读书笔记《代码整洁之道》迭进

迭进 我理解就是迭代。这章主要是讲，项目已经很大了。如果在一个已经成熟的项目中 进行开发迭代。 首先给出了简单设计的四条原则。按照重要性进行降序排序

 

运行所有测试

这是最重要的一条原则，可靠的系统需要通过所有的测试。 改动完了以后，所有的测试应该都要跑一遍。如果你的改动不能把所有的测试 都跑一遍，那就说明，改动是不安全的。当然 为了让所有的测试都能跑下去，写代码的时候 就保持类的短小和目的单一。

重构

因为有了测试，所以风险是可控的，那么就意味着 我们可以考虑优化。每次添加几行代码后，我们就需要考虑一下变化，重新设计，重新开发，运行测试。

在重构过程中尽量考虑优化，提升内聚性，降低耦合度，切分关注度，缩小函数，用更好的命名。

 

不可重复

重复是大忌，重复意味着包含了额外的工作额外的风险，额外且不必要的复杂度。既然有重复 那就说明可以调整到更相似的逻辑，然后把这部分相似的逻辑抽取出来。从而进行重构。

首先 就算重复代码再少（哪怕只有一行），也要有消除重复的意识。

做了一定的共性抽取之后，会发现有点违反SRP原则，这时候可以将这些重复的部分抽取为一个模版类，然后其它剩余的差异的部分 通过子类的继承 来补充。这就是 “模版方法模式”

 

表达力

软件的长期成本在于维护，项目越大 代码越难理解。为了降低 修改代码时出现缺陷的可能性，我们又必须理解系统在做什么。

这个时候 函数和类 当然是越小越好理解。短小的函数和短小的类通常易于命名，易于编写，易于理解。

采用标准命名法来命名 也会更有表达力。

编写良好的测试用例，可以替代文档用，也能提升表达力，让人更能理解某个类是做什么的。

最重要的是 爱惜珍惜自己的手艺，用心照拂自己创建的东西。

 

尽可能少的类和方法

为了防止以上概念被滥用，造成太多的细小类和方法，所以这条规则也主张函数和类的数量要少。我们除了要保持函数和类短小，也要保证整个系统 短小精悍。