从厨房漏水到行业标准：一个荒诞的 TDD（技术债）演化寓言

这是一个真实又荒诞的技术故事，讲述一个临时补丁如何一步步演变成公司核心系统，甚至被奉为行业“最佳实践”。

来源：https://github.com/bschug/tdd

一切从一滩水开始

有一天，产品经理发现厨房地上积了一滩水。这让他很不爽，于是直接去找开发者要个说法。

开发者的第一反应是：

厨房本来就需要水，不然咖啡机和洗碗机怎么用？

你看，两个人站在了完全不同的角度。产品经理关注的是“肉眼可见的异常”，而开发者纠结于“现象存在的合理性”。问题的本质，就在这种模糊的沟通中被掩盖了。

第一次处理：毛巾 + 桶

开发者亲自到现场查看，水槽是有点漏水，但完全解释不了地上那滩水的规模。他按照惯例，给出了标准处理方案：

• 用毛巾擦干地面。
• 在漏水点下方放一个水桶接水。
• 在项目管理工具（比如 Jira）的工单里备注：“暂时无法复现，持续观察。”

这在软件开发中太常见了，可以概括为 “先挂着，后观察”。问题没有解决，只是被暂时搁置了。

真正原因：洗碗机软管破裂

没过多久，问题再次出现，而且水量更大。这次终于找到了根源：洗碗机的排水软管破了一个洞，热水直接喷溅出来。

开发者当场用毛巾把漏点裹住，下面的桶接着水。然后，他把工单状态改为“已完成”，并附加了一条备注：“后续需要更换软管。”

这是第一个关键转折点：一个临时办法，被当成了真正的解决方案。最初的“观察”状态，此刻悄无声息地变成了“解决”。

技术债的“合理化”

第二天，产品经理和财务一起过来评估。他们的判断逻辑非常“业务”：

• 系统（厨房）还能用。
• 不影响核心业务（做饭、泡咖啡）。
• 修复成本（换软管）不值得投入。

他们甚至提出了“优化”建议：“那个桶有点碍事，能不能去掉？” 开发者坚持保留了桶，但整个决策方向已经确定：不修。这个临时补丁，开始背负上第一笔“技术债”。

系统持续劣化

接下来，厨房的水龙头也开始滴水，渐渐变成了细流。财务部门开始注意到水费账单在悄悄上涨。

然而，依然没有人愿意动真格去修复根本问题。最后，开发者采取了一个更“彻底”的措施：直接关掉了水源总闸。

这映射到软件世界，就相当于：关闭非核心功能、服务降级、或者直接限流。通过牺牲能力和体验，来维持系统不崩溃。

意外的“产品创新”

水源一关，咖啡机没法用了。产品经理看着桶里接的废水，灵机一动，用它泡了一杯咖啡。

结果出人意料：

• 客户觉得这咖啡味道“很独特”。
• 他们竟然愿意为此支付更高的价钱。

荒诞但真实的一幕发生了：一个错误，因为奇特的用户反馈，被“正向”解读了。

公司战略大转向

管理层看到了这个“意外之喜”，果断做出战略决策：

• 让洗碗机 24 小时运行，作为“废水咖啡”的原料生产系统。
• “毛巾+水桶”这套临时装置，升级为核心生产设备。
• 公司业务转型，开始正式销售“废水咖啡”。

你看，一个临时的补丁，就这样戏剧性地变成了公司的核心竞争力和主营业务。

围绕“错误”构建组织

更荒诞的事情接踵而至。公司开始围绕这套临时系统建立正式组织：

• 招聘专门的“毛巾管理员”岗位。
• 安排人员专职维护这套漏水-接水系统。
• 持续优化“毛巾更换流程”和“水桶清空SOP”。

甚至出现了这样的局面：负责维护补丁的运维岗位，其重要性逐渐超过了开发新功能的工程师。整个组织资源开始向“维持错误”倾斜。

问题进一步恶化

时间久了，反复使用的毛巾开始发霉，产生了明显的健康隐患。

但产品经理的第一反应不是解决问题，而是提出了一个“产品猜想”：

会不会……正是这些霉菌，带来了咖啡的独特风味？

典型的认知扭曲出现了：错误被强行解释为优势，缺陷被包装成特色。为了避免承认早期的决策失误，系统选择在错误的道路上狂奔。

“方法论”的诞生

后来，这位开发者离职去做技术分享，给这段奇葩经历起了个正式的名字：

毛巾驱动开发（Towel Driven Development, TDD）

他的分享内容包括：

• 如何快速“止血”（止漏）。
• 如何实现“高可用”（多毛巾轮换方案）。
• 如何保证“零停机”更换毛巾和水桶。

谁能想到，这套局部最优的临时方案，竟然开始被行业模仿：

• 投资人推动其成为“创新模式”。
• 相关的培训、认证、甚至框架相继出现。

一个本应被清除的荒诞补丁，就这样被成功包装成了 “行业标准”与“最佳实践”。

讽刺的结局

终于有一天，有人通过实验发现：

在不漏水、使用干净水源的情况下，其实能做出品质更好、更稳定的咖啡。

但已经没人愿意改变现状了，因为：

• 围绕旧系统已经建立了完整的流程体系。
• 形成了稳固的利益链条（岗位、供应商、培训）。
• 所有人的思维都形成了路径依赖。

那个临时方案，彻底固化为不可撼动的标准操作流程。

给我们的启示

1. 技术债源于选择：很多技术债并非因为“不会修”，而是在特定时刻，权衡利弊后 “选择不修” 。每一次对临时方案的纵容，都是在为未来埋雷。
2. 临时方案的演化路径：其生命周期通常是：

   临时补丁 → 被接受 → 产生依赖 → 成为标准 → 无法替代

3. 警惕“事故产物型”最佳实践：许多被推崇的 “最佳实践” ，可能只是特定历史条件下事故的产物。脱离其原始上下文，生搬硬套往往会显得荒诞。
4. 强烈的警示信号：如果你的组织开始为某个补丁设立专职岗位、不断优化补丁流程、并围绕它制定各种规范，这往往意味着，整个系统已经在围绕一个 “错误” 核心运转。这值得所有技术管理者深思，也是我们在进行 系统设计 时需要极力避免的陷阱。

最后一句

你或许不想看餐厅的后厨，但很多软件系统的“后厨”，可能比这个故事还要混乱。

这个故事虽然夸张，但其反映的 技术债 积累、认知固化和路径依赖问题，在真实的软件开发与团队管理中屡见不鲜。在 云栈社区 的日常交流中，我们也常听到开发者们分享类似“哭笑不得”的经历。保持清醒，敢于重构，或许是避免陷入“毛巾驱动开发”困境的关键。