准备重构——保持项目节奏实践

重构是对代码的简化，无论是产品代码还是测试代码。重构不等于重新设计，只是简化而已。重构过的代码不会改变它的 接口 ，只是更简单。

我的代码不见了

哈尔，初级开发人员

我现在参与的项目是离开学校后的第二个。在第一个项目中，经理听了我的代码工作估算后说：“好，既然你还是个新人，咱们就再多加点儿时间吧，这样你可以把学到的经验 应 用到写好的代码中。”我觉得他这么做纯属多余，不过没关系，我还是加倍努力，在截止日期来临之时完成了手上的工作。接下来，我了解了整个系统真正的运转方 式，就得修改已完成的工作了，不只耗费了所有额外的时间，而且还多用了一点点。让我感到惊讶的是：为了解决问题，我没有编写更多代码，而是简化了现有做法 并去掉一些代码。我的代码不见了。

现在这个项目，我使用了持续集成，而且一边开发一边重构。在开发时，简化并清洁代码，而不是改变设计，这让我对自己手上的工作和开发速度有了更清晰的认识。而且，我的代码仍然在继续消失。

如 果你曾经随项目进展计算过代码行数，要是项目采取顺序式生命周期，或是将集成和测试放在项目临近结束时进行，那就会看到一个S形曲线（见图9.1）。可以 注意到，开始集成和测试后，代码的数量就开始减少了，这是因为发生了重构。（没错，也许是重新设计了某些东西，不过以我的经验，主要是重构造成的。）如果 不准备在项目快结束时进行重构，或是不愿意在顺序式生命周期中偿还技术债务，代码量会居高不下。在项目快结束时，代码缩减就不会发生。

图9.1 顺序式生命周期中代码量的典型变化

在使用敏捷生命周期的项目中，代码量的曲线很可能如图9.2所示。代码的增长要慢得多，因为开发人员仅仅编写当前功能需要的代码。他们还会一边开发一边重构，而不是等到项目快结束时再去修复一大堆bug。（对于很多bug来说，去掉某些代码就可以解决。）

图9.2 敏捷生命周期中代码量的典型变化

项 目经理可以让重构与开发同时进行，也可以最后再进行重构。如果希望发布的产品中缺陷越少越好，就必须要对代码进行重构。如果让重构与开发同时进行，重构的 成本是非常小的。如果打算在项目结束时重构，那成本可就高了，而且你会发现总是没有时间去做重构。要么管理层就会指示你不要重构。高昂的成本来源于开发人 员得到的反馈延迟过久，以及不知道应该重构哪些代码以及如何重构，因为开发人员很久没有思考过要重构的代码了。