第十二章 迭进
12.1 通过迭进设计达到整洁目的
据Kent认为，只要遵循了下面的规则，设计就能变得简单
- 运行所有测试
- 不可重复
- 表达了程序员的意图
- 尽可能减少类和方法的数量
12.2 简单设计规则1：运行所有测试
只要系统可测试，就会导向保持类短小且目的单一的设计方案。遵循SRP的 类，测试起来较为简单。测试编写得越多，就越能持续走向编写较易测试的代码。所以，确 保系统完全可测试能帮助我们创建更好的设计。
12.3 简单设计规则2~4：重构
有了测试，就能保持代码和类的整洁，方法就是递增式地重构代码。添加了几行代码后， 就要暂停，琢磨一下变化了的设计。设计退步了吗？如果是，就要清理它，并且运行测试， 保证没有破坏任何东西。测试消除了对清理代码就会破坏代码的恐惧。
在重构过程中，可以应用有关优秀软件设计的一切知识。提升内聚性，降低耦合度，切 分关注面，模块化系统性关注面，缩小函数和类的尺寸，选用更好的名称，如此等等。这也 是应用简单设计后三条规则的地方：消除重复，保证表达力，尽可能减少类和方法的数量。
12.4 不可重复
重复是拥有良好设计系统的大敌。它代表着额外的工作、额外的风险和额外且不必要的 复杂度。重复有多种表现。极其雷同的代码行当然是重复。类似的代码往往可以调整得更相 似，这样就能更容易地进行重构。重复也有实现上的重复等其他一些形态。例如，在某个群 集类中可能会有两个方法：size（）、isEmpty().
12.5 表达力
软件项目的主要成本在于长期维护。为了在修改时尽量降低出现缺陷的可能性，很有必 要理解系统是做什么的。当系统变得越来越复杂，开发者就需要越来越多的时间来理解它， 而且也极有可能误解。所以，代码应当清晰地表达其作者的意图。作者把代码写得越清晰， 其他人花在理解代码上的时间也就越少，从而减少缺陷，缩减维护成本。
就是要通过好命名、规范来表达。
12.6 尽可能少的类和方法
即便是消除重复、代码表达力和SRP等最基础的概念也会被过度使用。为了保持类和函 数短小，我们可能会造出太多的细小类和方法。所以这条规则也主张函数和类的数量要少。
我们的目标是在保持函数和类短小的同时，保持整个系统短小精悍。不过要记住，这在 关于简单设计的四条规则里面是优先级最低的一条。所以，尽管使类和函数的数量尽量少是 很重要的，但更重要的却是测试、消除重复和表达力。
12.7 小结
有没有能替代经验的一套简单实践手段呢？当然不会有。另一方面，本章中写到的实践 来自于本书作者数十年经验的精练总结。遵循简单设计的实践手段，开发者不必经年学习就 能掌握好的原则和模式。
