作者 | Sean Goedecke

译者 | 核子可乐

编辑 | Tina

每隔几年，各大科技巨头就会闹出一番动静，被人发现产出极其离谱的垃圾代码。这时候没在大厂待过的同学就要问了：既然这里薪资优厚、人才济济，再加上运营节奏稳健，理应能够从容不迫地扎实完成工作。那这些垃圾代码是怎么搞出来的？

多数代码变更出自菜鸟之手

就个人观察，我发现科技大厂中其实充斥着“德不配位”的菜鸟工程师。据调查，大厂员工的平均在职周期仅为一到两年。科技巨头们在设计薪酬方案时，往往倾向将工程师的任期限制在四年左右；四年之后随着期权的全部兑现，工程师们的薪资可能锐减一半。尽管大厂也提供临时性的单年续签政策，但总体上制度更鼓励工程师们到期就另谋高就。

而如果把内部调岗也算进来，情况则更糟。我在单一团队或者项目上待过的最长时间也就是三年，基本上每年都会至少经历一次重组，而且实际频率远不止于此。

与之对应的是，大厂的代码库平均存续周期却远远更长——我经手过的很多服务已经运行了十年以上，期间经历过无数次管辖权变更。这意味着大量工程师们始终处于“摸索状态”。相当比例的代码变更是由“菜鸟”们完成的——其中很多人刚刚入职公司不到半年就开始接触代码库，此前甚至连编程语言都不懂。

为什么不用老手？

老手当然有自己的优势：这些工程师长期参与特定系统的开发，积累下大量扎实的专业往右。他们有能力完成深度代码审查，会快速发展各种典型问题。但对“老手”的过度依赖会带来两个问题：

首先，科技大厂是没有相对正式的“老手”培养及调配制度的。大厂很少以系统性方式针对个人培养其长期专业知识，即使偶尔出现了这样的人才，也不会太关心如何保留这些能力。这类老手工程师常被调往不同服务部门，要么在实质上继续以自愿的形式履行“老手”职责，要么撒手不管、安心在新的岗位上重新成为相对意义上的“菜鸟”。

第二，经验丰富的工程师们永远处于超负荷状态。作为少数掌握特定深度专长的工程师，他们的工作本就繁忙，既无暇亲自审查每项软件变更、也无法参与完整的决策流程。毕竟大家还有自己的工作要做：如果把时间都消耗在审查变更和参与讨论上，我们很可能因为个人产出不足而被约谈。

工程师中的大多数

综合以上因素，科技大厂中占据多数的工程师们到底有着怎样的典型画像？他们往往：

• 能力足以通过招聘部门的要求并胜任工作，但是……

• 要么需要接手他们不太熟悉的代码库或者语言；

• 要么需要在处理大量代码变更的同时，兼顾自己的份内工作。

他们每天被 deadline 折磨得身心俱疲，有时甚至需要同时面对多个项目的轮番轰炸。换言之，他们需要在根本不利于产出优质代码的泥潭当中，努力编写相对正常的成果。

这就是大厂频繁产出垃圾代码的根本原因。例如：初级工程师接手某个相当棘手的工单，但对代码库还一无所知。在耗费几天的摸索之后，他们提出了权宜之计。如果运气够好，会有友善的“老手”花点时间匆匆审阅菜鸟们提交上来的方案，在否决之后给出更加可行的替代建议。初级工程师意图实现新方案，在测试通过后就匆匆部署上线，之后所有参与者随即投入其他高优先级工作。直到五年之后有人注意到这段代码，惊讶地发现“这么垃圾的代码怎么会出现在科技巨头的项目当中？”

科技巨头表示，

“我们做事是这样的”

我之前曾经多次探讨过这个问题，并发现科技巨头们对于内部可调度性的坚持远高于生产力水平——即强调清晰掌握人员分工，并确保可以随意调配。大厂也不傻，知道这种将工程师视为可替换部件随意调动的设计会摧毁他们在单一项目上长期积累的专业知识，但这就是思考之后的刻意之举。大厂宁愿牺牲一部分专业知识和软件质量，也要确保随时能把技术人才投入最紧急、最需要冲刺的核心项目上。

我没法断言这种做法是好是坏，但它显然已经成为科技大厂们的常规操作，同时也埋下了不小的隐患。特别是在如今这个“快速转向 AI”正成为绝对正确的时代，这种强行要求工程师们仓促处理陌生系统的模式，必然产生比过去更多、更垃圾的代码。

个人在这样的模式设计下完全无能为力。特别是在 2025 年，权力的天平已经人工程师端向着大厂管理层倾斜。作为个人从业者，我们能做的也只是成长为“老手”：至少精通某个霍工，用专业知识阻挡这种糟糕的变革，引导团队做出至少大致合理的技术决策。但即便如此，个人 / 小团队也经常会与组织的整体趋势发生冲突，甚至可能面临绩效改进计划（PIP）或其他政策的严厉惩处。

工程实践的纯粹与非纯粹二分

我认为这个问题的本质，很大程度上取决于软件工程的纯粹与非纯粹二分特质。对于纯粹的工程师们——即那些从事独立技术项目（如编程语言）的工程师而言，对于垃圾代码的唯一解释就是水平不行。而非纯粹工程师的工作模式更接近水电工，他们常需要在截止期限的压力下处理相对陌生的项目，即使自身的技术底子相当扎实，也必然会在特定情况下面临棘手或者意外状况。因此后者不可避免会产出垃圾代码，但对他们的考核标准也有区别：只要整体系统能够正常运行，项目就算成功。

在科技大厂，工程师们无权决定自己要当纯粹工程师还是非纯粹工程师，毕竟代码库根本不归你所有！只要上头要求你从数据库基础设施小组转向支付系统开发，你就得乖乖抱着东西过去。你在陌生系统中当然更可能犯错，原本的数据库基础设施小组的同事也可能因为失去你的协助而受困——这些情况公司都知道，但公司就是要让每位员工别那么“纯粹”。

我解释这么多，并不是要为科技大厂搞出的垃圾代码辩解。发现问题并提出问题仍有好处，至少能有效推动具体问题的修复，高管们也可以借此机会将负面公关转化成正面宣传。我只希望大家不要把主要责任都甩在大厂工程师身上——即使这些员工们一夜之间技术实力翻倍，垃圾代码也仍然不会消失，因为几乎没人能在全新的代码库中零失误快速完成修改。再次强调：问题的根源，在于多数大厂员工被迫在陌生的代码库中修修补补。

令我惊讶的是，评论中有很多朋友误以为我在宣扬某种虚无主义。我自认对工作抱有相当乐观的态度，这篇文章的本意是想给大厂的软件工程师们正名，回应批评者们过于严苛的抨击。

除此之外，很多朋友也在评论中提出了关于垃圾代码的其他成因理论：缺乏工作动力、大厂故意打击工程师士气以阻挠其内部联合，或者是纯粹追求速度指标优化。基于个人经验，我认为这些解释相对缺乏说服力。毕竟我的许多同事都充满干劲，我也不大相信有任何大厂会刻意做打压工程师士气、让他们心怀不满的蠢事。

还有一些朋友对期权兑现的问题提出了质疑，表示他们的公司提供期权更新制度。我不太了解这个，虽然我也享受类似的期权归属更新，但只要这方面制度没写入合同，在我看来就意义有限——毕竟公司可以随时调整。这对应的可是高达 50% 的薪酬来源，相信大多数人为了锁定未来四年的收益预期，都会主动选择另换东家。