项目剖析

虽然代码重构带有美学的、整洁的一面，但重构不是一门仅仅追求完美的设计而忽视其他限制的技术；相反，重构常常出于实用主义的立场。原因也很简单，那就是：结构良好的代码更易理解、更易修改，也就更不容易出现 bug，更容易添加新特性，这些都能带来实在的经济效益。

在这一点上，BugsZero 非常接近日常项目工作的场景：你有一些代码，也有一些测试覆盖保护，但是代码的结构不甚良好。当你接到新的需求，往往不得不在许多地方做出修改，需要记得诸多的修改点，而且可能常常就漏改其中的某几处而产生 bug；而由于代码交织着不同层次、各个方面的细节，又特别容易滋生 bug，使得你不敢贸然重构。于是用不了多久，又一块祖传代码就诞生了。

要对抗这种代码腐败趋势，正需要你频繁地进行重构，持续简化代码设计。《重构 2》的第 2.4 节里提到“预备性的重构”，指出重构代码的时机之一即是在添加新特性之前：先重构代码，使“添加新特性”一事变得更加简单，然后再添加想要的特性。这里我们也可以看到重构实用主义的一面。

BugsZero 里有一个十分大的类。大类往往承担了过多的职责，意味着它很可能需要让其他对象分担一些事情——缺乏对象，这是遗留代码另一个常见的问题。你需要练习的是，分辨什么时候需要分出一部分职责到新的对象身上，这会驱使你写出更加短小、更加内聚、更加模块化，因而也更可理解和维护的代码。