《Clean Code》一书回顾

《Clean Code》一书从翻开至今，已经差不多两个月的时间了，尽管刨去其中的假期，算下来实在是读得有点慢。阅读期间，断断续续的做了不少笔记。之前，每每在读完了一本技术书籍之后，其中的诸多细节会很快的淡忘，最终留下的往往是在阅读时候与自己之前的印象产生极大共鸣的部分，或者在之后实践当中碰巧运用到的一些知识点。所以，根据已往的经验来说，对于一本技术书籍的学习，个人更愿意依照如下两个基本原则来学习：

• 撷取个人当前认同最深的少数几个知识点，反复进行实践，并在理解之后再扩张到其他的知识点
  
• 择期再次阅读，并记录之前理解不对的或者总结自己收获的新的认知

也因为做如是认为，对于这本书的阅读笔记，当前也只对一些印象深刻的三个观点进行记述。

价值认同

决定去学习一件事情，首要的是认同其跟从的价值。所以作者在第17章《 Smells and Heuristics》总结部分提到提到：

这份启发与味道的清单很难说已完备无缺。我不能确定这样一份清单会不会完备无缺。但或许完整性不该是目标，因为该清单确实给出了一套价值体系。这套价值体系才该是目标。

我很赞同作者的这种说法，CleanCode首先必须要程序员本身非常在乎自己的代码，并且有心一点一滴的去提升自己的代码质量。有了这样相同的价值认知，剩下的就是不断的编写代码、改进代码，按照一些建议或者过程当中自己收获的心得，一步一步螺旋式的去改善代码的质量。

方法学

其实，大多人都是想学好的，但是往往是有向学之心，但无恒久之力。古今皆有之，比如《论语》当中便有一段冉求与夫子的对话：“冉求曰：「非不說子之道，力不足也。」子曰：「力不足者，中道而廢。今女畫。」”

对于此，作者在书里面的多个地方结合自己的经验做了说明，读了可真是使人倍受鼓舞啊，且看。在第3章《Functions》当中有：

写代码和写别的东西很像。在写论文或文章时，你先想写什么就写什么，然后再打磨它。初稿也许粗陋无序，你就斟酌推敲，直至达到你心目中的样子。

我写函数时，一开始都冗长而复杂。有太多缩进和嵌套循环。有过长的参数列表。名称是随意取的，也会有重复的代码。不过我会配上一套单元测试，覆盖每行丑陋的代码。

然后我打磨这些代码，分解函数、修改名称、消除重复。我缩短和重新安置方法。有时我还拆散类。同时保持测试通过。

最后，遵循本章列出的规则，我组装好这些函数。

我并不从一开始就按照规则写函数。我想没人做得到。

作者非常坦白的告诉他自己的写作过程，尽管无法证实，但是如此inspiration的表达，也是像我这样自认愚笨、难以雕琢的程序员所喜闻乐见的，算算自己多多坚持似乎也还有成为好程序员的机会:) 另外，从作者的这一段叙述里面，起码可以知道两件事：

• 好的代码的写成并非一蹴而就，而需要反复、耐心细致的调试
  
• 单元测试的重要，帮助确保优化前后功能的一致

在第14章《Successive Refinement》里面也有：

这段程序并非从一开始就写成现在的样子。更重要的是，我也没指望你能一次写出整洁、漂亮的程序。如果说我们从过去几十年里面学到什么东西的话，那就是编程是一种技艺甚于科学的东西。要编写整洁代码，必须先写肮脏代码，然后再清理它。

作者在这里也突出了高质量的代码伴随了一个逐步改进的过程。不过现实当中往往是生产了非常多的“能工作”的程序，然后就没有然后了。

综合本书归结下来，写好代码的建议并未只是一味的谈论理论，相反的，作者反复的强调动手实践的重要性，并且在书中花了100+页来示范代码的重构。所以，自己总结了Clean Code的方法学为四个字：“反复，改进”。

四原则

四原则出自第12章《Emergence》，中文版对该章名称的翻译为“跌进”。这一章相对来说，是更为详细的方法论。Kent Beck认为遵守简单设计的四条规则，对于创建具有良好设计的软件有着莫大的帮助，它们是：

• 运行所有测试
  
• 不可重复
  
• 表达了程序员的意图
  
• 尽可能减少类和方法的数量

上面的四条规则按照重要程度排列。对于“设计规则之一：运行所有测试”，作者提到的一句话：“测试编写得越多，就越能持续走向编写较易测试的代码。”这一话多少是一种鼓励，对于当前大部分开发人员而言，都是极其讨厌测试代码的编写，并且通常是在事后为了覆盖率而去“有针对性”的编写测试用例。当然，这一种原因时因为开发人员本身没有编写多少代码，所以不知道测试的好处；另外一种是不知道测试代码的重要性，其带来的质量和效率上面的提升功能。

测试固然很重要，但是作者同时也提到编写高质量的测试代码更重要，因为糟糕的测试代码可能会带来适得其反的效果。对于单元测试的说法，王垠在他的一篇文章《谈“测试驱动的开发”》也专门谈到过他对测试的认识，其中透露的比如“不能在心理上完全依赖测试”，“架构并未成型的时候对于测试可以延迟编写”也是可以用来作为参考的。

其他的三条设计规则，也就是属于“重构”的范围了。其实不管是测试，还是重构，里面都包含了相当多的内容，显然三言两语并不能说出过大概，但是这对于Clean Code整体干支的梳理上清晰了不少。有了测试，便可以消除对清理代码就会破坏代码的恐惧。

尽管有着诸多的指导原则和参考规范，文中的一些内容也会有自相矛盾的地方：为了保持类和函数短小会造出太多细小类和方法，而四条规则的最后一条则是尽可能少的类和方法。作者对此做了一个说明：

我们的目标是在保持函数和类短小的同时，保持整个系统短小精悍。不过要记住，这在关于简单设计的四条规则里面是优先级最低的一条。所以，尽管使类和函数的数量尽量少是很重要的，但更重要的却是测试、消除重复和表达力。
所以，坚守一些规范是好的，但是同时也需要保持一定的灵活性。

总的来说，上面的“价值认同”、“方法学”与“四原则”是自己偷懒总结的当前欣赏或者说觉得有指导意义的三个方法的知识点，对于书中其他的各种参考当然也是有价值的，因为知道自己一次性记不了那么多的详细条目所以也就并未一一将笔记全副进行摘录了。对于各方面尚未登堂的自己来说，Coding Now！

其他

拿这本书每一章的内容的组织来说，带给我的感觉与之前读到的一些书籍有所不同，当然，这主要是我看的技术书籍少得可怜的缘故 :( 之前阅读的一些技术书一章篇幅较长，实话说，自己当前对于技术不是痴迷的那一类，所以读起来真是有些痛苦，这也间接的造成了一些书读了一半或者一部分。而该书每一章的组织因为比较短小，所以读起来会觉得比较轻松，却在不经意间读完了。同时，这也带给了我在写作笔记时的一点启发：之前自己很欣赏多位技术博主的长篇笔记，觉得异常丰满，在自己学着去写作的过程当中总是也向其看齐，但是因为自身水平不够，所以总是常常半途而废。其实想想将一片笔记写成恰到的长度，说明了该说明的，就很不错。

注：文中的中文引用来自翻译版《代码整洁之道》