演化架构与紧急设计: 对设计进行重构

在 “测试驱动设计，第 1 部分” 和 “测试驱动设计，第 2 部分” 中，我介绍了测试如何为新的项目实现更好的设计。在 “组合方法和 SLAP” 中，我讨论了两种关键模式 — 组合方法（composed method）和单一抽象层原理 — 为您的代码结构提供了整体目标。需要牢记这些模式。一旦拥有了一个现有软件项目，那么发现和利用设计元素的主要方法就是进行重构。在 Martin Fowler 的经典著作 Refactoring 中，他将重构定义为 “一种严格的技术，可以重新构造现有代码体，修改代码的内部结构，但是不会影响代码的外部行为”。重构是一种具有某种目的的结构转换。对任何项目来说，值得称赞的一点就是拥有可以轻松进行重构的代码库。在本文中，我将讨论如何使用重构技术来查找隐藏在代码库中的未得到充分设计的代码。

关于本系列

本 系列 旨在从全新的视角来介绍经常讨论但是又难以理解的软件架构和设计概念。通过具体示例，Neal Ford 将帮助您在演化架构 和紧急设计 的灵活实践中打下坚实的基础。通过将重要的架构和设计决定推迟到最后关键时刻，您可以防止不必要的复杂度降低软件项目的质量。

单元测试可以提供最重要的安全屏障，允许您按照自己的意愿重构代码库。如果您的项目的代码覆盖率达到了 100%，那么可以安全地重构代码。如果尚未达到这个程度的测试，那么草率地进行重构就会变得比较危险。本地化修改可以很容易地应用并且可以立即看到修改效果，但是副作用产生的破坏也会使您非常苦恼。软件会产生无法预料的耦合点，对代码的某一部分进行微小的修改会影响到整个代码库，造成数百行代码发生错误。要安全地修改代码并找出大量错误，需要进行广泛的单元测试。对于一个为期 2 年的 ThoughtWorks 项目，技术主管在运行该项目的前一天对代码进行了 53 处不同的重构。他在进行重构时信心满满，因为项目拥有广泛的代码覆盖率。