好的代码至少要修改两遍

黄河敏捷开发

2014-11-25

近些年来，越来越多的人开始转向敏捷开发，而且这些敏捷开发的技术已不再新鲜，大多都是在 80 和 90 年代设计形成的。但是，最近几年，程序员，特别是一些商业顾问，架构师和客户开始喜欢上了敏捷开发。

不断进化的需求

现如今，有一个普遍的认识就是在你开始项目编程之前，你不可能写下所有的需求，这些需求的确定需要一个不断进化的过程。在较短的开发周期中，我们不断的完善程序，多次迭代从而满足客户提出的最新需求。这些都是基于进化的原则，就像我们的生活，你是一步一步的向前从而做得更好。

不断进化的代码

这就可以了吗？现在的大多数程序员都已经认识到了需求是不断进化和完善的。但还不够，他们依旧认为项目使用的框架和架构应该在项目开始的时候就确定了，而且代码一旦完成，就一切都 OK 了。

错。根据我的经验，所有优秀的代码都至少要写两遍。第一遍写代码时，你通常会很匆忙，不能很好的理解并实现需求。当然，如果你看过一些设计模式，知道一些方法，你最终的代码可能会写得不错，但它绝不是最优秀的。少写一些无谓的代码，多一些思考。

在我们现在的项目中，几乎所有重要的功能都要从零开始写，并且重复修改很多次。这虽然很慢，但确定的是写出的代码越来越好了。当你修改某一部分的代码已经三到四次，或又修补了这里的一个 bug，你就开始有点想躲避这部分代码，如果不再处理它你就会很高兴。当有了这样的想法后，你肯定会删了这些代码。那就又要一切从头开始了吗？

再一次错。确实，IDE 里空了，代码没了，或许只有一些测试程序还在。但是，你已经对你写的这些代码有了深刻的认识，你知道它是什么样的，你也知道它的问题出在哪。在此基础上，你现在可以写出更好，甚至是优秀的代码。当然了，我们也可以保留之前的代码，进行一些重构等等，但都不如从头开始，更好的做出它。

这和生活中的道理依然是一样的，要想把一件事做到极致，就要多次的重复和进化。你的需求是这样，你的代码和架构也要这样。