豆瓣评分8.6！这本《代码整洁之道》到底牛在哪里？重点都在这了

《代码整洁之道》（Clean Code）豆瓣评分8.6，是开发人员的必读书籍，尤其是当您想成为一名更好的软件开发人员时。这本书解释了什么是干净的代码和最佳实践，以帮助您写出干净整的代码。

代码整洁之道

阅读本书有两种原因：第一，你是个程序员；第二，你想成为更好的程序员。很好。我们需要更好的程序员。

这是本有关编写好程序的书。它充斥着代码。我们要从各个方向来考察这些代码。从顶向下，从底往上，从里而外。读完后，就能知道许多关于代码的事了。而且，我们还能说出好代码和糟糕的代码之间的差异。我们将了解到如何写出好代码。我们也会知道，如何将糟糕的代码改成好代码。
 

关于作者

Robert C. Martin，世界级软件开发大师，设计模式和敏捷开发先驱，敏捷联盟首任主席，C++ Report前主编，被后辈程序员尊称为“Bob大叔”。20世纪70年代初成为职业程序员，后创办Object Mentor公司并任总裁。Martin还是一名多产的作家，至今已发表数百篇文章、论文和博客文章。除本书外，还著有《代码整洁之道：程序员的职业素养》《敏捷软件开发：原则、模式和实践》《UML：Java程序员指南》等。
 

什么是整洁代码

作者问过很多知名的、经验丰富的程序员对整洁代码 的定义很多，他们是怎么想的？

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

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

Grady Booch，Object Oriented Analysis and Design with Applications（中译版《面向对象分析与设计》）一书作者。

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

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

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

简单代码，依其重要顺序：

• 能通过所有测试；
• 没有重复代码；
• 体现系统中的全部设计理念；
• 包括尽量少的实体，比如类、方法、函数等。

如何写出整洁代码？

有意义的命名

只有程序员才会读你的代码。所以，尽管用那些计算机科学（Computer Science，CS）术语、算法名、模式名、数学术语吧。依据问题所涉领域来命名可不算是聪明的做法，因为不该让协作者老是跑去问客户每个名称的含义，其实他们早该通过另一名称了解这个概念了。

命名规则

• 名副其实
• 避免误导
• 做有意义的区分
• 使用读得出来的名称
• 使用可搜索的名称
• 避免使用编码
• 避免思维映射
• 类名
  类名和对象名应该是名词或名词短语，如Customer、WikiPage、Account和AddressParser。避免使用Manager、Processor、Data或Info这样的类名。类名不应当是动词。
• 方法名
  方法名应当是动词或动词短语，如postPayment、deletePage或save。属性访问器、修改器和断言应该根据其值命名，并依Javabean标准[10]加上get、set和is前缀。
• 别扮可爱
• 每个概念对应一个词
• 别用双关语
• 使用解决方案领域名称
• 使用源自所涉问题领域的名称
• 添加有意义的语境

函数

函数的第一规则是要短小。第二条规则是还要更短小。

函数应该做一件事。做好这件事。只做这一件事。

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

然后我打磨这些代码，分解函数、修改名称、消除重复。

注释

“别给糟糕的代码加注释——重新写吧。”

—Brian W. Kernighan与P. J. Plaugher

什么也比不上放置良好的注释来得有用。什么也不会比乱七八糟的注释更有本事搞乱一个模块。什么也不会比陈旧、提供错误信息的注释更有破坏性。

如果你发现自己需要写注释，再想想看是否有办法翻盘，用代码来表达。每次用代码表达，你都该夸奖一下自己。每次写注释，你都该做个鬼脸，感受自己在表达能力上的失败。

我为什么要极力贬低注释？因为注释会撒谎。也不是说总是如此或有意如此，但出现得实在太频繁。注释存在的时间越久，就离其所描述的代码越远，越来越变得全然错误。原因很简单。程序员不能坚持维护注释。

代码在变动，在演化。从这里移到那里。彼此分离、重造又合到一处。很不幸，注释并不总是随之变动——不能总是跟着走。注释常常会与其所描述的代码分隔开来，孑然飘零，越来越不准确。

格式

先明确一下，代码格式很重要。代码格式不可忽略，必须严肃对待。代码格式关乎沟通，而沟通是专业开发者的头等大事。

或许你认为“让代码能工作”才是专业开发者的头等大事。然而，我希望本书能让你抛掉那种想法。你今天编写的功能，极有可能在下一版本中被修改，但代码的可读性却会对以后可能发生的修改行为产生深远影响。原始代码修改之后很久，其代码风格和可读性仍会影响到可维护性和扩展性。即便代码已不复存在，你的风格和律条仍存活下来。

那么，哪些代码格式相关方面能帮我们最好地沟通呢？

• 垂直格式
• 横向格式
  一行代码应该有多宽？图5-2展示了这7个项目的代码行宽度分布情况。其中展现的规律性令人印象深刻，45个字符左右的宽度分布尤为如此。其实，20～60的每个尺寸，都代表全部代码行数的1%。也就是总共40%！或许其余30%的代码行短于10个字符。记住，这是个对数标尺，所以图中长于80个字符部分的线性下降在实际情况中会极其可观。程序员们显然更喜爱短代码行。

团队规则

每个程序员都有自己喜欢的格式规则，但如果在一个团队中工作，就是团队说了算。

单元测试

TDD三定律

谁都知道TDD要求我们在编写生产代码前先编写单元测试。但这条规则只是冰山之巅。看看下列三定律：

定律一　在编写不能通过的单元测试前，不可编写生产代码。

定律二　只可编写刚好无法通过的单元测试，不能编译也算不通过。

定律三　只可编写刚好足以通过当前失败测试的生产代码。

整洁的测试还遵循以下5条规则

快速（Fast）　测试应该够快。测试应该能快速运行。测试运行缓慢，你就不会想要频繁地运行它。如果你不频繁运行测试，就不能尽早发现问题，也无法轻易修正，从而也不能轻而易举地清理代码。最终，代码就会腐坏。

独立（Independent）　测试应该相互独立。某个测试不应为下一个测试设定条件。你应该可以单独运行每个测试，及以任何顺序运行测试。当测试互相依赖时，头一个没通过就会导致一连串的测试失败，使问题诊断变得困难，隐藏了下级错误。

可重复（Repeatable）　测试应当可在任何环境中重复通过。你应该能够在生产环境、质检环境中运行测试，也能够在无网络的列车上用笔记本电脑运行测试。如果测试不能在任意环境中重复，你就总会有个解释其失败的接口。当环境条件不具备时，你也会无法运行测试。

自足验证（Self-Validating）　测试应该有布尔值输出。无论是通过或失败，你不应该查看日志文件来确认测试是否通过。你不应该手工对比两个不同文本文件来确认测试是否通过。如果测试不能自足验证，对失败的判断就会变得依赖主观，而运行测试也需要更长的手工操作时间。

及时（Timely）　测试应及时编写。单元测试应该恰好在使其通过的生产代码之前编写。如果在编写生产代码之后编写测试，你会发现生产代码难以测试。你可能会认为某些生产代码本身难以测试。你可能不会去设计可测试的代码。
 

迭进

通过迭进设计达到整洁目的，Kent Beck关于简单设计的四条规则，对于创建具有良好设计的软件有着莫大的帮助。

• 运行所有测试；
• 不可重复；
• 表达了程序员的意图；
• 尽可能减少类和方法的数量；
• 以上规则按其重要程度排列。

并发编程

编写整洁的并发程序很难——非常难。编写在单线程中执行的代码简单得多。编写表面上看来不错、深入进去却支离破碎的多线程代码也简单。系统一旦遭受压力，这种代码就扛不住了。

第一要诀是遵循单一权责原则。将系统切分为分离了线程相关代码和线程无关代码的POJO。确保在测试线程相关代码时只是在测试，没有做其他事情。线程相关代码应该保持短小和目的集中。

了解并发问题的可能原因：对共享数据的多线程操作，或使用了公共资源池。类似平静关闭或停止循环之类边界情况尤其棘手。

学习类库，了解基本算法。理解类库提供的与基础算法类似的解决问题的特性。

学习如何找到必须锁定的代码区域并锁定之。不要锁定不必锁定的代码。避免从锁定区域中调用其他锁定区域。这需要深刻理解某物是否已共享。尽可能减少共享对象和共享范围。修改对象的设计，向客户代码提供共享数据，而不是迫使客户代码管理共享状态。

在本文中，我与您分享了从Robert C. Martin（鲍勃叔叔）的《代码整洁之道》中摘录的部分关于如何写出整洁代码的部分内容。对于每个想要在职业道路上脱颖而出的开发人员来说，这都是非常重要的。

代码整洁之道

尽管糟糕的代码也能运行，但如果代码不整洁，会使整个开发团队泥足深陷，写得不好的代码每年都要耗费难以计数的时间和资源。但是，这种情况并非无法避免。

著名软件专家罗伯特·C. 马丁（Robert C. Martin） 在本书中为你呈现了革命性的视野。他携同Object Mentor公司的同事，从他们有关整洁代码的*佳敏捷实践中提炼出软件技艺的价值观，以飨读者，让你成为更优秀的程序员——只要你着手研读本书。

阅读本书需要你做些什么呢？你将阅读代码——大量代码。本书会促使你思考何谓正确的代码，何谓错误的代码。更重要的是，本书将促使你重新评估自己的专业价值观，以及对自己技艺的承诺。