很多IT组织都面临一个难题：老系统的维护、升级越来越难做。特别是那些价值高、生命周期长、规模大的核心业务系统，越到后来，要修复一个缺陷或者新增一个功能就需要越大的工作量。这是为什么呢？

软 件的质量体现在两方面：商业方面的质量，以及技术方面的质量。从商业的角度看来，“成功的软件”意味着它所创造的价值超出在它身上付出的代价。从技术的角 度看来，“成功的软件”意味着所有测试都通过、代码结构良好、并且容易理解和维护。很多商业上非常成功的软件系统忽视了技术方面的质量，所以尽管它们仍然 在为IT组织创造价值，但对它们的维护和升级越来越困难。最终技术质量的欠缺会反过来阻碍软件系统创造更大的商业价值。

为了保留并最大化软件资产的价值，适应新的需求变更，老系统总会面对维护和升级。当维护和升级的困难达到一定程度时，很多IT组织就会决定投入一整块资源和时间来改善这些老系统的技术质量，以便将来的维护升级能顺利进行。这样的做法通常被称为“重构项目”。

根据我们的经验，很多重构项目在目标管理、任务划分和质量保证等方面存在比较严重的问题，这些问题导致重构项目不能充分发挥价值。

目标管理

很多重构项目缺乏清晰的、可测试的目标。以ThoughtWorks参 与过的一个重构项目为例，该项目最初的目标只有“提高代码可维护性”等感性的描述，缺乏量化指标。目标不清晰的直接结果是，进行重构的程序员难以明确每一 步的重构工作应该做到什么程度，导致系统各个部分的优化程度不一致，一些部分在经过重构之后仍然质量低下，而且难以确定完成重构的时间。

和 新功能开发一样，重构也同样应该是可验收的，并且验收过程应该尽可能自动化。除了确保其功能性行为仍然保持原样不变之外，重构工作的验收条件还包括单元测 试覆盖率、代码复杂度、编码规范等指标。这些指标的报告应该自动化地生成，及时地展现给所有项目成员，为此我们需要一个持续集成环境来自动、频繁地验证所 有重构工作。

在ThoughtWorks参与的重构项目中，我们采用CruiseControl作为持续集成工具。每次开发者往代码库中签入（check in）代码时，就会触发CruiseControl对项目进行构建，构建的内容包括编译、连接（对于后台部分）、单元测试、测试覆盖率统计、代码复杂度统计、编码规范检查、部署到测试环境、功能测试等。

很多遗留还缺乏有效的项目自动化（automation）机制，使得持续集成环境无法发挥出它最大的价值。在建立持续集成环境的过程中，还应该对项目自动化机制进行改进，确保所有构建工作都能自动完成。于是完整的构建不仅在持续集成服务器上频繁运行，还在每个开发者的工作机器上更加频繁地运行。

任务划分

很多重构项目并没有明确的、细粒度的任务划分，实际进行重构的程序员得到的任务往往是类似“对安全模块进行重构”这样粗粒度、模块级的任务，而项目经理得到的反馈也是类似“可能需要两个月”这样粗略的估计，因此重构项目的进度往往难以控制。

和别的任何开发任务一样，重构任务（以及其他“技术债”类型的任务）也应该符合INVEST的标准：彼此独立（Independent），可讨论（Negotiatable），有价值（Valuable），可估算工作量（Estimatable），足够小（Small），可测试（Testable）。尤其是，它们的工作量应该得到估算，它们应该按照业务价值排列优先级。因为归根到底，重构（以及其他任何开发任务）都归结为“花在代码上的成本”与“对业务创造的价值”之间的权衡。

我们建议按照软件功能模块划分任务，而不区分是新功能开发还是重构。在实际工作中我们发现，对于同样的功能模块，新开发和重构的工作量差别不大。这也意味着重构工作可以被安排在日常开发工作中进行，并统一管理进度。

质量保证

在过去的咨询项目中，我们曾经不止一次见到这样的项目：在缺乏测试覆盖的情况下，程序员们修改旧系统中的代码，试图提高其可读性和可维护性。这些项目往往自称“重构项目”，但实际上它们并不是重构，因为它们缺乏必要的质量保证机制。

按照定义，重构是对软件内部结构的一种调整，目的是在不改变“软件之可观察行为”的前提下，提高其可理解性，降低其修改成本。如果没有一套可靠的测试机制，重构就无从谈起，因为你根本就无从知道自己做的调整是否改变了“软件之可观察行为”，甚至可能已经搞得系统不能运行还一无所知。

对这种没有测试的系统进行重构，就像是编织一张网：先针对一小块功能编写验收测试，在这张“粗网”的保护下再逐渐给代码添加单元测试，有了粗细两层网的保护 再深入重构。随着重构的开展，这张频繁自动化运行的安全网也渐渐铺开。从不断提升的测试覆盖率和不断降低的代码复杂度，我们就能清晰地看到重构的进展情况。

有 时由于代码质量低劣，程序员们在试图重构时会遇到困难：那些最需要重构的代码也是最难进行单元测试的。通常这是因为模块之间的依赖过于复杂、建立依赖的方 式不佳，而导致无法将这些模块纳入测试。此时需要首先建立验收测试套件，然后用必要的解耦手段调整依赖关系，然后才能对这些模块进行单元测试，之后才能对 它们进行重构。

ThoughtWorks能做什么？

在重构项目的组织、管理、质量保证和实施技术等方面，ThoughtWorks具有无可比拟的能力和经验。我们曾为一些生命周期长至数年、规模大至上百万行代码的遗留系统进行过重构项目，并取得了良好的效果。

我们的咨询师可以和公司中的开发者共同工作，共同解决发现并解决问题。在这个过程中，ThoughtWorks的咨询师会迅速把更佳的工作方式和理念告诉作为客户的开发者，以便在将来没有ThoughtWorks咨询师的情况下，客户也可以坚持那些方发实践，并把它传播给更多的人。

组织简介 | 联系我们 |   Copyright 2002 ®  UML软件工程组织 京ICP备10020922号

京公海网安备110108001071号