本文目录导读：
- 为什么说“重写代码”是最不应该的失误？
- 另一个经常被点名、且技术含量极低的失误：“忽略向后兼容性”
- 最无声的失误：“治理模式断层”（独裁者消失）
- 回到你的问题：如果真的要在复盘里写一句“最不应该”，怎么写最深刻？
- 总结：什么样的失误“最不应该”？
这个问题问得很尖锐，也很有价值，因为复盘的意义恰恰在于从“最痛的”失误中提取最普适的教训。
对“最不应该出现”的失误，业界有很多经典案例，但若论最懊恼、最典型、最不该发生的失误，通常会集中在以下几个维度，我可以从动机和类型上帮你拆解，而不是给一个绝对答案,因为不同项目的死法各不相同。
如果说要选一个最具代表性的“最不应该”,那我会首推：
“在未经充分验证的情况下，为了‘重构’而重写核心代码，导致生态崩溃或用户流失。”
这通常被总结为 “Inventing the Wheel Again”（过度自我颠覆）。
下面展开聊聊为什么这类失误最“不应该”,以及它通常在什么场景下发生：
为什么说“重写代码”是最不应该的失误？
（1）它违背了“可进化性”原则 最典型的开源反例是 OpenSolaris（或早期的 LibreOffice 分支冲突）以及 Gnome Shell 的早期。
- 很多项目在发展到一定阶段，核心维护者会觉得“旧代码太烂，我要用最新技术重写”。
- 现实是：旧代码里的“烂”往往是为了兼容无数真实用户场景的“历史包袱”，重写意味着你丢弃了所有在 issue tracker 里沉淀的边界条件。
- 结果：新版本不兼容，插件失效，贡献者因为无法适应新架构而流失，这个失误的“不应该”在于：明明可以通过渐进式重构（Strangler Fig Pattern）解决，却选择了最激进的下策。
（2）它浪费了最宝贵的社区信任 开源的核心资产是信任和贡献者网络，当维护者说“我们要重写”时，等于告诉所有贡献者：“你们之前提交的代码结构一文不值，请重新学一遍。” 这不是技术失误，这是政治和心理学失误，最不应该的地方在于：没有评估技术债务的“利息”和“本金”的关系，低估了社区学习成本。
另一个经常被点名、且技术含量极低的失误：“忽略向后兼容性”
这虽然听起来老生常谈,但它在开源项目中重复犯错率极高。
- 最愚昧的场景：在做一个小改动时，顺手把某个公共 API 的参数名改短了，或者把某个环境变量悄悄删除了。
- 为什么最不应该：这种失误通常不涉及复杂架构，纯粹是细节上的傲慢，因为你本可以在 CHANGELOG 里加一行，或者在弃用前保留两个版本的 Deprecation Warning。
- 教训：这种失误说明项目缺乏 SemVer（语义化版本控制） 的底线意识，或者维护者根本没有考虑过“下游用户”在升级时会因为一个函数的改名而崩溃。
最无声的失误：“治理模式断层”（独裁者消失）
如果你关注近年来的开源风波（如一些热门前端工具），会发现最不该出现的失误是：没有建立继任者计划，导致核心维护者因现实生活原因（工作变动、家庭）停止维护，项目瞬间停滞。
- 为什么最不应该：因为这不是技术问题，是管理问题，开源项目如果能靠三五个核心人员维持，但没有形成梯队建设，那这个项目的“红火”只是泡沫。
- 代价：公司依赖者被迫紧急 Fork（分叉），社区分裂,商业公司甚至因此被迫重写核心依赖。
回到你的问题：如果真的要在复盘里写一句“最不应该”，怎么写最深刻？
如果让你在复盘文档里总结，我建议不要写成“某个具体代码 bug”，而要写流程机制的缺失。
“我们最不应该出现的失误，是在发现性能瓶颈后，没有先做 Profiling 分析，而是靠‘直觉’去微调参数，这导致了三天的无效劳动，并拖慢了迭代节奏。”
或者：
“我们最不应该出现的失误，是为了追求测试覆盖率 100%，写了很多‘硬编码断言’的假测试，导致后期重构时误报率极高，最终大家选择不再运行测试，这种形式主义比没有测试更可怕。”
什么样的失误“最不应该”？
我个人认为，“最不应该”的失误不是那些高深的、受限于技术认知的失误（比如没预见到某种并发问题）,而是：
- 好高骛远（重写）
- 傲慢（忽略兼容）
- 短视（没有继任计划）
这三者都有一个共同点：它是可以通过内部的“冷静期”或“规则”来避免的，但它往往源于“项目维护者的一时热情”或“对社区反馈的无视”。
如果你是在做自己的项目复盘，不妨聚焦一下：你们最大的失误，是花时间写代码，还是没有花时间去“问对方为什么要用这个功能”？后者往往更致命。
你是在复盘哪个具体的开源项目吗？如果是,我们可以聊聊那个项目里最痛的细节。
