《代码整洁之道》读后感

Posted 2020-07-27

众所周知，软件质量，不但依赖于架构及项目管理，而且与代码质量紧密相关。这一点，无论是敏捷开发派还是传统开发派，都不得不承认。《代码整洁之道》提出一种观念：代码质量与其整洁度成正比。干净的代码，既在质量上较为可靠，也为后期维护、升级奠定了良好的基础。作为编程领域的佼佼者，这些实践在《代码整洁之道》中体现为一条条规则（或称“启示”），并辅以来自现实项目的正、反两面的范例。只要遵循这些规则，就能编写出干净的代码，从而有效提升代码质量。以上便是《代码整洁之道》这本书的内容简介，不过这并不是当初读这本书的理由，选择这本书，是因为一些非技术性原因，比如我喜欢它的插图（如下所示，相传洗的是保林球计分程序），还有第一章那句话“阅读本书有两种原因：第一，你是个程序员；第二，你想成为更好的程序员。很好，我们需要更好的程序员。”

 

本书第一章是对什么是整洁代码的讨论，引用了Bjarne Stroustrup（C++之父）、Grady Booch（UML的创始人之一）等人当然也Bob大叔（本书的作者Robert Martin）自己对整洁代码的理解。总结来说整洁代码有以下表现：第一，代码要力求集中，每个模块、类和函数要全神贯注于一件事；第二，消除重复代码，提高代码的表达力；第三，包括尽量少的实体，比如类、函数和方法。

第二章是有意义的命名，本章的内容很实用，因为不管是现实世界还是软件项目中，命名都是一件让人头疼的事。本章读完之后使我在命名上有了很大的进步，此后告别了只会使用“a、b、c、d、e、f......”的时代。总结来说，命名的原则包括：选择体现本意的代码能让人更容易理解和修改代码，避免使用与本意相悖的词，提高代码的清晰度，避免误导；对词意相近的命名要做有意义的区分，避免模糊不清的命名；使用可搜索的名称，单字母名称和数字常量很难在大篇幅的代码中找出，采用能表达意图的名称；抛弃以前依赖使用编码的习惯；类名和对象名应该尽可能使用名词或名词短语，方法名尽量使用动词或动词短语属性访问器、修改器应该根据其值命名。

第三章是函数，本章关于函数的讨论，其实只有一句话：“函数只应该做一件事情，把一件事情做好，而且只由它来做这一件事情。”这一点与面向对象设计原则中的单一职责原则不谋而合，不过，知易行难，想要达到这样的境界，还需要大量的练习才行。

第四章是对注释的说明，几乎每个人都告诉你“代码记得要写注释呀！”，然而，这个注释怎么写，写在哪里，写多少字，有没有什么格式要求，却从来没人说过。本章对此作出了解释，在此总结性的说几句注释的要求：用注释来提供基本信息，对意图的解释，把晦涩难懂的参数和返回值翻译为可读形式；对于没有用的代码无需用注释标记，可以直接删掉；注释要简明，扼要。不过，注释不是对劣质代码的补救。事实上好的代码即便没有注释也拥有良好的可读性，但恰当的注释会让代码变得更可读、可维护性更高。

第五章是代码风格，只要在IDE中设置好使用的风格就好。重点是第六章对象和数据结构，这一章讲述的内容对于养成良好的编成习惯很重要，读完第六章后感觉一直想着面向对象编程，但是在写程序时写的一些代码都和面向对象的设计理念相违背，看来需要更多的思考与练习。第六章中一些内容更深层次的含义我还不能理解，希望以后能加深理解。

第七章对错误（异常）处理的讲解非常精彩，其中提到，整洁的代码中对错误的处理应当是被分离的关注点（不要跟正常的业务逻辑混杂在一起），而面向对象中的异常机制就是一种在不打乱原有业务逻辑的前提下处理掉程序在运行时发生的不正常状况的手段。这章有两个观点我特别欣赏，一是非受检异常允许你在适当的地方处理异常，而适当的地方就是异常影响代码执行逻辑的地方，不管做哪种类型的应用，都应该尽可能向用户隐藏异常的发生，除非发生了不可挽救的状况，这才是符合最小惊讶原则的设计；二是如果一个方法在出状况的时候返回null，那么调用者都要通过频繁的检查返回值来判定是否出错，一旦忘了这件事情就有可能出错，既然null是一种异常状况，那么用抛出异常的方式来代替返回null明显是更好的做法。

第八章边界的内容对实际开发有重要的指导意义，其中提供了很多测试和理解第三方代码的建议，主要有：不要在生产代码中试验新东西，而是编写测试来遍览和理解第三方代码，如在应用中调用第三方代码，来检测自己对API的理解程度；通过代码中少数几处引用第三方边界接口的位置来管理第三方边界。

第九章的内容是单元测试，作者Bob大叔是TDD（测试驱动开发）的倡导者，这一章讲的是如何编写整洁的测试，给出的答案是FIRSE（Fast、Independent、Repeatable、Self-Validating、Timely）规则。本章讲述的内容较为专业，理解起来较困难，不是太懂。

第十章关于类的介绍，主要还是SRP（单一权责原则），类应该尽量短小；类应该只有少量的实体变量，每个方法都应该操作一个或多个这种变量，保持内聚性；要为了修改来对类进行组织；类应该依赖于抽象而不是依赖于具体细节。

第十一章系统、第十二章迭进、第十三章并发编程，说来惭愧，感觉这些都不是太懂，需要以后细细研究。第十五章到第十七章说的都是重构，十分精彩。

虽然选这本书的时候理由很简单，不过看完之后感想却很多。神在细节之中，一段段代码是组成程序之屋的砖，只有砖块够结实，房屋才会兼顾，所以我认为《代码整洁之道》是每个立志成为好的程序员的人必读的书。作者曾嘲笑低水平的编码者为“代码猴子”，而这本书的作用，正是给猴子加上腕带，规定其写出整洁的代码，成为模范童子军。