“简洁是一种伟大的美德，但实现它需要艰苦的努力，欣赏它需要良好的教育。更糟糕的是，复杂往往更有市场。” —— 艾兹格·迪科斯彻 (Edsger Dijkstra)
我认为，有一种现象正悄无声息地毁掉许多工程团队。无论是在面试、晋升报告还是设计评审中：过度设计的工程师总能讲出一个动听的故事，而那个交付了“达成目标的最简方案”的人，却往往一无所获。
当然，这并非谁的本意。没人会坐下来开会说：“咱们得确保那些把事情搞复杂的人能升职！”但当公司用错误的方式评估工作时，这种情况就会一次又一次地发生。
想象一下同一团队中的两名工程师。
工程师 A 接到一个功能需求。她审视问题，对比了几种方案，选择了最简单的一种。代码实现清晰直观，大约 50 行。易读、易测，后来者也极易上手。功能上线了，她只花了两天时间，接着便投身于下一个任务。
工程师 B 接到了类似的需求。他也审视了问题，但他看到了一个构建更“健壮”系统的机会。他引入了一个新的抽象层，创建了一套用于组件通信的发布/订阅系统，还增加了一个配置框架，美其名曰为了未来用例的“可扩展性”。这花了三周时间，提交了无数个 PR。当他在文档中展示这一切时，收获了一堆兴奋的表情符号。
到了晋升季，工程师 B 的工作几乎能自动转化成一份完美的晋升报告：“设计并实现了可扩展的事件驱动架构，引入了被多团队采用的可复用抽象层，并构建了支持未来扩展的配置框架。”这简直是在大声宣告：此人具备“主任工程师（Staff+）”的素质。
而对于工程师 A 的工作，几乎无话可说：“实现了 X 功能。”寥寥数语。她的工作其实更出色，但因为她把事情做得太简单，反而变得“不可见”了。你没法为一个没去构建的东西写出引人入胜的叙事。没人会因为规避了复杂性而获得晋升。
复杂性看起来很高级。这并非因为它真的高级，而是因为我们的制度倾向于奖励它。这种激励错位甚至在入职前就开始了。
想想系统设计面试。如果你提出一个简单的方案：单台数据库、直观的 API，或许加个缓存层。面试官会问：“那扩展性呢？如果有千万级用户怎么办？”于是你开始增加服务、引入队列、搞数据库分片。你在白板上画出越来越多的方框。面试官终于露出了满意的神情。
你学到的一课是：复杂性才能打动人。简单的答案并没错，只是不够“有趣”。你可能会带着这个教训开启职业生涯。公平地说，面试官施压有时是为了考察你在压力下的思考能力以及对分布式系统的理解。但如果候选人得出的结论是“简单是不够的”，那一定是哪里出了问题。
这种现象也出现在设计评审中。当一名工程师提出简洁方案时，总会被问到：“我们难道不该考虑‘面向未来’吗？”于是他们回去加上了暂时不需要的层级，为可能永远不会出现的问题做抽象，为没人提过的需求留出灵活性。这不是因为问题本身需要，而是因为评审室里的氛围预期如此。
我见过许多工程师（我自己也曾是其中之一），为了避免重复几行代码而创建了复杂的抽象，结果导致代码比重复时更难理解和维护。每次这么做时，都觉得自己在做“正确的事”，觉得代码看起来更“专业”、更有“工程感”。但用户并没有因此更快用上功能，而下一位接手代码的人得花半天时间去理解那层抽象，才能改动一行代码。
在此我要澄清：复杂性有时是必要的。如果你在处理每秒百万级的交易，你确实需要分布式系统；如果你有 10 个团队在同一个产品上协作，你确实需要服务边界。当问题本身很复杂时，解决方案通常也必须复杂。
问题不在于复杂性本身，而在于“不劳而获”的复杂性。 “数据库达到极限需要分片”与“三年后可能达到极限所以现在就分片”之间，有着本质的区别。
优秀的工程师明白这一点。当你审视他们的代码和架构时，你会想：“嗯，理应如此。”没有魔法，没有故弄玄虚，没有任何让你觉得自己智商不够用的地方。而这正是精髓所在。
通往资深工程师的真实路径，不在于掌握更多工具和模式，而在于学会何时不去使用它们。任何人都能量化复杂，唯有经验与自信才能留白。
那么，我们该怎么办？毕竟，“保持简单”说起来容易，改变激励机制却很难。
如果你是工程师，要意识到简洁需要被“可见化”。工作成果不会自己说话，不是因为它不够好，而是因为大多数系统听不懂“简洁”的语言。
从描述工作的方式开始。不要只写“实现了 X 功能”，试着这样写：“评估了包括事件驱动架构和自定义抽象层在内的三种方案，判定直观的实现方式即可满足当前及预期的需求，仅用两天即完成交付，且上线半年零事故。”同样是简单的工作，这种描述捕捉到了背后的判断力。决定“不建什么”也是一种决策，而且是至关重要的决策！ 请据此记录它。
在设计评审中，当有人问“我们不该面向未来吗？”时，不要直接妥协。试着回答：“如果以后需要，增加那个功能的成本是多少；而现在就加，我们要付出什么代价。我认为现在应该等待。”你不是在顶撞，而是在展示你做过功课——你权衡了复杂性，并选择了拒绝。
此外，主动与你的主管沟通。你可以说：“我希望我的工作记录能体现我的决策过程，而不只是代码产出。我们能聊聊在下次考评中如何体现这一点吗？”大多数主管会很欣赏这种做法，因为你让他们的工作变得轻松了——你给了他们为你争取利益的素材。
如果做完这一切，你的团队依然只提拔那些构建冗余系统的人……那这也是一个非常有用的信号。它告诉你这里的企业文化究竟崇尚什么。有些文化真心推崇简洁，有些则是口头支持、实则奖励复杂。如果你处于后者，你要么加入这场游戏，要么找一个能识得“判断力”真金的地方。
如果你是工程领导者，你的责任比谁都大。无论是否有意，激励机制是由你设定的。问题在于，大多数晋升标准在设计之初就倾向于奖励复杂性。 “影响力”往往通过项目的规模和范畴来衡量，这固然重要，但避开了什么同样重要。
所以，从改变提问方式开始。在设计评审中，不要只问“考虑过扩展吗？”，试着问：“能上线的、最简单的版本是什么？什么样的具体信号会提醒我们必须引入复杂性？” 这个问题改变了博弈规则：它让简洁成为默认选项，把证明负担丢给了“复杂性”。
在晋升讨论中，当看到一份堆砌了各种高大上系统的报告时，多问一句：“这些真的必要吗？我们真的需要这个发布/订阅系统，还是它只是在报告里看起来很厉害？”当团队成员交付了简洁优雅的作品时，帮他们润色叙事。“评估多种方案并选择了解决问题的最简路径”就是一个极具说服力的晋升理由，前提是你得真正把它当回事。
还有一点：留意你公开表扬的事情。如果团队频道里的每一次“点赞”都给了那些庞大复杂的项目，大家就会以此为目标。试着去表彰那个删减了代码的人，表彰那个说“我们现在不需要这个”并被证明是正确的人。
归根结底，如果我们持续奖励复杂、忽视简洁，那么得到一个臃肿不堪的系统也就不足为奇。其实，解决之道并不复杂——我想，这正是我们要表达的核心。