《Clean Code》阅读笔记

时间：2023-12-24 21:28:07

  • Chapter 2  命名

    • 命名要表现意图
    • 避免歧义和误导，增强区分
    • 命名可读性：便于发音，增强印象，便于交流
    • 命名可查性：增强区分，便于搜索
    • 类和对象的命名：名词或名词短语
    • 方法的命名：动词或动词短语
    • 使用仅表述单一概念的词，如 get，避免多概念的词，如 fetch
    • 使用行业术语及业务术语

  • Chapter 3  方法

    • 尺寸：越小越好，不应超过20行
    • if、else、while 等 statement 不应超过一行
    • 单一责任
    • 单一抽象层级
    • 无参最优，一参数次之，二参数最次，不应超过3参数，否则应引入参数结构或对象
    • 避免将参数作为输出

  • Chapter 4  注释

    • 尽量少用注释，避免过时的注释
    • 如果能用良好的命名来表现意图，就不用注释
    • 如果能用代码来表现意图，就不用注释
    • 良好的注释：　
      • 提供补充信息
      • 解释意图
      • 警告
      • TODO 注释
      • 强调注释

  • Chapter 5  格式

    • 垂直格式：
      • 单个类文件，不超过100行/150行/200行
      • 使用空行分隔方法
      • 自顶向下的方法依赖分布
    • 水平格式
      • 单行不超过80字符/100字符/120字符，屏幕能够全部显示
      • 保持缩进
      • 使用空格，运算符左右使用空格等
      • 显式地突出空循环，避免省略地写为一行
      • 优先遵循团队规定的格式

  • Chapter 6  对象和数据结构

    • 数据结构和对象的对立性：
      • 数据结构以 public 暴露内部属性，不提供访问方法
      • 对象以 private 隐藏内部属性，提供访问方法
      • 数据结构易于增加新方法，同时不影响已有结构。对象反之，易于增加新类，同时不影响已有方法。
      • 数据结构不便于增加新数据结构，因为需要改变每个已有方法。对象反之，不便于增加新方法，因为需要改变每个已有类。
      • Law of demeter：最少知识原则，一个对象应对其他对象有尽量少的了解。类C的 f 方法，应只调用这些方法：
        • 类C的方法
        • f 创造的对象的方法
        • 传递给 f 的参数对象的方法
        • 类C的成员实例变量的方法

  • Chapter 7  错误处理

    • 使用 exception， 避免使用返回的错误码
    • 逐层 throw exception，在最顶层 catch，即定义一个错误传递流
    • 将 try/catch 抽取出来作为独立函数
    • 在需要时定义新的 exception 类
    • 不要返回 null，定义一个 Null 类
    • 不要传递 null

  • Chapter 8  边界

    • 在自己的代码和第三方代码的边界处，使用自己编写的代码适配（适配器），避免将第三方代码直接嵌入自己的代码
    • 测试第三方代码

  • Chapter 9  单元测试

    • TDD
    • 测试代码和生产代码同样重要，但测试代码不一定需要遵循同样的效率和资源限制
    • 保持测试代码的clean，避免过时和冗余等
    • BUILD-OPERATE-CHECK 的测试模板
    • given/when/then 的测试方法命名建议
    • 模板方法模式可能有所帮助
    • 每个测试方法，仅测试一个概念
    • F-I-R-S-T原则
      • Fast，测试效率要高
      • Independent：每个测试应当独立
      • Repeatable：在不同环境下均可运行
      • Self-Validating：应拥有一个boolean的输出，自身直接输出测试是否通过
      • Timely：每个测试应 just before 写在生产代码之前

  • Chapter 10  类

    • 类成员顺序如下，自顶向下
      • public static constants
      • private static constants
      • private instance variables
      • public functions
      • 被 public function  调用的 private functions 紧跟在该 public function 之后，满足自顶向下的阅读顺序
    • 尺寸：类尽可能小，不同于用物理行数衡量方法的尺寸，应该用 responsibilities 衡量类的尺寸。类应保持单一责任。
    • 类应该保持单一责任（SRP），而类名应该描述这一责任。
    • 类名不应超过25个单词，同时避免 if、and、or、but等代表多责任的词，同时少用大范围的含糊的词，如super，manager等。
    • 尽可能提高类的内聚度：尽量使类中的每个成员变量被类方法使用
    • 将大类分隔为很多小类，优化组织性，提高内聚。但也会造成类数量的激增。
    • 依赖倒置原则（DIP），类依赖于抽象，而不是具体实现。降低耦合。
    • 将类中会变化的部分抽象出来，让客户代码依赖于抽象，而不是具体实现。

  • Chapter 11  系统

    • 将系统构造部分，与使用部分解耦
    • 将构造和初始化部分，全部放在main函数中，再在main函数中，将构造完毕的对象，以参数形式传递给具体使用它们的函数。这是一个方法。
    • 工厂方法可能有所帮助。
    • 依赖注入（DI）和控制反转（IoC）机制可能有所帮助。
    • （这一章没怎么看懂）

  • Chapter 12  迭进

    • Kent Beck 认为的“Simple Design”的四条规则。重要性由上而下递减。
      • 运行所有测试
      • 无重复（良好重构）
      • 表现编程者意图
        • 良好命名
        • 保持类和方法尽可能小
        • 遵循公有标准和共同语言，如通用规范、设计模式等
        • 良好的单元测试
      • 最小化类和方法的数量
        • 经过去重、重构等操作之后，类和方法的数量可能激增。因此在此基础上，尽量减少它们的数量。

  • Chapter 13  并发

    • 复杂且不成熟，跳过。

  • Chapter 14  坏味道和启示

    • 注释 Comments

      • C1 不适宜的注释：修改历史、作者、最近修改日志等，都不适宜出现在注释中。注释应该仅保留技术和业务相关的要点。
      • C2 过时的注释
      • C3 冗余的注释：注释是代码的重复，没有提供额外信息
      • C4 写的很烂的注释：认真措辞，不要随意
      • C5 注释起来的代码：没人知道它的重要性和意义，其他人根本无法轻易地改动它。如果可以，直接删除它

    • 环境 Environment

      • E1 构筑环境需要不只一步：做到一键 build 你的项目环境。
      • E2 单元测试需要不只一步：做到一键 test 你的项目的所有单元测试。

    • 方法 Functions

      • F1 太多参数：无参最佳，1参次之，2参再次，3参再次，多余三个参数，则考虑引入参数结构或对象。
      • F2 输出参数：避免改变参数，然后将它作为结果输出。
      • F3 Flag参数：避免使用Flag参数，这意味着这个方法将做不只一件事。
      • F4 Dead方法：无人问津的方法，直接删除它。

    • 通用 General

      • G1 单个源码文件中，出现多种编程语言：解耦、分离他们。
      • G2 明示的行为没有被实现：应该遵循“最低惊异原则”，任何明示而被期待的行为，都应该被正确实现。否则，代码阅读者将会对更多的代码失去信任。
      • G3 边界处的行为都要被准确实现：任何边界条件、角落case、巧合case、异常case的行为，都需要被准确实现。否则，代码阅读者将会对更多的代码失去信任。
      • G4 覆盖安全机制：避免覆盖你使用的框架提供的安全代码机制，如警告等，不要轻易重载、覆盖、取消它们。
      • G5 重复：不仅包括明显重复的代码，还包括重复的设计等。善用模板方法和策略等设计模式。
      • G6 错误/混乱抽象分层：不同抽象层级的隔离应该明确，一个方法应该仅在同一抽象层级上操作。
      • G7 基础类依赖于它们的衍生类：不要让抽象上层依赖于抽象下层，抽象上层应该对抽象下层一无所知。也有例外：比如上层严格控制了下层衍生物的数量等。
      • G8 单个方法/类/模块负责通过多责任：约束尺寸，约束责任，约束信息。
      • G9 Dead Code：避免永远不会执行的代码，直接删除它。
      • G10 垂直分隔：局部变量和方法需要被定义在他们的使用者附近。private function应该被定义在just below他们的首次调用者处。保持自顶向下的阅读顺序。
      • G11 不一致性：相似的行为应该保持相似一直的结构和命名，保持“最低惊异原则”。
      • G12 杂物：无用的变量，无用的方法，无信息的注释，都应该被尽早删除。
      • G13 人为耦合：解耦那些不必要的、不小心造成的耦合关系。
      • G14 位置不当：类中的方法应该尽量只使用此类中的变量和其他方法，如果某方法更多地使用其他类中的变量和方法，那么它可能需要挪动位置了。
      • G15 传递boolean参数：不要将boolean值作为方法参数，这意味着该方法负责不只一件事。
      • G16 含混的意图：代码自身要意图明确。
      • G17 位置不当：一些变量和方法应该正确地放置在它们最被期待的地方。“最低惊异原则”
      • G18 不适当的static：某些方法适合static，有些不适合，正确处理它们。
      • G19 变量意图不明：使用有解释力和变现力的变量，如合适命名等，增强可读性。
      • G20 方法意图不明：使用有变现力的方法名，增强可读性。
      • G21 对算法理解不明
      • G22
      • G23 建议使用多态来代替if/else和switch/case，当后者重复超过1次时，考虑使用多态替换他们。工厂模式可能有所帮助。
      • G24 建议遵循标准惯例
      • G25 建议使用 Named Constants 代替魔数：魔数自身的变现力低，使用具名常量增强表现力。
      • G26 建议当你首次完成系统时，对细节的完成尽可能详细，不要偷懒。
      • G27 良好结构和惯例之间的取舍，前者优先
      • G28 建议封装条件：将if/else和switch/case处的条件式，用独立而良好命名的方法重新表述，使条件处永远只有一行，并且让那个独立的方法的名字，替你解释此处条件是什么。
      • G29 避免否定条件：首先使用肯定条件。
      • G30 方法只做一件事
      • G31 隐藏临时耦合
      • G32 别随意
      • G33 封装边界条件：将边界条件集中、封装，不要让他们散落各处
      • G34 方法只活动在同一层抽象上
      • G35 让配置信息和数据，保持在高层抽象上，不要定义在底层抽象上，通过参数逐层传递它们。
      • G36 避免多级传递：遵守Law of Demeter

    • Java

      • J1 包引入：如果引入了一个package中的超过两个成员，那么直接引入整个包。
      • J2 不要继承常量：不要将常量声明在基类或接口中，然后继承它们。将常量声明在子类中。
      • J3 使用枚举代替一系列常量。

    • 命名 Naming

      • N1 选择有描述力、表现力的名字
      • N2 在命名时体现不同抽象层级
      • N3 如果可能，采用某些标准惯例下的命名
      • N4 明确命名，避免含混用词
      • N5 相关域越大，其命名可以越长
      • N6 避免编码：？？
      • N7 不要将方法不会去做的事，体现在其命名上

    • 测试 Tests

      • T1 不充分的测试
      • T2 使用IDE提供的测试覆盖工具
      • T3 不要跳过那么低级的、显而易见的trivial测试
      • T4
      • T5 细心测试边界条件
      • T6 当你发现bug时，正儿八经地测试它
      • T7 测试失败pattern
      • T8
      • T9 测试需要快速

相关文章