《Clean Code》阅读笔记

• 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  并发
  

  • 复杂且不成熟，跳过。