凡事预则立不预则废。在公司里呆久了，总会遇到一些软件项目需要重写代码（或换个全新语言、或进行重大版本升级等）。重写整个系统的风险极大，资源投入到了几个月的重写过程，就没法投资在开发新功能上了。让我们来看看重写代码会失败的五个征兆吧。
重写的价值不够明确
重写代码必须要产生新的价值。因为重写代码和主要的重构工作会耗费大量资源，如果不能在半年内看到有价值的产出，那问题就大了。如果你是这个项目的高管而且你自己不确定重写代码增加的价值是什么，那么可能终止更好；如果你确定你想要重写，那就需要做用户调研或者设计构思，然后重新评估重写这个项目到底是否符合用户的需求。
你正在进行大切换式的重写
切换更容易，大切换重写是所有代码重写的警报，它只适用于非常简单的系统。已经有过大量的论述，关于为什么采用更为渐进的重写方法更好。如果你是一名高管，你需要打电话给你的开发人员，因为他们会努力进行大规模的转换。当然，他们从不使用这些词，而是说在“重新设计”之类的，但这是一回事。问他们 – 什么时候能在生产中看到这些代码？如果答案超过 3 个月 …… 他们可能正在进行转换。
重写的特征速度比遗留系统慢
这很简单：如果您在进行重写时，同时改进现有的旧产品以保持竞争优势（一个好主意），但重写系统无法以更快的速度添加与旧系统相同的功能，重写代码大概永远不会完成。重写研发团队需要由你的超级巨星开发人员组成，他们了解最新的技术，并且了解如何掌握遗留系统的复杂性。此外，确保重写团队能够持续快速地进展！不要在重写的前 2 - 3 个月根据重写速度做出判断，项目开始时总是挺快的，因为还不复杂，但随着时间的推移，它会变慢……
您不与那些曾经是旧系统专家的人合作
旧系统的前开发人员甚至是高级用户，这些人对于重写项目是至关重要的，因为他们了解关于应用程序的所有问题。如果没有这些人，您将成为 Tesler 定律的受害者，最终重写的版本可能价值还低于旧版本，不如原来的好用。请他们帮助做测试，他们能帮助发现重写中的很多细微实现错误，您可能永远无法发现。让这些人参与进来。让他们觉得他们有助于重写（确实是），尽早并经常获得他们的反馈。
你打算删除一些很难的功能
让我们假设您正在重写一个取得了一定成功并积极为用户提供价值的系统。很容易陷入使用“简化”构建名称中的较少功能进行重建的陷阱。但这有意义吗？是的，旧的应用程序可能很慢而且很难看。但想一想 – 你的用户愿意忍受缓慢而丑陋的系统！如果您删除他们正在使用的功能，您的用户将讨厌您。这是否意味着您应该盲目复制旧有系统的功能？当然不是！传统技术所需的一些功能已经变得僵化。现在有类似 OCR 的东西，可以代替表单字段的页面。这意味着您可以自由地重新构想这些功能或创建一个允许您删除操作的新流程，但无论多么诱人，您都无法删除要完成的工作 / 整个故事。
回顾一遍以上要点
我希望你注意到重写意味着要聚焦真正的，立足现在的价值交付。这就是为什么每次重写都必须从彻底的设计阶段开始，以发掘所有增值功能。该 sprint 的核心方法是通过访谈从最终用户和利益相关者那里获取反馈，并通过原型确认您的想法。这确保了产品以您期望的方式满足市场需求，并在重写期间留出创新空间，这是基于真人的真实反馈。
如果你觉得你不得不选择通过重写代码复制一个特别繁重的旧功能和添加新功能，你有一些选择。一种选择是使用 Martin Fowler 的扼杀者模式，您可以在重写时创建新功能，同时相对无缝地与旧功能集成，从而保留这些功能而无需重新创建它们。
本文由网易云社区简译。更多详情请参见原文。
文章来源：网易云社区