6个软件重写故事的教训

软件重写不能被简单判成禁忌，也不能被当成摆脱遗留代码的万能出口。网景的失败说明，从头重写会吞掉多年时间，让产品停滞、竞争对手追上来，还可能丢掉旧代码里积累的边界案例和用户习惯。Basecamp的成功则说明，有些重写并非因为代码腐烂，而是因为既有用户和既有产品形态把团队锁住，任何改动都会伤害现有工作流，导致产品逐渐只服务过去的客户，不再吸引未来客户。真正的问题不是“要不要重写”，而是现有系统的限制来自哪里：技术债、架构错位、过时平台、招聘困难、产品方向冻结，还是用户迁移成本。可选路径也不只有渐进重构和完全推倒重来，还包括并行新版本、分模块替换、保留旧产品服务老用户、用新产品验证新市场。重写应当服务清晰的业务目标，并承认迁移、功能缺失和时间窗口的代价。若只是厌恶旧代码，重写多半会失败；若旧产品已经阻止公司面向未来，干净的新起点可能反而更诚实。