你绝不应该做的事，第 I 部分（2000）

对整体推倒重写的总体态度

• 许多评论者仍然认同，完整重写通常风险很高，而且往往更多源于心理因素，而不是必要性。
• 另一些人认为，在较小的系统（数万行 LOC）或真正病态的代码库中，从头开始可能是最务实的选择。
• 也有人批评把“永远不要重写”当作普遍规则；具体情境和规模很重要。

为什么重写如此诱人

• 全新项目更有趣；你可以避开遗留约束、运维痛苦和凌乱的历史包袱。
• 开发者常常相信，借助已知需求和事后视角，这次可以“把它做对”。
• 自己的代码风格总比别人的更容易读，所以现有代码看起来比实际更糟。
• 重写有时会恢复一种自主感和控制感，甚至是无意识地发生的。

支持重构和渐进式变更的理由

• 渐进式重构能保留一个可运行的系统，让你持续交付，并降低风险。
• 删除死代码、隔离糟糕区域、逐步改进架构，被认为更可持续。
• 全面的测试和可靠的文档能显著减少重写冲动，因为它们让变更更安全。
• 有些人把重构与重写之争比作改革与革命：革命通常下场很糟，但拒绝改革也会导致爆炸。

何时重写可能是合理的

• 当现有系统是一个“愤怒的单体/方尖碑”，任何改动都会不可预测地破坏生产环境，而且交付速度已经崩溃。
• 当现有功能中的很大一部分已经不再需要，因此新系统会明显更简单。
• 当最初的语言/框架/架构从根本上阻碍了所需的性能或演进。
• 当代码质量属于“二型糟糕”：毫无结构、没有源代码管理、单个巨大文件、复制粘贴混乱。
• 有几位评论者提到，经验丰富且对领域非常熟悉的团队，成功完成过 5 万到 10 万 LOC 的重写。

失败、规模与组织因素

• 大型、持续数年的重写往往会停滞：团队最终在生产环境中同时维护旧系统和新系统。
• 文中举了一些大公司的重写项目长期搁置、第二系统过度设计，以及团队根本无法执行复杂的全新替换的例子。
• 还有人指出，重写可能是一种隐蔽的职业路线：先启动重写，享受全新项目编码的乐趣，然后在支持和艰难妥协到来之前离开。

其他主题

• 讨论代码到底是更难读还是更难写；多数人同意，真正困难的是深入理解。
• 还讨论了框架作为标准化习惯用法、降低上手成本的一种方式；但也有人反驳说框架同样可能很糟，并不是万能解法。