重构和重写的目标，都是要通过提高的代码的可读性、结构和清晰性，从而提高系统的健壮性。清晰的代码更易于维护和改善。然而，在很多情况下，敏捷团队会难以在二者之间做出选择。
代码会随着时间的流逝变得越来越差， Michael Dubakov 为此指出了下面的原因：
- 越来越多的特性。它会导致复杂度的提升。
- 捷径和权宜之道。为了支持诸如”我们在八月份需要这个 NB 的搜索，没二话”之类的特性
- 开发者轮换。新的开发者根本不知道架构之后的所有起决定性作用的决定和主意。知识不可避免地随着人员的轮换而流失。
- 开发团队的扩大。更多的人导致更少的交流，更少的交流产生糟糕的决定。
Michael 建议，虽然重构和重写都会使代码更加清晰，但是这两种技术都会导致现有系统的混乱。重构是一种增量式的活动，因此它每次只会接触到系统的一部分。这会在局部造成混乱，可能还比较容易控制。而另一方面，重写是更具有攻击性的改变，它会导致系统中更大的混乱。由于它会造成更广泛的影响，因此要想让重写的影响稳定下来，时间要比重构长得多。
我们重写旧的系统，因此混乱是家常便饭。在公开发行之后，混乱显著增长。我们预料会出现很多新的（和旧的）缺陷和古怪的行为，因此稳定期会更长。
Peter Schuh 认为团队经常会将两个词彼此替换使用，从而导致更多的迷惑和混乱。团队应该知道：和重构相比，重写更具有风险，因此应该恰当地使用术语。据他所说：
那只是语义上的。然而，在一些人受到伤害之前那只是语义上的。重写代码很有风险，并且有时会付出痛苦的努力，这么做不一定总有光明的结尾。如果我们执行重写，但是把它叫做重构，并且整个过程以梨形（指越到后来问题越多，需要付出的时间和成本也随之增长）进行，那就不会有业务人员停下来考虑语义了。他们只是会在下次听到重构这个词的时候退缩。
Guido A.J. Stevens 的想法很有趣，他认为问题并非出在重构和重写之间，而是在于：或者重构，或者重写并重构。他提出：即使当团队决定重写系统的时候，最终他们也会有两个系统并行运行。旧系统需要重构，而新系统正在被重写。这种组合变成了一项极度复杂的任务，据他所说：
维护老化的代码基础，并且编写新的系统，将会耗尽你的资源。你的团队被分割，并导致延迟。你需要制定计划，小心翼翼地执行转换。同时，你所面临的上市时间问题在你的竞争对手身上不存在，他们还会试图挖走你的客户。如果你能正视这种现实，并仍然想把公司前途押在重写上，那么你也许有机会成功。
Naresh Jain 对于遗留代码有下面特别的的建议。当代码难于理解，并且团队不能确定它做什么的时候进行重构。当很清楚知道代码做什么，但是很难理解那些代码的时候就重写。
因此，重构是不断提升系统更好的方式。它是慢速前进的，通过小的、经常的提升来提高质量。重写也有其自身的优势，然而在很多情况下它是一种有风险的选择，并且团队可能永远都不确定产出物的情况。正如“Joel 说软件”中所说：
重要的是要记住，当你从零开始的时候，没有绝对的理由相信你会比你第一次做得好。
查看英文原文： Refactor or Rewrite?
评论