程序员想重写代码？

程序员想重写代码？

产品经理最担心听到开发人员这样抱怨：“不能再增加功能了！我们得停下来重写代码。代码库一团糟，就像纸糊的老虎，根本应付不了持续增加的用户。我们维护不下去了！”

这一幕在很多公司上演过，现在依然在不断重演。1999年eBay遭遇这一幕时，公司濒临崩溃的情形超出所有人想象。Friendster几年前也发生过这种情况，当时他们正在向MySpace开放社交网络用户。网景与微软展开浏览器大战时，也发生过类似的事情，最后的结果大家都知道。事实上，没几家公司能渡过难关。

一旦公司陷入这种困境，开发团队往往沦为替罪羊。经验告诉我，这类问题通常是由产品管理失误引发的。因为产品经理一直迫使开发团队满负荷工作，开发尽可能多的功能。所有软件架构都存在功能极限，如果忽视产品的基础技术构架，一旦系统越过崩溃的临界点，就会造成无法挽回的结果。

在重写代码的过程中，用户无法看到产品的任何改进。你可能认为重写代码至多也就几个月，但是实际花费的时间无一例外要多得多。你只能坐在一旁，眼睁睁看着用户投奔竞争对手，而这个时候，竞争对手恰恰在不断地改进产品。

如果你还没有遇到这样的情形，未雨绸缪很有必要——你需要预留一定的研发技术能力，在eBay被称为余量（headroom）。很多因产品迅速膨胀产生的问题都与扩展规模有关，余量意味着避免触及技术能力的上限，为用户数量的增长预留空间，为事务增长预留空间，为新增功能预留空间，保证产品的基础技术构架能够满足团队的要求。

与开发团队合作应该遵循以下原则：在产品管理上为开发团队预留20%的自主时间，让他们自由支配。开发团队可以利用这些时间重写代码、完善架构、重构代码库中有缺陷的部分，或者更换数据库管理系统，提高系统性能，避免“我们需要停下来重写代码”的情形发生。

如果你的糟糕处境已经初现端倪，应该拿出至少20%的资源进行调整，而我担心有些团队连20%都不愿意拿出来。
如果你已经身陷重写的困境，说明公司危在旦夕，这里给出一点建议供你参考。

第一步，针对开发团队确定的产品修改目标并制订切实可行的计划和时间表。通常，有经验的开发团队估计的开发时间八九不离十，但是重写代码是个例外，因为多数团队都没有重写代码的实际经验，估计往往过于乐观。你必须审时度势，仔细检查每处细节，确保计划切实可行。

第二步，只要有可能，最好把重写目标分成几大块，实现递增修改，让用户感受到产品的改进，哪怕会因此把9个月的工作时间延长至2年，也一定要采用这种方式。重写代码时，保证让用户看到功能的改进——即使会占用少则25%，多则50%的开发资源——对保持产品（尤其是互联网产品）的市场占有率至关重要。

第三步，由于开发用户可见功能的资源有限，必须谨慎选择正确的产品特性，并确保产品定义的正确性。

eBay起死回生后，我们发誓绝不重蹈覆辙，马上开始新一轮的代码重写，把危机甩在身后。事实上，由于发展迅速，eBay已经重写了三次代码，最后一次采用了完全不同的编程语言和架构。开发团队花了几年时间，大规模地改写了几百万行代码，同时在不影响用户群的情况下，开发了大量新功能。这是我知道的最惊心动魄的中途重建网站的故事。

临渴掘井不如未雨绸缪，为防患于未然，别忘了预留20%的余量。如果你从未与开发团队谈过这件事，今天就去找他们吧。