《代码整洁之道》 读书笔记 一、整洁代码

1. 整洁代码

1.1 要有代码

代码不再是问题；我们应当关注模型和需求。代码很快就能自动产出。这种言论是不正确的。

因为代码呈现了需求的细节，在某些层面上，这些细节无法被忽略或抽象。

即使将来语言的抽象程度继续提升，那么用这种语言开发也同样是代码。同样需要严谨、规范、精确和详细。

1.2 糟糕的代码

写出糟糕代码的原因：

• 赶着推出产品，代码写得乱七八糟。特性越加越多，代码也越来越烂，最后再也没法管理这些代码了。
• 瞟一眼自己亲手造成的混乱，决定弃之而不顾，走向新一天。
• 烂程序居然能运行，然后断言能运行的烂程序总比什么都没有强。
• 有朝一日再回头清理。（勒布朗（LeBlanc）法则：稍后等于永不（Later equals never））。

1.3 混乱的代价

• 代码混乱难以修改和加feature，进度缓慢
• 修改都影响到其他两三处代码。
• 修改者都得对那堆扭纹柴了然于心，这样才能往上扔更多的扭纹柴。
• 为提升生产力不得不加入更多新人，新人不熟悉系统设计造成更多的混乱。

1.3.1 华丽新设计

最后，开发团队造反了，他们告诉管理层，再也无法在这令人生厌的代码基础上做开发。他们要求做全新的设计。于是组建一个新的团队重新开发，保留旧系统，新旧系统同步开发。持续极长时间。我就见过延续了十年之久的。到了完成的时候，新团队的老成员早已不知去向，而现有成员则要求重新设计一套新系统，因为这套系统太烂了。

1.3.2 态度

代码变糟糕，抱怨的原因：

• 需求变化背离了初期设计
• 进度太紧张，没法干好活
• 愚蠢的经理、苛求的用户、没用的营销方式

正确的态度：

• 经理和营销人员指望从我们这里得到必须的信息，然后才能做出承诺和保证；即便他们没开口问，我们也不该羞于告知自己的想法。
• 多数经理想要知道实情，即便他们看起来不喜欢实情。多数经理想要好代码，即便他们总是痴缠于进度。他们会奋力卫护进度和需求；那是他们该干的。你则当以同等的热情卫护代码。

举例论证：

假使你是位医生，病人请求你在给他做手术前别洗手，因为那会花太多时间，你会照办吗？本该是病人说了算；但医生却绝对应该拒绝遵从。为什么？因为医生比病人更了解疾病和感染的风险。医生如果按病人说的办，就是一种不专业的态度（更别说是犯罪了）。
同理，程序员遵从不了解混乱风险的经理的意愿，也是不专业的做法。

1.3.3 谜题

程序员面临的基础价值谜题：之前的混乱拖了自己的后腿。但开发者们背负期限的压力，只好制造混乱。

但这个谜题的最后部分说错了，制造混乱没办法赶上限期，混乱只会立刻拖慢你。做得快的唯一方法——就是始终尽可能保持代码整洁。

1.3.4 整洁代码的艺术

• 明白整洁代码的意义，再去尝试写整洁代码才有意义
• 写整洁代码很像是绘画，能分辨画的好坏和能绘画是两码事（分辨整洁代码和会写也是）
• 写整洁代码，需要遵循大量的小技巧，贯彻刻苦习得的“整洁感”/"代码感"（代码感有些人天生就有，有些人费点劲才能得到）。

1.3.5 什么是整洁代码

Bjarne Stroustrup, C++语言发明者，C++ Programming Language（中译版《C++程序设计语言》）一书作者。

• 代码逻辑应当直截了当，叫缺陷难以隐藏；
• 尽量减少依赖关系，使之便于维护；
• 依据某种分层战略完善错误处理代码；
• 性能调至最优，省得引诱别人做没规矩的优化，搞出一堆混乱来。
• 整洁的代码只做好一件事。

总结：

• 不要重复代码
• 只做一件事
• 表达力（可读性）
• 小规模抽象。

1.4 思想流派

本书会详细介绍关于整洁变量名的想法，关于整洁函数的想法，关于整洁类的想法，如此等等。

实际上，书中很多建议都存在争议。或许你并不完全同意这些建议。这样挺好的。另外一方面，书中列出的建议，乃是我们长久苦思、从数十年的从业经验和无数尝试与错误中得来。无论你同意与否，如果你没看到或是不尊敬我们的观点，就真该自己害臊。

1.5 我们是作者

我们是作者。作者都有读者。实际上，作者有责任与读者做良好沟通。下次你写代码的时候，记得自己是作者，要为评判你工作的读者写代码。

读与写花费时间的比例超过10:1。写新代码时，我们一直在读旧代码。既然比例如此之高，我们就想让读的过程变得轻松，即便那会使得编写过程更难。没可能光写不读，所以使之易读实际也使之易写。
这事概无例外。不读周边代码的话就没法写代码。编写代码的难度，取决于读周边代码的难度。要想干得快，要想早点做完，要想轻松写代码，先让代码易读吧。

1.6 童子军军规

美国童子军一条简单的军规，应用到我们的专业领域：让营地比你来时更干净。

如果每次签入时，代码都比签出时干净，那么代码就不会腐坏。清理并不一定要花多少功夫，也许只是改好一个变量名，拆分一个有点过长的函数，消除一点点重复代码，清理一个嵌套if语句。
你想要为一个代码随时间流逝而越变越好的项目工作。

1.7 前传与原则

本书是我2002年写那本Agile Software Development: Principles, Patterns, and Practices（中译版《敏捷软件开发：原则、模式与实践》，简称PPP）的“前传”。

在本书中，你会发现对不同设计原则的引用，包括单一权责原则（Single Responsibility Principle, SRP）、开放闭合原则（Open Closed Principle, OCP）和依赖倒置原则（Dependency Inversion Principle, DIP）等。

1.8 小结

本书同样也不担保让你成为好程序员。它不担保能给你“代码感”。它所能做的，只是展示好程序员的思维过程，还有他们使用的技巧、技术和工具。

还记得那个关于小提琴家在去表演的路上迷路的老笑话吗？他在街角拦住一位长者，问他怎么才能去卡耐基音乐厅（Carnegie Hall）。长者看了看小提琴家，又看了看他手中的琴，说道：“你还得练，孩子，还得练！”

1.9 参考文献

略