加载失败
这场讨论围绕一篇观点：在许多公司里，“把事做到足够简单”常常不会像“打造平台/复杂系统”那样在绩效与晋升上得到认可。评论结合具体案例（例如 Amazon 某功能上线时无额外基础设施但后来贡献了九位数收入；某银行拥有 4,000+ 微服务且单次请求触及约 1,100 个服务）与工程理论（如 Fred Brooks 的本质/偶然复杂性、Bill Atkinson 的精简代码轶事）来剖析原因。争论聚焦在技术权衡与组织激励的错配：系统设计面试与可视化产物常鼓励“画更多方框”（Kafka、sharding 等），而实用修正建议包括用 PR/ADR 记录决策并设定量化触发器（如 p95 门限）以及在组织内更主动地展示简化带来的价值。
许多评论指出“简单”只有在缺失时才被注意，复杂方案更容易在纸面上展示影响力：有文档、图表、内部宣讲的“平台化”看起来更值钱，而那句“没出问题”并不算成就。复杂性的持续成本很少向构建者计费，团队后来承担更多暴露面、故障模式和修改前的阅读时间。为此建议把“简单”写成可辨识的决策记录，在 PR/ADR 中列出被放弃的更酷选项并写明升级触发条件（例如 if p95 > X for Y days、加入第二个 producer 等）。评论里还提到面试和绩效评审往往只看“可见的工程量”，因此需要把简洁的影响用具体量化或决策记录表达出来。
部分评论认为标题过于绝对：晋升以影响为导向，不论实现复杂或简单，真正有价值的工作会被识别并奖励。经验丰富的工程师常在复杂系统中先试验，再将功能用最少改动重写出来；他们因被复杂性伤过而更懂得简化问题。也有人举出因合并/去除服务获得晋升的实际例子，并指出通常是初级工程师更倾向于提出复杂方案，而资深工程师才会推动简洁。还有评论补充，既有的大型复杂遗产有时使简单方案在政治上不可行，从而产生表面上的“复杂优先”错觉。
不少人提醒不要把所有复杂性都归为坏：业务边缘用例会累积，简单算法经常只能覆盖大多数场景却漏掉关键例外。举例：计时工资的简单计算覆盖约90%的情况，但轮值津贴、按次通话加班等例外会带来显著额外逻辑。评论引用 Fred Brooks 的 essential/accidental complexity（本质复杂性/偶然复杂性）来区分无法消除的业务复杂度与可优化的实现复杂度；也有提到 Bill Atkinson 的“-2000 lines”轶事来说明极致简洁的价值与难度。讨论强调工程师需判断哪些复杂性是不可避免、哪些是被不当引入的。
评论里有强烈的组织政治视角：架构流行趋势和团队利益会放大复杂性的可见性并阻碍简化。有人举出大型银行有 4,000+ microservices、一次客户端请求会触及约 1,100 个服务的极端案例，说明微服务潮（源自 Netflix 并被 Thoughtworks 等推动）可以制造难以清理的技术债。试图简化常遭遇风险官、架构师和跨团队阻拦，且节约成本的功劳有时被归给他人或被流程吞没（如拆除测试站估算省下约 $1M 却被告知“别人创造了那个价值”）。因此，简化往往不仅是技术决策，还是组织协调与博弈的问题。
评论给出若干可执行的修正：把简洁写进 PR/ADR，列出被放弃方案并设定量化触发器（例如 p95 门限或用户/生产者数量），以便把“有意的简化”变成可评估的贡献。面试与绩效评审也应更重视使系统“更易变更”的长期影响，而非仅看当下的规模或图上方框数。另外，内部宣传和量化证明很重要：需要用 A/B、收入预估或清晰的自评来把节约与价值呈现出来（有评论戏谑用 GPT 写企业式自评）。这些方法同时涉及工程实践与沟通/推广技能。
ADR（Architecture Decision Record）: 记录架构或设计决策的文档/PR 条目，列出所选方案、被放弃的更“酷”选项及何时应升级的触发条件，使简单实现成为可追溯的、有理据的选择。
p95: 第95百分位延迟/响应时间指标，常用作性能门限；评论中以“if p95 > X for Y days”作为量化触发条件来决定何时增加复杂性或扩容。
essential complexity / accidental complexity（本质复杂性/偶然复杂性）: 来自 Fred Brooks 的区分：本质复杂性是问题固有的业务难点，难以消除；偶然复杂性由实现、工具或架构引入，可被优化或剔除。
microservices（微服务架构）: 将系统拆分为大量独立服务的架构风格，评论提到其起源与推广（如 Netflix 与被 Thoughtworks 等推广）以及在大公司造成大量通信、维护和治理成本的风险。