本文翻译自 Nobody Gets Promoted for Simplicity，原载于 Hacker News。
“简单是一种美德，但需要艰苦的努力才能实现，需要教育才能欣赏。更糟糕的是，复杂的东西更好卖。” — Edsger Dijkstra
我觉得有什么东西正在悄悄地搞垮很多工程团队。在面试中、在晋升材料里、在 design review（设计评审）上：过度构建的工程师总能讲出一个动人的故事，而那些交付最简单可行方案的人却…什么也没有。
当然，这不是故意的。没有人会坐下来专门说”让我们确保过度设计的人获得晋升！”但当公司错误地评估工作时，这就是可能发生的结果（而且一次又一次地发生）。
两个工程师的故事
想象同一团队里的两个工程师。
工程师 A 接到一个功能需求。她分析问题，考虑几个选项，然后选择最简单的方案。一个直接的实现，大概 50 行代码。易读、易测试、易于后人接手。它能工作。她几天内就交付了，然后继续下一个任务。
工程师 B 接到类似的功能。他也分析了问题，但他看到了一个构建更”健壮”方案的机会。他引入了新的抽象层，创建了用于组件间通信的 pub/sub（发布/订阅）系统，添加了配置框架以便该功能对未来的用例”可扩展”。这花了三周时间。有多个 PR。当他分享文档解释这一切时，群里充满了兴奋的表情符号。
现在，晋升时间到了。工程师 B 的工作几乎自动就写成了晋升材料：
“设计并实现了一个可扩展的事件驱动架构，引入了被多个团队采用的可持续抽象层，并构建了支持未来扩展性的配置框架。”
这简直就是在喊”Staff+ 工程师”。
但对于工程师 A 的工作，几乎没什么可说的。”实现了功能 X。”四个字。她的工作实际上更好。但因为她让一切看起来太简单，所以变得不可见。你没法为你没有构建的东西写出一个动人的故事。
没人会因为避免了复杂性而获得晋升。
复杂性看起来很聪明
不是因为它是，而是因为我们的系统被设计成奖励它。而且这个激励问题不是从晋升时才开始，它在你得到这份工作之前就开始了。
想想面试。你在系统设计环节，提出了一个简单的解决方案：单个数据库、一个直接的 API、可能加个缓存层。面试官说：”那可扩展性呢？如果你有一千万用户怎么办？”
于是你添加服务。你添加队列。你添加分片。你在白板上画更多的框。面试官终于看起来满意了。
你刚刚学到的是：复杂性给人留下深刻印象。简单的答案没错，只是不够”有趣”。你可能会把这个教训带入你的职业生涯。
公平地说，面试官有时确实有充分的理由追问扩展性问题；他们想看你在压力下如何思考，以及你是否理解分布式系统。但当候选人的收获是”简单是不够的”时，有些东西就出问题了。
Design Review 里的问题
这也在设计评审中体现出来。一个工程师提出一个干净、简单的方案，然后被问到”我们不应该为未来做些准备吗？”
于是他们回去添加了暂时不需要的层，为可能永远不会出现的问题添加抽象，为没有人提出的需求添加灵活性。不是因为问题需要它，而是因为房间里的人期待它。
我见过工程师（我自己也包括在内）创建抽象来避免重复几行代码，结果却得到了比重复本身更难理解和维护的东西。每一次，这都感觉像是正确的事情。代码看起来更”专业”，更”工程化”。但用户并没有更快地得到功能，下一个接触它的工程师不得不花半天时间理解抽象，然后才能做任何修改。
复杂性有时是正确的选择
让我澄清一下：复杂性有时是正确的选择。如果你在处理数百万笔交易，你可能需要分布式系统。如果你有 10 个团队在同一个产品上工作，你可能需要服务边界。当问题复杂时，解决方案（可能）也应该复杂！
问题不是复杂性本身，而是未经授权的复杂性（unearned complexity）。”我们正在触及数据库限制，需要分片”和”我们可能在三年后触及数据库限制，所以现在就分片”之间有很大的区别。
有些工程师理解这一点。当你看他们的代码和架构时，你会想”嗯，当然”。没有魔法，没有巧妙的东西，没有什么让你觉得自己愚蠢的。而这正是关键所在。
通往资深程度的真正路径不是学习更多的工具和模式，而是学习何时不使用它们。
任何人都可以添加复杂性。有经验和自信的人才能把它排除在外。
那么，我们该怎么办？
说”保持简单”很容易。改变激励结构更难。
如果你是工程师
学会让简单变得可见。工作本身不会说话；不是因为它不好，而是因为大多数系统没有被设计成能听到它。
从你谈论自己工作的方式开始。”实现了功能 X”没什么意义。但是：
“评估了三种方案，包括事件驱动架构和自定义抽象层，确定一个直接的实现满足所有当前和预期的需求，并在两天内交付，六个月内零事故。”
这是同样的简单工作，只是用一种能够捕捉背后判断的方式描述出来。不构建某事的决定也是一个决定，一个重要的决定！相应地记录它。
在设计评审中，当有人问”我们不应该为未来做些准备吗？”时，不要直接屈服然后去加层。试试这样：
“这是以后需要时添加它的成本，这是现在添加它的成本。我认为我们应该等待。”
你不是在抵制，而是在表明你做了功课。你考虑了复杂性，然后选择不接受它。
是的，和你的经理谈谈这个问题。比如：
“我想确保我记录工作的方式反映了我做出的决定，而不仅仅是我写的代码。我们能谈谈如何为我的下一次评审构建这个吗？”
大多数经理会感激这一点，因为你让他们的工作更容易了。你给了他们可以用来为你争取的语言。
如果你是工程领导
这一点的责任在你身上，比任何人都大。无论你是否意识到，你设定了激励。问题是大多数晋升标准基本上都是为了奖励复杂性而设计的，即使它们本意不是如此。”影响”通过某人构建的东西的大小和范围来衡量，这通常很重要！但他们避免了什么也应该重要。
从改变你问的问题开始。在设计评审中，不要问”我们考虑过规模吗？”，试试：
“我们可以交付的最简单版本是什么，哪些具体信号会告诉我们需要更复杂的东西？”
这一个问题就改变了游戏规则：它让简单成为默认，把证明的责任放在复杂性上，而不是反过来！
在晋升讨论中，当某人的材料基本上是一串听起来很厉害的系统列表时，要质疑：
“所有这些都是必要的吗？我们真的需要 pub/sub 系统吗，还是它只是在纸面上看起来不错？”
当你团队上的工程师交付了干净简单的东西时，帮助他们写出这个叙述。”评估了多种方法并选择了最简单的一种来解决问题”确实是一个令人信服的晋升案例，但前提是你真正把它当作一个。
还有一件事：注意你公开庆祝什么。如果你团队频道里的每一个表扬都是大的、复杂的项目，那就是人们会优化的东西。开始认可那些删除代码的工程师。那些说”我们现在不需要这个”并且是对的的人。
结语
归根结底，如果我们继续奖励复杂性而忽视简单性，我们不应该对得到的结果感到惊讶。但修复并不复杂。
我想，这大概就是重点。
核心要点：
- 复杂性在晋升时更容易”包装”成动人故事，简单的工作反而不可见
- 这个激励问题从面试阶段就开始了——简单答案常被视为”不够”
- 真正的资深是知道何时不用某些技术，而不是会用所有技术
- 工程师要学会”让简单可见”——用描述决策而非代码的方式谈工作
- 领导者要改变提问方式——让简单成为默认，把证明责任放在复杂性上