导读： 本文译自文章 Great code is written twice (or more)。

敏捷开发中的需求进化

近年来，越来越多的团队开始转向敏捷开发（Agile Development）。各种敏捷开发技术其实并不新鲜，大多是在 20 世纪 80 和 90 年代发展形成的。但直到最近，程序员、商业顾问、架构师以及客户才开始真正喜欢并拥抱敏捷开发。

现在的一种普遍共识是：在开始编码前，你不可能把所有的需求都定义完备。需求的确定是一个逐渐发展、进化的过程。通过使用短开发周期（Sprints），我们一步步地开发程序，以多次迭代的方式完成从客户方获取的最新需求。这些都是基于一个进化的思想——就像生活中一样，我们总是通过一步步的改进来达到最佳状态。

代码也需要进化

可是，这就完事了吗？如今大部分的程序员都认识到了需求必定是一步步挖掘出来的，但他们却忘了自己的工作？他们仍然认为项目的框架和架构在项目开始之初就定型了。同样，代码一旦写成，程序就完成了……不是吗？

错。 以我的经验，所有好的程序都至少要写两遍。第一遍往往过于仓促，不能很好地理解需求、实现需求。不错，当看到了某种业务模式，我们知道要提炼出方法，围绕着它实现业务职责。你最终写成的代码是非常好的，但，它不是优秀的。

在我们目前的项目中，几乎所有的重要功能模块都从头重写过数次。慢慢地但明显地，代码变得越来越好。一旦你对某段程序做了第三或第四次增补，或又找到了一个 Bug，你能感觉到这程序什么地方有“异味”。你开始躲避触碰这段程序，你为不需要再处理这段程序而高兴。当有了这样的感觉后，我会怎么做？我会删了这些代码。

可是……这样你就要完全从头开始了！？

你又错了！ 当然，IDE 中的代码清空了，也许一些测试程序会存留下来。但你却对你的代码应该做什么有了扎实的认识。你也知道以前这段代码是什么样的，你知道它以前的隐患和代码异味（Code Smell）在哪里！有了这些认识，你能写出更好，甚至是非常优秀的代码！不错，我们也可以保留这些代码，使用一些重构措施……但你可能再也找不到这样好的从头开始、更好地编写它的机会了。

再次，就像生活中的所有事情：要让事情变得完美，你需要经过多次的进化迭代。对你的需求是这样，对你的架构和代码也是如此。

重写意味着双倍时间吗？

当告诉人们我的观点是“所有的程序都至少写两遍”时，他们担心花费两倍的项目时间。但事实远非如此。下面是原因：

  • 第二次写代码只是用去你初次写代码的很少一部分时间。
  • 重写之后，代码的质量会有明显的提高，可维护性、可扩展性都有改善，包括编程的速度。

祝你好运，坚持重新改进你的代码！

文章来源：

说明： 本文原文发表于 2011 年，虽部分术语与实践背景较早期，但“代码迭代进化”的核心思想至今仍具参考价值。