大公司里的优秀工程师为什么会写出烂代码
原始链接: https://www.seangoedecke.com/bad-code-at-big-companies
每隔几年就有人发现，大型科技公司有时会写出非常糟糕的代码。如果你没在大公司工作过，可能很难理解。大厂薪水高，能招到很多牛人；他们的节奏慢，看似有充足的时间把活干好。那么，烂代码究竟是怎么来的？
大多数代码修改是由“新手”完成的
我认为主要原因是：大公司里到处都是在自己专业领域之外工作的工程师。大厂员工的平均任期只有一两年。事实上，大厂的薪酬结构通常会给工程师的任期设定一个隐形的“四年上限”：四年后，入职时授予的股票完全解禁，工程师可能会面临薪水减半的局面。虽然公司会提供年度股票刷新，但这无疑是在鼓励工程师跳槽，去寻找下一份不用每年担心薪水缩水的工作。
如果算上内部调岗，情况更糟。我职业生涯中在单一团队或代码库待过最长的时间是三年。我预计至少每年都会经历一次组织架构调整，有时甚至更频繁。
然而，大厂代码库的寿命远长于此。我参与过的许多服务都有十年甚至更久的历史，多年来换过无数个负责人。这意味着许多大厂工程师一直在“摸着石头过河”。**很大一部分代码是由“新手”修改的：**他们接触这家公司、这个代码库甚至这门编程语言还不到半年。
资深老手
在某种程度上，这个问题被“老手”缓解了：这些工程师在特定系统周围深耕已久，积累了真正的专业知识。他们能进行深度的代码审查，并可靠地拦截明显的问题。但依赖“老手”有两个弊端。
首先，这个机制完全是非正式的。大厂很少刻意去培养对单个系统的长期专业知识，而且一旦有了这种专家，他们似乎也根本不在乎如何留住这些经验。这些工程师经常被调到不同的服务，他们要么全凭热情继续兼顾“老手”的职责，要么彻底放弃，在一个全新的系统里重新变回“新手”。
其次，经验丰富的工程师总是超负荷工作。作为极少数对某个服务有深刻了解的工程师，工作是非常繁重的。你没有足够的时间亲自审查每一次代码修改，或参与每一个决策过程。别忘了，你还有自己的工作要干：如果你把所有时间都花在审查和讨论上，很可能会因为个人产出不足而受到公司的惩罚。
典型的高产工程师
综合来看，大厂里典型的高产工程师是什么样的？他们通常：
- 能力过关，达到了招聘标准并能完成工作，但是
- 正在使用一套对他们来说非常陌生的代码库或语言，或者
- 在忙于自己工作的同时，还要努力应对海量的代码审查。
他们几乎都在赶进度，或者同时应付多个重叠的截止日期。换句话说，他们在一个根本不利于产出高质量代码的环境中，拼尽全力。
这就是那些“明显”糟糕的代码是如何产生的。举个例子，一位初级工程师接手了一个他极不熟悉的系统里的棘手 bug。他花几天时间弄明白，并给出了一个勉强凑合（hacky）的解决方案。一位资深“老手”（如果运气好的话）在百忙中抽了半小时看了一眼，否决了这个方案，并建议了一个稍微好点、至少能跑得通的方法。初级工程师尽力实现了建议、测通、通过简短审查并上线，然后所有参与者立刻投入到更高优先级的工作中。五年后，有人看到了这段代码并惊叹：“哇，太糙了——这么大的软件公司怎么会写出这种烂代码？”
大厂对此习以为常
关于导致这种现象的科技公司内部动态，我写过很多。最直接的是在《像软件公司一样思考》一文中，我认为大厂始终将内部的清晰度（legibility）——即能够一目了然地看到谁在做什么并随意调配的能力——置于生产力之上。大公司很清楚，把工程师当成可替代的螺丝钉随意调动，会破坏他们在单一代码库中积累长期经验的能力。这是一个深思熟虑的权衡。 他们宁可牺牲一定的专业知识和软件质量，也要换取能将优秀工程师快速部署到“当月最热项目”上的能力。
我不知道这是好是坏。对于大厂来说，这似乎很奏效，尤其是在当今“你转向 AI 相关业务的速度有多快”变得如此重要的时期。但如果公司这样做，那就必然会产生真正糟糕的代码。当你要求工程师在他们不熟悉的系统上匆忙赶工时，就会发生这种事。
单个工程师对改变这种动态完全无能为力。尤其是在 2025 年，权力天平已经倾斜，从工程师转向了科技公司高管。作为个人，你能做的最多就是努力成为一名“老手”：至少在一个领域建立专业优势，利用它来阻止最糟糕的修改，并引导人们做出哪怕只是最低限度合理的架构决策。但即便如此，这往往也是在逆势而为，如果处理不当，你可能会被列入绩效改进计划 (PIP) 甚至面临更糟的结果。
纯粹与不纯粹的工程
我认为这很大程度上归结于纯粹与不纯粹的软件工程之间的区别。对于纯粹的工程师——比如开发编程语言这种自包含的纯技术项目——烂代码的唯一解释就是能力不行。但不纯粹的工程师操作起来更像水管工或电工。他们在自己比较陌生的项目上赶工期，即使他们的技术基础无可挑剔，特定环境中的某些东西也总是会让人感到别扭或意外。对于不纯粹的工程师来说，烂代码是不可避免的。只要整体系统运行得足够好，项目就算是成功了。
在大厂，工程师无权决定自己是在做纯粹还是不纯粹的工程。那不是你的代码库！如果公司想把你从数据库底层开发调去构建新的支付系统，他们完全有权这样做。你在陌生系统里可能会犯错——或者你以前数据库团队的同事可能会因为失去你的专业经验而受苦——这都是公司，而非工程师做出的深思熟虑的权衡。
指出大公司的烂代码没什么问题。退一步说，这至少能倒逼高管们为了把负面公关变成正面公关而去修复这些特定问题。但我认为把主要责任推给这些公司的工程师是错误的。如果你能挥舞魔杖让每个工程师的能力都翻倍，你依然会看到烂代码，因为几乎没人能进入一个全新的代码库并迅速做出完美零失误的修改。根本原因是：大多数大厂工程师被迫在陌生的代码库中完成他们的大部分工作。
编辑说明：这篇文章在 Hacker News 和 lobste.rs 上获得了大量评论。
令我惊讶的是，许多评论者觉得这种观点带有一种令人不悦的虚无主义色彩。我认为自己对工作还算乐观。事实上，写这篇文章是为了给受到批评的大厂软件工程师们进行有力的辩护！不过，我发现这篇回应博文非常好地表达了“这太愤世嫉俗了”的立场，我可能很快会写一篇跟进文章（编辑：跟进文章《软件工程师应该稍微有点愤世嫉俗》已发布）。
一些 Hacker News 的评论者对烂代码的产生有不同的理论：缺乏动力、故意打击工程师士气以防止他们组建工会，或者纯粹是为了追求速度。根据我自己的经验，我觉得这些理由缺乏说服力。我的很多同事都非常有动力，而且我根本不相信任何科技公司会故意让其工程师士气低落、心生不满。
少数读者不同意我的观点，他们认为受限股票单位 (RSU) 并不会促使员工离职，因为他们的公司会刷新股票 (stock refreshers)。我对此保留意见。我也拿股票刷新，但如果这没写在合同里，那我觉得这毫无保障——公司只需暂停刷新，就能随意克扣你 50% 的薪酬，这恰恰是一种促使你跳槽以锁定未来四年薪酬的动机。
如果你喜欢这篇文章，可以考虑订阅我的邮件更新，或者[在 Hacker News 上分享](news.ycombinator.com/submitlink?… good engineers write bad code at big companies)。以下是与本文标签相关的另一篇文章预览。
作为 Staff 软件工程师，我如何影响科技公司的政治
许多软件工程师对公司政治抱有宿命论态度。他们认为参与其中毫无意义，因为：
核心观点是：软件工程师根本不具备与真正的政治玩家在同一层面博弈的能力。这是对的！如果软件工程师认为自己应该像在演《权力的游戏》那样去阴谋算计，那绝对是个大错特错的想法。你的计谋会被立刻识破，并被反过来用来对付你、成全别人。算计需要大量的练习和权力，而这两样东西软件工程师通常都不具备。
继续阅读...
