CleanCode01

《代码整洁之道》学习笔记01-整洁代码

《代码整洁之道》 作者：罗伯特.C.马丁（Bob大叔）
《Clean Code》 Robert C.Martin

概述

阅读该书有2种原因：第一，你是个程序员；第二，你想成为更好的程序员。

1.1 要有代码

• 代码永存！
• 我们永远抛不掉代码，因为代码呈现了需求的细节。在某些层面上，这些细节无法被忽略或抽象，必须明确之。
• 将需求明确到机器可以执行的细节程度，就是编程要做的事。而这种规约正是代码。
• 实际上，在较高层次上用领域特定语言撰写的规约也将是代码！它也得严谨、精确、规范和详细，好让机器理解和执行。
• 记住，代码确然是我们最终用来表达需求的那种语言。我们可以创造各种与需求接近的语言。。我们可以创造帮助把需求解析和汇总为正式结构的各种工具。
• 然而，我们永远无法抛弃必要的精确性——所以代码永存。

1.2 糟糕的代码

• 我认为好代码是该领域最强固、最受支持、最被强调的前提了。
• 我们知道好代码重要，是因为其短缺实在困扰了我们太久。
• 勒布朗（LeBlanc）法则：稍后等于永不（Later equals never）。

1.3 混乱的代价

• 随着混乱的增加，团队生产力也持续下降，以致趋近于零。（备注：后续可以结合技术债来进行一些总结）
• 花时间保持代码整洁不但关乎效率，还关乎生存。

为什么好代码会这么快就变质成糟糕的代码？理由多得很。
我们抱怨需求变化背离了初期设计。我们哀叹进度太紧张，没法干好活。
我们把问题归咎于愚蠢的经理、苛求的用户、没用的营销手段和那些电话消毒剂。
不过，亲爱的呆伯特（Dilbert），我们是自作自受。我们太不专业了。

• “不听经理的，我就会被炒鱿鱼。” 多半不会。多数经理想要知道实情，即便他们看起来不喜欢实情。

• 经理他们会分离卫护进度和需求；那是他们该干的。你则当以同等的热情卫护代码。

• 守护代码、写好代码是程序员的本职工作，而不是经理的本职工作；所以，程序员应该守护自己的代码，这是专业性的体现。

• 不要指望其他人来帮助你保持专业性，而是应该由你自己来坚守专业性。

• 医生如果按照病人说的办（在给他做手术前别洗手以节约时间），就是一种不专业的态度（更别说是犯罪了）。

• 同理，程序员遵从不了解混乱风险的经理的意愿，也是不专业的做法。

• 制造混乱无助于赶上期限。

• 赶上期限的唯一方法——做得快的唯一方法——就是始终尽可能保持代码整洁。

1.3.4 整洁代码的艺术

• 这一节值得深思，单独整理出来。
• 坏消息是，写整洁代码很像是绘画。多数人都知道一幅画是好是坏，但能分辨优劣并不表示懂得绘画。
• 写整洁代码，需要遵循大量的小技巧，贯彻刻苦习得的”整洁感”。
• 这种”代码感”就是关键所在。
• 编写整洁代码的程序员就像是艺术家，他能用一系列变换把一块白板变作由优雅代码构成的系统。

1.3.5

• 这一节很关键，值得反复研读，单独整理出来。

C++发明者的观点

• Bjarne Stroustup，C++语言发明者，《C++ Programming Language》一书作者：

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

• Bjarne用了”优雅”一词。说得好！优雅的定义：外表或举止上令人愉悦的优美和雅观；令人愉悦的精致和简单。

• 注意对”愉悦”一词的强调。Bjarne显然认为整洁的代码读起来令人愉悦。

• 读这种代码，就像见到手工精美的音乐盒或设计精良的汽车一般，让你会心一笑。

• 务实的Dave Thomas 和 Andy Hunt 从另一个角度阐述了”糟糕的代码引发混乱！”，他们提到破窗理论。

• Bjarne 也提到完善错误处理代码，往深处说就是在细节上花心思。凸显出整洁代码对细节的重视。

• Bjarne 以””整洁的代码只做好一件事”结束论断。毋庸置疑，软件设计的许多原则最终都会归结为这句警语。

《面向对象分析与设计》作者观点

• Brady Booch，《Object Oriented Analysis and Design with Application》一书作者：

整洁的代码简单直接。
整洁的代码如同优美的散文。
整洁的代码从不隐藏设计者的意图，充满了干净利落的抽象和直截了当的控制语句。

• Grady的观点与Bjarne的观点有类似之处，但他从可读性的角度来定义。
• 我特别喜欢”整洁的代码如同优美的散文”这种看法。
• 代码应当讲述事实，不引人猜测。它只该包含必需之物。

Eclipse 战略教父的观点

• “老大” Dave Thomas，OTI公司创始人，Eclipse 战略教父：

整洁的代码可由作者之外的开发者阅读和增补。
它应当有单元测试和验收测试。
它使用有意义的命名。
它只提供一种而非多种做一件事的途径。
它只有尽量少的依赖关系，而且要明确地定义和提供清晰的、尽量少的API。
代码应通过其字面表达含义，因为不同的语言导致并非所有必需的信息均可通过代码自身清晰表达。

• Dave断言，整洁的代码变化与其他人予以增补。（开放闭合原则 OCP）
• Dave将整洁系于测试之上！
• 应当用人类可读的方式来写代码。（源自Knuth的”字面编程”）

《修改代码的艺术》作者的观点

• Michael Feathers，《Working Effectively with Legacy Code》一书作者：

我可以列出我留意的整洁代码的所有特点，但其中有一条是根本性的。
整洁的代码总是看起来像是某位特别在意它的人写的。
几乎没有改进的余地。
代码的作者什么都想到了，如果你企图改进它，总会回到原点，赞叹某人留给你的代码——全心投入的某人留下的代码。

• 一言以蔽之：在意。
• 这就是本书的题旨所在。或许该加个副标题，如何在意代码。

《极限编程实施》作者的观点

• Ron Jeffries，《Extreme Proramming Installed》以及《Extreme Programming Adventure in C#》作者
• Ron 初入行就在战略空军司令部编写Fortran程序，此后几乎在每种机器上编写过每种语言的代码。他的言论值得咀嚼。

节选：
近年来，我开始研究贝克的简单代码规则，差不多也都琢磨透了。简单代码，依其重要顺序：
能通过所有测试；
没有重复代码；
体现系统中的全部设计理念；
包括尽量少的实体，比如类、方法、函数等。
在以上诸项中，我最在意代码重复。
（中间略过，感兴趣请读原文）
减少重复代码，提高表达力，提早构建简单抽象。这就是我写整洁代码的方法。

• Ron以寥寥数段文字概括了本书的全部内容。
• 不要重复代码，只做一件事——表达力，小规模抽象。该有的都有了。

Wiki发明者、极限编程创始人之一的观点

• Ward Cunningham，Wiki发明者，Extreme Programming的创始人之一，Smalltalk 语言和面向对象的思想领袖。所有在意代码者的”教父”。

如果每个例程都让你赶到深合己意，那就是整洁代码。
如果代码让编程语言看起来像是转为解决那个问题而存在的，就可以称之为漂亮的代码。

1.4 思想流派

• 我（”鲍勃大叔”）又是怎么想的呢？在我眼中整洁代码是什么样的？
• 本书将以详细到吓死人的程度告诉你，我和我的同道对整洁代码的看法。
• 任何门派都并非绝对正确。
• 可以把本书看作是对象导师（Object Mentor，作者开的咨询培训公司）整洁代码派的说明。
• 书中要传授的就是我们勤操己艺的方法。
• 实际上，书中很多建议都存在争议。可以参考、但不必一味盲从。

1.5 我们是作者

• Javadoc中的 @author 字段告诉我们自己是什么人。我们是作者。作者都有读者。
• 实际上，作者有责任与读者做良好沟通。下次你写代码的时候，记得自己是作者，要为评判你工作的读者写代码。
• 你或许会问：代码真正”读”的成分有多少呢？难道主要力量不是应该用在”写”上吗？
• 作者玩过”编辑器回放”，回放过程显示，多数时间都是在滚动屏幕，浏览其他模块！
• 你该明白了。花费读与写的时间的比例超过 10 ： 1。写新代码时，我们一直在读旧代码。
• 既然比例如此之高，我们就想让读的过程变得轻松，即便那会使编写过程更难。不可能光写不读，所以使之易读也就是使之易写。
• 这事概无例外。不读周边代码就没法写代码。
• 编写代码的难度，取决于读周边代码的难度。
• 要想干得快，要想早点做完，要想轻松写代码，先让代码易读吧。

1.6 童子军军规

• 光把代码写好可不够。必须时时保持代码整洁。
• 借用没改过童子军一条简单的军规，应用到我们的专业领域： 让营地比你来时更干净。
• 如果每次签入时，代码都比签出时干净，那么代码就不会腐坏。
• 清理并不一定要花多少功夫，也许知识改好一个变量名，拆分一个有点过长的函数，消除一点点重复代码，清理一个嵌套if语句。

1.7 前传与原则

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

1.8 小结

• 艺术书并不保证你读过之后能成为艺术家，只能告诉你其他艺术家用过的工具、技术和思维过程。
• 本书同样也不担保让你成为好程序员。它不担保能给你”代码感”。
• 它所能做的，只是展示好程序员的思维过程，还有他们使用的技巧、技术和工具。
• 你会看到好代码，也会看到糟糕的代码。你会的看到糟糕的代码如何转化为好代码。你会看到启发、规条和技巧的列表。
• 你会看到一个有一个的例子。但最终结果取决于你自己。
• 最重要的是多练习。
• Practice makes perfect。（熟能生巧）
• 无他，唯手熟尔。