“烂代码”扎堆，为何优秀工程师一进大厂就“变菜”？

大厂为何难逃烂代码困局？

原创于 2025-12-05 17:23:34 发布 · 571 阅读

CC 4.0 BY-SA版权

【优快云编者按】在大众认知里，大厂手握顶尖人才与资源，本应是高质量代码的“代名词”。但实际上，关于“大厂代码粗糙”的吐槽却频繁发生。本文作者以一线大厂研发经验为切口，撕开了“优秀工程师写烂代码”的表象：从薪酬结构导致的人员高频流动，到资深工程师的超负荷困境，再到公司战略对“灵活性”的刻意倾斜，拆解出了代码质量与组织机制间的深层矛盾。

原文链接：https://www.seangoedecke.com/bad-code-at-big-companies/

作者 | Sean Goedecke 翻译 | 郑丽媛

出品 | 优快云（ID：优快云news）

几乎每隔几年，就会有人惊讶地发现：大厂居然也会产出又乱又糟的代码。

如果你没在大公司待过，很难理解这是怎么发生的。毕竟——大厂薪资足够高，能吸引大量优秀工程师；研发节奏不快，外界甚至觉得工程师可以慢慢打磨。

那问题就来了：这些烂代码是怎么被写出来的？

大厂里的大部分改动，其实都来自“新手”

核心原因在于：大厂里太多工程师都在自己不擅长的领域工作。

有调查显示，大厂员工平均任期往往只有 1-2 年。而事实上，大厂的薪酬体系本身就是为“四年上限”设计的——四年后初始股票发完，工程师等于被“降薪 50%”。

虽然公司会继续提供年度股票刷新奖励，但你永远不知道下一年还能不能拿到，这自然会刺激大家跳槽锁定下一份长期激励。如果把内部调岗也算上，情况就更糟了。

我职业生涯中在同一个团队、同一份代码库上工作最久的时间，也不过是刚入行时的三年。现在，我几乎每年都会经历至少一次组织架构调整，有时甚至更频繁。

但大厂代码库的“寿命”比工程师的任期要长得多，像我维护的很多服务已经运行十年甚至更久，中途换过一批又一批负责人——这意味着：无数工程师一直处于“摸索中”状态。

而这样的结果就是：有相当高比例的代码变更，都出自那些入职不到半年、刚熟悉公司流程、代码库甚至编程语言的“新手”。

“老手”能救一部分，但救不了全部

确实，大厂里也有一些“老手”：长期围绕某个系统工作，积累了真正的深度经验。他们能通过深度代码审查，精准揪出明显的问题。

但如果依赖“老手”，就会有两大结构性缺陷：

(1) 完全是“民间体系”，公司本身不培养

很多大厂，其实并不会刻意培养工程师在特定系统上的长期专业能力，也不太在意如何长期留住这种经验。所以这些“老手”经常被调到其他业务线，他们要么自愿继续兼职做老代码库的顾问，要么彻底放弃、成为另一个新系统中的“新手”。

(2) “老手”永远超负荷

一个系统里能真正懂全局的人通常就那么几个，他们每天都很忙：自己有 KPI、要补位做代码审查，还得参与重要决策。如果他们花太多时间在审查别人的代码上，很可能被公司认为“个人产出不够”，影响绩效、晋升甚至面临警告。

那些“明显很烂的代码”到底是怎么被写出来的？

综合这些因素，大厂里的典型工程师往往是这样的：

他们足够优秀，能通过大厂的招聘门槛，也能胜任本职工作，但是——

● 要么正在处理自己不熟悉的语言或代码库；

● 要么一边要应对海量的代码变更，一边还要兼顾自己的核心任务。

他们几乎永远在赶 Deadline，甚至要同时应对多个项目的重叠 Deadline。换句话说，他们是在一个根本不支持产出高质量代码的环境中，尽力做到最好。

于是，这就是“明显很烂的代码”出现的全过程：

某个“新手”接到一个完全不熟悉的代码库中的 Bug 要求修复，他花了几天时间摸索入门，想出了一个临时解决方案；某个“老手”如果有时间，会匆匆扫一眼，否了它，然后给出一个至少能运行的方案；“新手”照着改，并做了基础测试，经过简单审查就上线了——所有人随即转向优先级更高的工作。五年后，某位倒霉的新维护者看到这段代码，不禁疑惑：“这么粗糙的代码，怎么会出现在大厂里？”

重点来了：大厂其实完全接受这种结果

我之前就提过，大厂完全清楚把工程师当“可替换资源”四处调动，会损失长期代码库经验，但这是一种刻意的权衡——他们放弃了部分专业深度和软件质量，换取了快速将熟练工程师投入到“月度重点问题”中的灵活性。

我不知道这种做法是好是坏，但它显然对大厂是有效的——尤其是在当前“快速转向 AI 相关业务”至关重要的环境下。可既然选择了这种模式，大厂也愿意接受随之而来的结果：工程师在陌生系统里匆忙产出的劣质代码。

显然，单个工程师完全无力改变这种现状。尤其在 2025，组织权力已经从工程师侧倾向管理层。作为个人，你唯一能做的就是争取成为“老手”：在至少一个领域积累专业知识，用它来阻止糟糕代码的产生，并引导团队做出至少合理的技术决策。但即便如此，这往往也是在与组织趋势对抗——如果处理不当，甚至会被 PIP（绩效改进计划）盯上。

“纯粹”工程 vs. “非纯粹”工程

这一切的核心，在我看来，在于 “纯粹软件工程” 与 “非纯粹软件工程” 的区别：

● 对于纯粹工程师，比如专注于编程语言等独立技术项目的工程师来说，糟糕代码的唯一解释就是能力不足；

● 但非纯粹工程师的工作更像是水管工或电工：他们要在 Deadline 前完成自己相对陌生的项目，即便技术基础无可挑剔，也总会遇到一些特殊场景下的棘手问题。对他们而言，糟糕的代码是不可避免的——只要整个系统还能跑，项目就算成功。

可问题在于：在大厂里，工程师几乎没办法选择自己做的是纯粹工程还是非纯粹工程——公司让你去哪，你就必须去哪。

我认为，指出大厂的糟糕代码本身无可厚非，甚至还能促进修复，但如果把主要责任归咎于这些公司的工程师，那就错了。即使你给予每个工程师加倍的能力，也无法阻止烂代码发生，因为：几乎没人能在完全陌生的代码库里零失误地高效贡献。

所以真正的问题根源是：大厂的大多数工程师，被迫在不熟悉的代码库上完成大部分工作。而这是一种组织模式，而非个人问题。

【活动分享】2025 年是 C++ 正式发布以来的 40 周年，也是全球 C++ 及系统软件技术大会举办 20 周年。这一次，C++ 之父 Bjarne Stroustrup 将再次亲临「2025 全球 C++及系统软件技术大会」现场，与全球顶尖的系统软件工程师、编译器专家、AI 基础设施研究者同台对话。

本次大会共设立现代 C++ 最佳实践、架构与设计演化、软件质量建设、安全与可靠、研发效能、大模型驱动的软件开发、AI 算力与优化、异构计算、高性能与低时延、并发与并行、系统级软件、嵌入式系统十二大主题，共同构建了一个全面而立体的知识体系，确保每一位参会者——无论是语言爱好者、系统架构师、性能优化工程师，还是技术管理者——都能在这里找到自己的坐标，收获深刻的洞见与启发。详情参考官网：https://cpp-summit.org/