如何确保你永远无法发布:当每个「最佳实践」互相拖垮交付
来源: kore-nordmann.de — 2026-09-02
概述
Kore Nordmann 一篇逆向思维的管理随笔(其系列里各文分别反对多仓库、长寿特性分支、滥用微服务、专职 QA、统一覆盖率指标、把 PR 评审当质量闸门)。这一篇把上述'每步在局部都站得住'的做法一次性全叠起来,论证它们会形成一台'永远不会交付'的机器。核心机制是协调边界会相乘而非相加:一次小改动要加一个共享字段,会触碰四个仓库→变成四个 PR、各自被只看到自己一角的评审人审、四个覆盖率门槛、还要在长分支上对抗数周漂移、跨网络部署不同步、交给 QA 时没人说得清当前到底部署了哪些版本的组合。作者引 1944 年 OSS(CIA 前身)写给欧洲的破坏手册对照——「一切走流程、把事推给尽量大的委员会、为措辞争吵、鼓吹谨慎、让本可一人拍板的事要三个人批准」,与如今无法交付的流水线只差'意图'二字。出路是减法:单仓库去掉跨仓库轴、主干+功能开关去掉长分支轴、进程内边界代替反射式微服务、质量归团队、同步评审去队列、覆盖率分阶段去全局闸门——每一条不是效率技巧,而是删掉一个乘数。
核心要点
- 把多仓库、长分支、微服务、专职 QA、全局覆盖率、逐仓库 PR 评审叠在一起,就造出一台永远交付不了的机器
- 核心机制是协调边界相乘而非相加:加一个字段在四个仓库=四个各看一角的 PR+四个覆盖率门槛+对抗数周漂移
- 部署不同步后连 QA 都答不出'当前到底在测哪些版本的组合'——组合数等于各轴之积而非之和
- 作者引 1944 年 OSS 破坏手册:走流程、推给大委员会、吹毛求疵、鼓吹谨慎——与无法交付的流水线只差意图
- 出路是减法:单仓库、主干+功能开关、进程内边界、质量归团队、同步评审、覆盖率按阶段,每项都是删除一个乘数
- 边界不是免费的:该保留的(需独立扩容的服务、真公开的代码、难缠客户的开关)留下,其余统统砍掉
金句
You did not slow delivery down. You designed it to be impossible and called each step an improvement.(你并没有拖慢交付——你把它设计得不可能完成,却把每一步都称作改进。)
👍 0
👎 0
返回 Lobsters 首页