重建还是重构？

在 Agile Testing Days 2015 大会上， Wouter Lagerweij 谈到了如何重建一个遗留系统而不是重构它，来帮助团队采取敏捷实践，比如测试驱动开发，自动化测试，持续交付。他的谈话基于他的博客文章 Don’t Refactor. Rebuild. Kinda 。

InfoQ 采访了 Lagerweij 关于是什么让重构如此困难，重建软件的风险是否比重构小，以及持续交付如何配合软件的重建。InfoQ 同时请教了他关于重建和重构的建议。

InfoQ：您能解释一下是什么使得重构这么困难吗？

Lagerweij：只要你去做，重构是一项相当简单的实践。同样的例子是单元测试。只要你坚持为代码编写测试用例，或者清理代码中的设计问题，一小步一小步的，这并不困难。

可是你越是把这些丢在一边，捡起来的时候就越困难。这就是为什么每个人都一直说“技术债务”。可是实际上它通常不是指 Ward Cunningham 所创造的技术债务（参见 Ward Explains Debt Metaphor ）。

软件行业并不是唯一发生这些事情的地方。只是询问一些活跃在医疗保健行业的专业医师。了解到外科医生坚持在手术前洗手能降低一半的手术并发症，但是即使有积极的宣传和结构化的清单，它依然很难被遵守。

所以，由于一些团队推迟重构，我们有一些混乱，或者说“遗留代码库”。由于这些团队几乎总是没有足够的重构经验（否则他们已经这样做了），他们无疑不能完成修复这些混乱代码的工作。

此时这些团队认识到他们应该为他们的“债务”做些事情，他们不得不接受一个系统，在其中努力学习用以提升自己系统的技能！当小的改动在系统的不同部位导致不可预知的结果时，是对重构中积极的学习经历不利的。而且任何开发人员都知道为封闭的，紧耦合的系统添加单元测试是一个困难和不愉快的经历。

我想我要说的是，如果你等到遇到这些麻烦才开始学习这些技能，很可能你将不会成功的应用它们。也就是说，在掌握它们之前，你更可能会先放弃它们。

InfoQ：在您看来重建软件比重构的风险更小？您能解释一下吗?

Lagerweij：说实话，如果你的团队成员知道如何去改进一个遗留系统，重构始终是更好的选择。它的风险更小，并且比任何类型的重写的开销要少。

但是不幸的是这些技能仍然非常稀少。如果团队中的成员之前没有做过这类工作，之后你的所有工作都会慢于预期。你会在开发团队和公司中增加挫败感。

有一些组织发现自己陷入了困境。他们简直没有专业人员来解决他们的技术问题。他们不能构造有竞争力的新功能。甚至找到几个有经验的人也很难，常常是“太小，太迟”的情况。

这种情况下重写是更有吸引力的。

InfoQ：您能给出一些例子来展示团队如何来重建软件以及做持续交付吗？是什么让它们成为一个好的组合？

Lagerweij：重写的一个好处是你能重新开始。这意味着这次你能确保你这样做是正确的。当然，大多数时候，你不能。就像我之前说的，处理这些事情最好的方式，例如测试和重构，就是持续不断的做。但是如果你之前从来没有做好过，它怎么会突然就能工作？

我在谈话中说过的，我们已经在我当前工作的团队试过。我们使用测试驱动开发（也叫做行为驱动开发），我们会保持代码的整洁，确保始终有 100% 的单元测试覆盖率。他们不再害怕他们的遗留系统，他们知道他们能够做到这一点。

我们也同意，确保我们不会受到放松控制的诱惑，我们从第一天起就做到完全的持续部署。这意味着开发者每次推送代码到 GitHub 中时，它会自动构建，测试并部署一直到生产。这使得我们任何时候都能极好的关注在保持高质量上。你不能推迟那些测试，因为推送未测试的代码会破坏构建，使得整个团队等着你。但是你也不想跳过测试（或者写一个未检查的单元测试只是为了糊弄覆盖率），因为你实际上可能破坏生产。你自己，很明显。

还有一些简单的心理作用，没有人真正关心什么让测试覆盖率从 2.1% 到 2.0%，但是当它从 100% 掉到 99.9% 时，整个团队会要求一个解释。

你仍然需要经历一个学习过程。重新开始并不会让你突然做的更好。它只是创造一个更大成功率的机会。

InfoQ：对于正在考虑用重建软件代替重构的团队，您有什么建议？

Lagerweij：首先，在发布之前不要尝试和重建任何东西。找到一种方式将新系统和老系统融合，并尽快为你的新系统的用户提供价值。有些东西比如 strangler pattern 或 branch by abstractio 能帮助你。如果你不这样做，你的项目要么在某个时候被取消，要么永远继续下去，但无疑不会有好的结果。

其次，停止糊弄自己。使用一个严格要求规定的工具，比如持续部署，会感觉在项目的表明需求上增加了额外的负担，但是这个规定会帮助你避免陷入和之前同样的陷阱，写出一个完全的新的遗留系统。它会促使你学习新技能，例如持续重构，如何测试驱动你的代码，有多少种不同类型的测试需要被掌握，如何自动化部署，如何处理监控和错误处理。所有的这些都是和到生产的途径变得短和直接紧密相关的。

最后，可能是最重要的，涉及到客户！尽管比通常的要多，重写的诱惑是得到“和老系统做同样的事”的响应，而不是因为客户交流有任何进一步的需要。但是我们需要知道客户现在需要什么。我们也需要知道他不再需要什么。我们都熟悉 80/20 法则关于被使用的功能。你看，重构不仅仅只是发生在代码层面，审查你的需求，业务流程甚至是商业模式都是同样的重要。

当然，它仍然会有大量的工作要做，但是如果你坚持这些原则，一旦你做到了，你会得到干净的代码，一个学习型团队，和高兴的客户。

查看英文原文： Rebuild or Refactor?

感谢张龙对本文的审校。

给InfoQ 中文站投稿或者参与内容翻译工作，请邮件至 editors@cn.infoq.com 。也欢迎大家通过新浪微博（ @InfoQ ， @丁晓昀），微信（微信号： InfoQChina ）关注我们，并与我们的编辑和其他读者朋友交流（欢迎加入 InfoQ 读者交流群（已满），InfoQ 读者交流群（#2））。