敏捷开发和最小化功能组合的好处是能持续得到客户反馈，快速迭代，防止无用程序的产生。但是随着时间的推移，如果开发人员不注意，那些为早期客户编 写的程序会变得笨拙不堪，难以维护，无法扩展。你最终会讽刺的得到和敏捷方法完全相反的结果。而且问题的严重程度会随着公司的壮大呈指数级增长。合理的解 决方案是什么？把产品“重构重写”。

对于处于快速变换的市场中的一个公司，这通常是走向灭亡的开始。

看似很合理

我刚好和一位朋友在加州的Palo Alto共进午餐，他是一个科技公司的创始人，现在出任董事会主席。几年前他聘请了一位职业经理做CEO。我询问他工作做的如何(“非常好，谢谢你的关 心，五年来，公司现在的市值已经达到5千万美元”)，但他却想跟我谈一个在他脑子里想了很久的问题。“随着公司的壮大成长，我们对市场变化和客户反馈的反 应越来越迟钝。虽然现在我们的营业收入看起来还不错，但如果我们不能使公司的产品平台跟上客户需求的快速变化，一两年内我们就可能完蛋。我们的CEO没有 技术背景，但他也为公司不能开发出他想要的一些新功能和平台(Facebook,iPhone,Android等)而沮丧。在最近的一次董事会会议上，我 们主管技术的副总裁指出问题的根源在于‘我们的程序积累了太多的技术债务‘，程序实在是糟透了，我们现在根本没法处理。他告诉董事会，如果想在其上做我们 想要的修改，那只能重写这个产品。”我的朋友补充道，“这听起来很合理，所以CEO打算批准这个计划。”

举枪自杀

“那么董事会在听到这种鲁莽的计划后没有做任何反应吗？”我问道。“没有，”朋友回答道，忧郁的摇摇脑袋，“董事会成员都感觉这像个好主意。”

经过更详细的询问后，我了解到他们的已经膨胀巨大的代码库中还保留着公司早期在拓荒阶段为客户开发的代码遗迹。当初针对客户的产品技术设计对于公司当前所面对的新平台的扩展任务来说并不是正确的设计。

我提醒我的这位朋友，我从来没有做过技术管理，所以任何我给他的建议都是来自于经历过这种事情的他人。

引诱非技术出身的CEO的美妙海妖歌声

CEO在其职业生涯中至少会遇到一次这样的“重写”问题。如果他是被请来替代技术创始CEO的，那这个决策似乎很好定 —— 只需要对比一下负责技术的副总裁提供的重写(短期)进度计划和保留老代码、增加新功能(长期)的进度计划就行了。而事实上，这是个愚蠢的决定。技术团队也 许会知道使用旧程序的困难和问题所在，但不会知道如果重写代码库将会面对多少的困难和问题。

曾经经历过重写噩梦或理解程序的复杂性的CEO会知道，没有最初的技术开发团队，重犯以前曾经犯过的错误的几率会非常的高。加之会引入以前不曾犯过的错误，根据墨菲法则，不受约束的乐观主义会使1年期的重写计划变成数年。

我的观点是，CEO和主管技术的副总裁混淆了因果。客户并不要求新的程序。他们要的是新的功能和平台 —— 在当前。他们不太关心这 些功能是由一堆糊涂代码、还是由外星飞船、还是由一个新产品提供的。当你在代码重写的过程中，那些不痴迷于架构血统纯度的竞争对手会扩展他们的功能、平 台，拉拢客户、增加市场份额。这种目前就增加这些功能、还是一两年后再增加这些功能之间的区别代表着收入增长、还是被淘汰出局两种境况之间的区别。

谁想要老的产品

也许这着手搞程序重写最危险的副作用就是当你对旧的程序宣告死亡时却没有可替代的产品存在。当副总裁和CEO宣告公司将来要采用新的程序时，谁还会 去重视这充满问题的旧程序呢？当管理者说出“重写”这个词时，老的程序就死掉了。这后果就是，CEO没有退路可走。如果技术副总裁的开发进程最终是花了4 年时间，而不是设想的1年，那么在这几年期间对于系统新功能的增加不会有任何的进展。

这是一种预测的失败

我认为这看起来像是技术副总裁蓝景设计上的失败 —— 再加之没有代码重写经历的CEO推波助澜 —— 再经过想不出具有建设性的方案的董事会们的搅和。

给朋友的建议？指出市场的快速变化和竞争性，指出这种动作会使公司致命。公司在前进道路上的探索不应该在时间对于市场至关重要的情况下、在客户的需求快速转换的情况下对代码库进行重写。重写是在竞争周期比较长的市场条件下才可行。

我建议他应该在董事会会议上把这些情况陈列清楚。要求CEO详细列出什么时候需要什么样的功能和平台特征，用什么样的手段对进度计划管理的风险进行 控制。弄清楚这种完全不同的技术方案是否真的可行。(是否可以只重构目前需要追加新功能的部分模块？在新的代码库上开发要求的新平台系统？启动一个独立的 分支工作团队来开发新平台？等等)

本文是从 Startup Suicide – Rewriting the Code 这篇文章翻译而来。