英文原文：The Effective Engineer - How to Avoid One of the Costliest Mistakes in Software Engineering
编者按：影响软件工程进度的原因有很多种，而代码重写无疑是最耗费时间的变更之一。那么重写的时候需要注意哪些细节才能把资源开销控制到最低或可接受的程度呢？本文作者 Edmond Lau 在其博文中进行了阐述。以下为译文。
前几周，一位年轻的初创企业工程师过来寻求我有关代码重写的建议。其管理层希望她的团队在 4 周内完成 Web 产品的代码重写工作。这已进行了 3 个多月，但估计还要多花 2 个月才能完成。她们每周的工作时间将近 80 多个小时，伴随的还有一堆堆的错误需要更改。时间对于初创公司来说无疑是重中之重，她们该如何处理目前这个困境呢？
在我职业生涯早期，也曾碰到过类似的困境——原本估计 4 个月完成的项目，在通过重写后，最终用了 9 个月才完成。在这个痛苦的过程里，最令人抓狂的事情之一是如果市场出现新的机遇，由这引起的改动是最优先的。换言之，我们只能不断的缝缝补补。打这以后对于项目重写，我变得慎之又慎。
Google Docs的故事
在今年初，我与 Sam Schillace 会面时也讨论过有关重写的问题，它是 Box 的技术副总裁，前 Google Apps 负责人。我向他提了一个问题，“你们工程团队曾遇到过的最昂贵的错误是什么？”
他的回答是，“尝试从零开始开展代码重写。”
Schillace 的创业公司在 2006 年被 Google 收购了，他们当时的团队有 4 人，产品名字是 Writely 即 Google Docs 的前身。在他们发布了一个试验性的 C# 原型作品后，用户数很快就突破了 50 万。加入 Google 后，他们收到的第一个商业任务是进行项目迁移，从而充分利用 Google 的架构体系以实现高容量和高扩展性。每天用户数仍在快速增长，而他们也开始意识到之前所写代码的扩展瓶颈。
我还在 Google 工作时，我知道 Google 的软件堆栈是不支持 C# 的。所以当 Schillace 说到这里时，我很自然地问到，“当你们进行 Writely 到 Google Docs 的转换时，你们是不是只能从零开始？”。
Schillace 的回答是，“是的。”当他们开展重写工作时，有个合伙人提出边转换边重写，因为如果进行彻底推翻，将极大增加工作量。Schillace 并不认同。最终，他说服团队只设置一个非常有限的重写目标，延后其它更多的目标工作。他们定下一个清晰的目标先把系统在 Google 数据中心运转起来，然后再整合 12 种不同的 Google 技术。他们花费了一个星期来调试并最终编译成功。调试过程中，很多错误是由于 Java 和 C# 不同的语义表达引起的，例如==双等号的不同含义。
“这真的真的非常痛苦。”Schillace 说道。继续奋战 12 个星期后，他们最终完成了一个“令人惊讶的，奇怪的，晦涩难懂的”代码库。但它也最终在 Google 数据中心里成功运转了，这也创造了一项纪录—被收购后最快适应 Google 架构的转换项目。如果他们不是摒弃了过多的目标，也许还不能这么快就完成。同时如果他们把更多精力放在代码质量上，时间也会用得更多，因为需要修正一堆堆的正则表达式。相反地，他们的目标是使 Writely 先尽快运转起来。
经验教训
以上所说并不代表重写或推倒重写就是绝对的对或错。MongoDB 的创始人 Eliot Horowitz 曾说过，“我们应该把代码看成有3-5 年的半生命周期，因此应该定期进行更新。”MapReduce，Bigtable 等技术的 Google 架构师 Jeff Dean 也曾说过，“我们不妨以放大 10 倍的规模来设计软件，这样一来我们会发现它的与众不同。”
如果我们一口气就把整个代码进行重写，问题便会出现。我们会倾向于低估了开销而高估了益处。
当我们缺乏经验时，这是很正常的。我们没有足够的底气和知识来阻止过激的进度计划，同时也没有划分好先后优先级的技能。我们可能会想，一个好的工程团队会有人能完成这一切。因此可能会认为只要按部就班、兢兢业业地去做事就万事大吉了。
经过一段时间历练，也不一定就能避免所有错误，因为评估工作仍然复杂而我们也会因为有了经验而高估了自己。这是一个有关虚幻优越感的事例。如果你去调查 100 位驾驶员的驾驶水平，80% 的人会认为自己的水平是中上的。如果调查 100 位教练，68% 的人会认为自己处于前列。类似的情况在 IQ 测试，自我评价等测评中屡见不鲜。所以，对于软件工程师来说，很自然会认为不能按时完成任务只会在较低水平团队中出现，所以当真的出现超期情况时，会使得重写工作一再拖长。
一旦重写出现超期，我们往往会自欺欺人地认为只要多加几天班，多开几次会就能把进度赶上。我们也不会再去想别的途径。一两次或许可以侥幸通过，但长期来看这是不能持续的，“罗马非一天建成”。
最佳的策略是全方位评估推倒重写的价值。如果需要这样做，例如 Schillace 所做的，不妨为项目设置一个有限的目标集合然后使之尽快实现并不断完善。如果你所在的团队陷入了一个一再延迟的项目，你需要站出来，指出商业目标和实际工作的差距—看是否需要减少过多功能，是否需要设置更切实可行的目标，是否把项目看成是沉没成本而彻底终止。对于采取何种策略，需要实事求是，而不能生搬硬套。（编译：伍昆责编：张红月）
相关文章