代码整洁之道.jpg

第一章 整洁代码

1. 阅读本书有两种原因： 第一，你是个程序员；第二，你想成为更好的程序员。P1
2. 勒布朗（leBlanc）法则：稍后等于永不。P3
3. 写整洁的代码，需要遵循大量的小技巧，习得“整洁感”或“代码感”。P6
4. “整洁的代码只做一件事”。P7
5. 贝克简单代码规则：P9
   • 能通过所有的测试
   • 没有重复代码
   • 体现系统中的全部设计理念
   • 包括尽量少的实体，比如类、方法、函数等
6. 保持代码整洁。 P12

第二章 有意义的命名

1. 名副其实——如果名称需要注释来补充，那就不算是名副其实。P16
2. 使用读得出来的名称。P19
3. 类名（名称或名称短语）。P23
4. 方法名（动词或动词短语）。P23
5. 同一每个概念对应一个词。P24
6. 添加有意义的语境。P25

第三章 函数

1. 短小（25行）。P32
2. if语句、else语句、while语句内只有一行。P32
3. 只做一件事。P33
4. switch不只做一件事，违反单一职责原则，使用多态重构。P35
5. 使用描述性的名称。P36
6. 函数参数避免超过三个。P37
7. 标识参数标识此函数不止做一件事。P38
8. 如果参数超过三个并且多次成对出现就创建参数对象。P39
9. 无副作用，命令查询分离原则（Command Query Separation）。P42
10. 错误码通常使用枚举类型，数量多之后使用或添加新的错误码很困难，使用异常或之后派生更好。P44
11. 别重复自己，代码臃肿，修改麻烦，许多原则包括面向切面编程和面向组件编程意图消除重复。P44
12. 写代码就像写文章要不断打磨。P45

第四章 注释

1. 无法找到不用注释就能表达的方法，所以总要用注释。P50
2. 用代码的可读性替代注释。P50
3. 注释往往是因为糟糕的代码而存在的。P50
4. 多余的注释。P56
5. 忘更新的误导性注释。P58
6. 日志性注释（有版本控制器就不需要）。P59
7. 归属于署名。P63
8. 注释掉的代码。P63

第五章 格式

1. 用一套管理代码格式的简单规则。P71
2. 格式的目的，增强沟通。P72
3. 代码长度200行。P73
4. 向报纸学习，细节渐次增加。P73
5. 行长度120个字符。P80
6. 团队要有规则并遵守。P84

第六章 对象和数据结构

1. 过程式代码（使用数据结构的代码）便于在不改动既有数据结构的前提下添加新函数，面对对象代码便于在不改动既有函数的前提下添加新类。反过来讲，过程式代码难以添加新数据结构，因为必须修改所有函数。面向对象代码难以添加新函数，因为必须修改所有类。P90
2. 德墨忒尔律：模块不应了解它所操作对象的内部情形。P91
3. 对象暴露行为，隐藏数据。P94

第七章 异常处理

1. 使用异常而非返回码。P96
2. 使用不可控异常，一旦一底层函数声明抛出异常， 那么上层函数逐级都要修改。违反开闭原则。P98
3. 根据需要定义异常类。对错误分类的方式有多种，可以依据来源，是组件还是其他地方，或者依据类型，是设备错误还是网络错误。不过在我们定义异常类的时候，最重要的考虑是如何捕获它们。P99
4. 别返回null值。程序中不断的看到检测null值的代码，一处漏掉检测就可能会失控。返回Null，作者认为这种代码很糟糕。建议抛出异常 或者返回特定对象（默认值）。更早的发现问题。同理，也应该避免传递Null值给其他的方法。P101

第八章 边界

1. 对第三方进行学习性测试，当第三方程序包发布了新的版本，我们可以允许学习性测试，看看程序包的行为有没有发生改变。P110
2. 使用尚不存在的代码，有时候我们的第三方，还没有开发好API，但又不能影响到我们的开发进度，所以我们先可以定义好自己想要的接口。如果第三方ok了，我们再对接起来。P110
3. 通过接口管理第三方边界，可以使用ADApter模式将我的接口转换为第三方提供的接口。这个是要注意，第三方的代码和自己的代码混合太多，这样不便管理。P111

第九章 单元测试

1. TDD三定律。P114

• 除非这能让失败的单元测试通过，否则不允许去编写任何的生产代码。
• 只允许编写刚好能够导致失败的单元测试。 （编译失败也属于一种失败）
• 只允许编写刚好能够导致一个失败的单元测试通过的产品代码。

2. 每个测试一个概念。P122
3. FIRST原则。P123

• 快速：测试应该能快速运行，太慢了你就不会频繁的运行，就不会尽早的发现问题。
• 独立：测试应该相互独立，某个测试不应该为下个测试设定条件。当测试相互依赖，一个没通过导致一连串的测试失败，使问题诊断变的困难。
• 可重复：测试应该可以在任何环境中重复通过。
• 自足验证：测试应该有布尔值输出，无论通过或失败，不应该是查看日志文件去确认
• 及时：单元测试应该恰好在使其通过的生产代码之前编写。

第十章 类

1. 类应该短小。职责的数量。P126
2. 单一权责原则(SRP)。类或模块应有且只有一条加以修改的理由。系统应该有许多短小的类而不是巨大的类组成。P128
3. 内聚：如果一个类中的每个变量都被每个方法所使用，则该类具有最大的内聚性。内聚性高，意味着类中的方法和变量相互依赖，相互结合成一个逻辑整体。P129
4. 为了修改而组织。开放闭合原则（OCP）：类应当对扩展开放，对修改封闭。我们可以借助接口和抽象类来隔离这些细节带来的影响。P136

第十一章 系统

1. 将系统的构造和使用分开：构造和使用是不一样的过程。P142
2. 工厂，有时候应用程序需要确定何时创建对象，我们可以使用抽象工厂模式。将构造的细节隔离于应用程序之外。P143
3. 依赖注入（DI/IOC）。在依赖管理情景中，对象不应该负责实例化对自身的依赖，反之，它应该将这份权责移交给其他有权利的机制，从而实现控制的反转。P144
4. 扩容：“一开始就做对的系统”纯属神话，反之，我们应该只实现今天的用户的需求。然后重构，明天再扩容系统，实现新用户的需求。这就是迭代和增量敏捷的精髓所在。 就像城市不断的再拆掉，再建设。P145
5. 测试驱动框架，没必要先做大设计（Big Design Up Front, BDUP），BDUP实际上是有害的，它阻碍改进，因为心理上会抵制丢弃即成之事，也因为架构上的方案选择影响到后续的设计思路。P153

第十二章 迭进

1. 通过迭进设计达到整洁设计。P157
2. 简单设计规则，运行所有测试：P158

• 紧耦合的代码难以编写测试。同样编写测试越多，就会越遵循DIP之类的原则，使用依赖注入，接口和抽象等工具尽可能减少耦合。如此一来设计就会有长足进步。遵循有关编写测试并持续运行测试的、明确的规则，系统就会更贴近OO低耦合度、高内聚的目标。

3. 简单设计规则，重构：P158
   • 在重构过程中，可以应用有关优秀软件设计的一切知识，提升内聚性，降低耦合度。换句话说：消除重复，保证表达力，尽可能的减少类和方法的数量。
4. 测试消除了对清理代码就会破坏代码的恐惧。P158
5. 不可重复。重复是良好设计系统的大敌。它代表着额外的工作、额外的风险和额外不必要的复杂度。P159