如何写出漂亮的代码? 非正规军应该怎么正规化? 让代码“优雅”起来?

2019-03-29 10:03:32 +08:00
 luxiaokuo

如题。

6577 次点击
所在节点    程序员
49 条回复
q8164305
2019-03-29 12:25:38 +08:00
多看,多写
wmhx
2019-03-29 12:41:46 +08:00
给时间就可以优雅,否则免谈
tkHello
2019-03-29 12:42:47 +08:00
用规范的工具 校验
sadhen
2019-03-29 12:57:23 +08:00
@yuankui 建议你买一本《程序员的职业素养》仔细阅读一下
qleroooo
2019-03-29 13:15:29 +08:00
@yuankui 能说有卵用,赚不到钱,说再多都卵用。这么浮躁的嘛
jtwor
2019-03-29 13:45:56 +08:00
c# 推荐 codemaid
ruandao
2019-03-29 14:03:36 +08:00
ftu
2019-03-29 14:08:14 +08:00
谷歌代码风格规范,有汉化版本的
libook
2019-03-29 14:09:08 +08:00
风格方面可以直接使用相应的 fmt 或 lint 工具,比如写 JS 用 ESLint,Go 和 Rust 都自带 fmt 工具。
但是其他方面就没那么容易了,代码的可靠性和性能都依赖于经验,可读性依赖于表达能力,Code Review 可以在明显的程度上改善这个问题。

可以参考一下我们团队的一个开发手册,忽略其他主题直奔 Coding 部分: https://github.com/guanghetv/our-dev-handbook/blob/master/README.md
zhangslob669
2019-03-29 14:20:03 +08:00
关于 Python 的可以多看看源码,可以参考这个:[Requests 源码分析]( https://zhangslob.github.io/docs/requests/request_source_code/)
SayNight
2019-03-29 14:53:30 +08:00
java 推荐:《 Effective Java 》《重构:改善既有代码的设计》《代码整洁之道 》《设计模式之禅》 。可能其它语言也有相似之处,欢迎其他 V 友补充
alw
2019-03-29 14:57:09 +08:00
用代码质量管理工具:Sonar
lolizeppelin
2019-03-29 15:19:24 +08:00
不建议直接去看上面的书

如果你不再是学生的话,心态、时间、记忆力都不适合直接看书

优秀源码光读没用, 要模仿着写, 你真正模仿优秀源码实现自己的需求的时候
并在模仿过程中删减增加,才能理解到哪些设计和写法的作用

到一定阶段后再看上面提到的书效果会更好
shiny
2019-03-29 15:22:23 +08:00
1、花时间写几年代码
2、结合以上书反思,对我个人帮助比较大的是《代码整洁之道》
yuankui
2019-03-29 17:02:49 +08:00
@sadhen 深受其害。
yuankui
2019-03-29 17:04:09 +08:00
@qleroooo 那请问优雅和赚钱又有什么关系?
yuankui
2019-03-29 17:05:39 +08:00
代码写得再漂亮,还不是民工。。

与其好好学习如何优雅地用 Java 面向对象编程,还不如好好学习,怎么优雅的用人类高级语言,面向下属,面向员工编程。。
sadhen
2019-03-29 19:11:31 +08:00
@yuankui

程序员的职业素养不只是将怎么写代码的 see https://book.douban.com/subject/11614538/

目 录
第 1 章  专业主义   1
1.1   清楚你要什么   2
1.2   担当责任   2
1.3   首先,不行损害之事   4
1.3.1   不要破坏软件功能   4
1.3.2   不要破坏结构   7
1.4   职业道德   8
1.4.1   了解你的领域   10
1.4.2   坚持学习   11
1.4.3   练习   11
1.4.4   合作   12
1.4.5   辅导   12
1.4.6   了解业务领域   13
1.4.7   与雇主 /客户保持一致   13
1.4.8   谦逊   13
1.5   参考文献   14
第 2 章  说“不”   15
2.1   对抗角色   17
2.2   高风险时刻   20
2.3   要有团队精神   22
2.3.1   试试看   24
2.3.2   消极对抗   25
2.4   说“是”的成本   27
2.5   如何写出好代码   34
第 3 章  说“是”   37
3.1   承诺用语   39
3.1.1   识别“缺乏承诺”的征兆   40
3.1.2   真正的承诺听起来是怎样的   41
3.1.3   总结   43
3.2   学习如何说“是”   43
3.2.1   “试试”的另一面   43
3.2.2   坚守原则   44
3.3   结论   47
第 4 章  编码   48
4.1   做好准备   49
4.1.1   凌晨 3 点写出的代码   50
4.1.2   焦虑时写下的代码   51
4.2   流态区   53
4.2.1   音乐   54
4.2.2   中断   55
4.3   阻塞   55
4.4   调试   57
4.5   保持节奏   60
4.5.1   知道何时应该离开一会   60
4.5.2   开车回家路上   61
4.5.3   洗澡   61
4.6   进度延迟   61
4.6.1   期望   62
4.6.2   盲目冲刺   62
4.6.3   加班加点   63
4.6.4   交付失误   63
4.6.5   定义“完成”   64
4.7   帮助   64
4.7.1   帮助他人   64
4.7.2   接受他人的帮助   65
4.7.3   辅导   66
4.8   参考文献   66
第 5 章  测试驱动开发   67
5.1   此事已有定论   69
5.2    TDD 的三项法则   69
5.3    TDD 的优势   70
5.3.1   确定性   70
5.3.2   缺陷注入率   71
5.3.3   勇气   71
5.3.4   文档   72
5.3.5   设计   72
5.3.6   专业人士的选择   73
5.4    TDD 的局限   73
5.5   参考文献   74
第 6 章  练习   75
6.1   引子   75
6.1.1    10 的 22 次方   76
6.1.2   转变   77
6.2   编程柔道场   79
6.2.1   卡塔   80
6.2.2   瓦萨   81
6.2.3   自由练习   81
6.3   自身经验的拓展   82
6.3.1   开源   82
6.3.2   关于练习的职业道德   82
6.4   结论   83
6.5   参考文献   83
第 7 章  验收测试   84
7.1   需求的沟通   84
7.1.1   过早精细化   86
7.1.2   迟来的模糊性   87
7.2   验收测试   89
7.2.1   “完成”的定义   89
7.2.2   沟通   91
7.2.3   自动化   92
7.2.4   额外工作   93
7.2.5   验收测试什么时候写,由谁来写   93
7.2.6   开发人员的角色   94
7.2.7   测试的协商与被动推进   95
7.2.8   验收测试和单元测试   96
7.2.9   图形界面及其他复杂因素   97
7.2.10   持续集成   98
7.3   结论   98
第 8 章  测试策略   99
8.1    QA 应该找不到任何错误   100
8.1.1    QA 也是团队的一部分   100
8.1.2   需求规约定义者   100
8.1.3   特性描述者   100
8.2   自动化测试金字塔   101
8.2.1   单元测试   101
8.2.2   组件测试   102
8.2.3   集成测试   103
8.2.4   系统测试   104
8.2.5   人工探索式测试   104
8.3   结论   105
8.4   参考文献   105
第 9 章  时间管理   106
9.1   会议   107
9.1.1   拒绝   107
9.1.2   离席   108
9.1.3   确定议程与目标   109
9.1.4   立会   109
9.1.5   迭代计划会议   109
9.1.6   迭代回顾和 DEMO 展示   110
9.1.7   争论 /反对   110
9.2   注意力点数   111
9.2.1   睡眠   112
9.2.2   咖啡因   112
9.2.3   恢复   112
9.2.4   肌肉注意力   112
9.2.5   输入与输出   113
9.3   时间拆分和番茄工作法   113
9.4   要避免的行为   114
9.5   死胡同   115
9.6   泥潭   115
9.7   结论   116
第 10 章  预估   117
10.1   什么是预估   119
10.1.1   承诺   119
10.1.2   预估   120
10.1.3   暗示性承诺   121
10.2    PERT    122
10.3   预估任务   125
10.4   大数定律   127
10.5   结论   127
10.6   参考文献   128
第 11 章  压力   129
11.1   避免压力   131
11.1.1   承诺   131
11.1.2   保持整洁   132
11.1.3   危机中的纪律   132
11.2   应对压力   133
11.2.1   不要惊慌失措   133
11.2.2   沟通   133
11.2.3   依靠你的纪律原则   133
11.2.4   寻求帮助   134
11.3   结论   134
第 12 章  协作   135
12.1   程序员与人   137
12.1.1   程序员与雇主   137
12.1.2   程序员与程序员   140
12.2   小脑   142
12.3   结论   143
第 13 章  团队与项目   144
13.1   只是简单混合吗   144
13.1.1   有凝聚力的团队   145
13.1.2   如何管理有凝聚力的团队   146
13.1.3   项目承包人的困境   147
13.2   结论   148
13.3   参考文献   148
第 14 章  辅导、学徒期与技艺   149
14.1   失败的学位教育   149
14.2   辅导   150
14.2.1    DIGI-COMP I, 我的第一台计算机   150
14.2.2   高中时代的 ECP-18    152
14.2.3   非常规辅导   154
14.2.4   艰难的锤炼   155
14.3   学徒期   156
14.3.1   软件学徒期   158
14.3.2   现实情况   159
14.4   技艺   160
14.5   结论   161
附录  工具   162
masker
2019-03-29 20:01:02 +08:00
一昧的追求优雅代码都是工作太闲造成的
anyele
2019-03-29 20:57:27 +08:00
@masker 不要为垃圾代码找借口

这是一个专为移动设备优化的页面(即为了让你能够在 Google 搜索结果里秒开这个页面),如果你希望参与 V2EX 社区的讨论,你可以继续到 V2EX 上打开本讨论主题的完整版本。

https://www.v2ex.com/t/549788

V2EX 是创意工作者们的社区,是一个分享自己正在做的有趣事物、交流想法,可以遇见新朋友甚至新机会的地方。

V2EX is a community of developers, designers and creative people.

© 2021 V2EX