我们如何决定何时进行重构，何时进行重写
每位开发者都会面临这样的时刻。
代码库运行缓慢。添加新功能耗时过长。新员工难以理解系统。最终，有人会提议进行全面的重写。
团队通常会分成两派。一派想要从头开始；另一派则担心过去重写失败的教训。双方都有道理。
重写并不是万灵药。它往往比计划的时间更长。你最终不得不同时维护两个系统。你甚至可能在新版本中重复同样的错误。
在以下特定情况下，重写是有意义的：
• 数据模型从根本上不符合业务需求。 • 技术已过时，且不再有安全更新。 • 业务需求发生了巨大变化，导致原系统已过时。 • 当前团队中没有人了解系统的运作方式。
即便如此，也不要进行“大爆炸式”的替换。请使用“绞杀者模式”（strangler fig pattern）。在保留旧系统的同时，逐步构建新系统。
大多数情况下，你实际上需要的是重构。
在以下情况下，重构是正确的选择：
• 即使速度较慢，你仍然可以添加功能。 • 团队了解当前的代码。 • 代码混乱仅限于特定的模块。 • 业务无法停止交付新功能。
在做出选择之前，先问问代码为什么会变差。
如果问题是技术债，请重构最糟糕的部分。如果问题是缺乏代码审查或文化缺失，重写也无济于事。你只会用同样的老习惯构建出一堆新的烂摊子。
在决定之前，请询问以下问题：
• 我们能否隔离并修复最糟糕的部分？ • 数据模型是否已无法满足当前的业务需求？ • 如果从头开始，我们会丢失哪些知识？ • 业务是否具备应对长期过渡期的稳定性？
从头开始的感觉很棒，但完成重写才是难点。大多数情况下，一个结构化的重构计划会更安全、更有效。
出处：https://dev.to/daviefano/how-we-decide-when-to-refactor-and-when-to-rewrite-40pk