2016年冬，我在一家创业公司的小团队里搞软件开发。彼时我们有一位真实的企业客户，且软件的第一版也已发布。开发按进度完工，在发布时我欣喜若狂，也十分自豪，看着系统效劳于每天几百万的独立用户，并发送出数千万条短信真是太令人称心了。到了第二年夏天，公司拿到了真实支出，我的职位变成了开发主管，公司又招了些新人，正待蓬勃开展，一切都很美妙。然后我们做了一个庞大的决策失误：决议重写软件——从头末尾。

为什么我们觉得有必要从头重写软件呢?

在第一次编写系统代码时，我们的时间表十分紧迫，必须与时间赛跑，在方案时间内赶完进度。因此无论是设计讨论，还是审查会议都没花太长时间——我们没有时间糜费在这下面——只能匆匆完成一个功用、快速测试，然后赶着去做下一个。我们与别的公司共享办公空间，我还记得其他公司的软件开发都会花很长时间做设计、讨论架构，再花上数周讨论设计模型。

除了设计仓促，本来的系统写得不差，总体来说架构也不错。其中有些意大利面条式的代码，是公司之前做概念验证时留下的，由于这些代码能用，再加上工期紧张，事先我们没有去碰。但后来我们不思索执行优化改良，却决议要从头重写代码的缘由在于：

老旧代码很蹩脚，很难维护;“单一全体式的java架构”对我们的未来开展不利，无法支持有6千万移动用户以及多站点部署的大型运转商;我想要尝试炫酷的新技术，比如Apache Cassandra、虚拟化技术、二进制协议、SOA等等。

结果很不幸：我们压服了全公司以及董事会，完成了愿望。

代码重写之旅

正式的开发时间是从2016年春天末尾的，我们将2017年1月末设定为发布时间。由于方案太过庞大，我们需求更多的人，于是在印度延聘了参谋与几个远程开发者。但是，我们没有充沛预期到维护本来系统、停止新的开发任务与了解客户需求这些并行起来的任务量。

还记得我在文章最末尾说过，我们有一个真实客户么?这位客户是南美最大的移动运营商之一。在我们开发的系统投入运用后，他们末尾对变更和新功用提出要求，因此我们只能继续更新原来的系统。但是，由于这个系统将会被废弃，在更新时我们总有些敷衍塞责，尽能够找借口拒绝了客户许多的新功用需求。结果招致了工期拖延，没能在原定的deadline完成进度。理想上，我们的进度拖延了整整8个月。

不过我们还是先说说结果吧：当项目终于完工时，新系统看起来十分棒，满足一切需求。我们做了负载测试，结果显示新系统能很容易地支持超过1亿的用户，配置集中，查看图表的UI工具也很美观，是时分废弃旧系统，改换新舷?了……

但是客户拒绝了晋级的央求：本来的系统曾经取得了普遍运用，他们的用户曾经末尾依赖旧舷?了，他们完全不想冒风险。长话短说，糜费了几个月之后我们收效甚微。该项目正式宣告失败。

何时需求重写代码

Joel Spolsky剧烈支稳健写代码，他建议大家都不要这样做。不过我不是特别认同：有时分逐渐优化与重构十分困难，独一读懂代码的方式就是重写。此外软件开发人员喜欢编写代码，发明新东西——阅读别人写的代码，尝试了解他们的代码与“思想笼统”会很无聊。不过，优秀的顺序员也是优秀的维护者。

假设你想要重写代码，一定要出于正确的理由，并有着适宜的方案。比如：

有时分在发布新版很久之后，老旧代码仍需维护，维护两个版本的代码需求消耗少量任务，在末尾重写前请依据项目规模评价所需的时间与资源。

想想其他失掉的时机，并比较义务的优先级。

重写大型细叱比小型系统风险更高，思索一下能否逐渐重写。我们同时执行了以下几项任务：切换到新的数据库、运用“SOA”架构、改换为二进制协议，其实本可以逐渐执行这些改换。

思索开发者的成见。在开发者想要学习新技术或新言语的时分，他们会想要运用这些来重写某些代码。不过我不支持这样做，这也是良好环境与文明的标志，但应当将它与风险和机遇做比较。

Michael Meadows对何时有需求停止“大型”重写有着很好的看法：

技术上

组件的耦合度很高，无法独自对某个组件停止修正。重新设计单个组件会招致一连串的变化，不只会影响到相邻的组件，甚至直接影响到一切的组件。技术堆栈太过复杂，未来形状设计需求变更很多的基础架构。出于这个缘由执行完全重写十分必要，逐渐重新设计在这种状况下没有优势。重新设计单个组件无论如何都会招致对该组件的重写，在现有设计中没有可以插入新功用的中央。这种状况下逐渐重新设计没有优势。

政策上

资助商无法了解逐渐重新设计需求对项目停止长期投入。不可避免的是：大少数公司关于在逐渐重新设计上继续消耗预算没有兴味。在完全重写代码时，这种现象也很难避免，但资助商更情愿继续投入，由于他们不想用着半成品的新系统与部分过时的旧系统。系统用户更习气运用“本来的界面”：在这种状况下，政策上不会允许修正系统的重要部分(前端)。但假设完全从头末尾重写，则会绕过这个成绩。用户还会坚持运用“相反的界面”，但这次你还击的理由更为充足。要记得：逐渐重新设计的总成本总是要高于残缺重写代码，但普通来说对企业的影响更小一些。在我看来，假设重写理由充足，公司又有超级优秀的开发者，那么就开工吧。

保持正在开发的项目很风险：糜费少量的时间和金钱重复完成已有功用，同时还会保持完成新功用的时机，有能够激怒客户并招致任务方案推延。假设你正在重写代码，那是你的权利，不过请确保这么做的理由正确，同时了解风险也做了相关方案。

【编辑引荐】

几个小例子通知你, 一行Python代码无能哪些事

顺序员快速处置代码bug的5大技巧

五招帮你正确处置前任顺序员留下的代码

提升代码可读性的10个技巧

扎克伯格13年前写的Facebook网站代码，你见过吗？

(责任编辑：admin)