每周跟踪AI热点新闻动向和震撼发展 想要探索生成式人工智能的前沿进展吗？订阅我们的简报，深入解析最新的技术突破、实际应用案例和未来的趋势。与全球数同行一同，从行业内部的深度分析和实用指南中受益。不要错过这个机会，成为AI领域的领跑者。点击订阅，与未来同行！ 订阅：https://rengongzhineng.io/
大型公司中优秀工程师为何也会写出糟糕代码
每隔几年，总有人注意到大型科技公司有时会产出令人意外的粗糙代码。
如果你没有在大公司工作过，可能很难理解这是怎么发生的。
大型科技公司薪资丰厚，足以吸引许多能力出众的工程师。
他们的开发节奏也相对缓慢，看起来似乎有充足时间打磨出高质量的作品。
那糟糕的代码究竟是如何出现的？
大多数代码改动都由“新人”完成
主要原因在于：大型公司里充满了在非擅长领域工作的工程师。
平均来看，大型科技公司的员工任期通常只有一到两年。
事实上，这些公司的薪酬结构本身就设计成让工程师的工作周期被限制在四年之内：
四年后，最初的股票赠与完全归属，意味着工程师可能面临 50% 的收入骤减。
公司虽然会临时提供每年的“股票刷新”（refresh），但这显然会促使工程师去寻找下一份能重新锁定四年股票的新工作。
如果把公司内部的“团队调动”也算进去，情况就更糟了。
笔者职业生涯中，在同一个团队或同一代码库待得最长的时间是三年——那还是刚入行时。
如今几乎每年都会经历一次重组，甚至更频繁。
然而，大公司中代码库的寿命却远远更长。
笔者目前维护的许多服务已有十年以上历史，期间换过无数个负责人。
这意味着，许多工程师总是在“摸索中工作”。
相当高比例的代码改动都出自“新手”之手——也就是那些刚加入公司、刚接触这套代码库、甚至刚开始学习这门编程语言不到六个月的人。
“老手”的作用
在某种程度上，这个问题由所谓的“老手”部分缓解。
这些工程师长期围绕某个系统工作，积累了深厚的经验，能在代码审查中指出明显问题。
但依赖“老手”有两个问题。
首先，这完全是非正式机制。
大公司在培养系统级长期专家方面投入甚少，甚至在获得专家后也几乎不在意如何留住他们。
这些人常常被调往其他服务，只能出于“志愿”心态继续维护旧系统，否则也得像新人一样在新系统里重新摸索。
其次，有经验的工程师几乎总是超负荷。
在某个服务上拥有深度专业知识的人总是事务繁忙，
根本没有时间亲自审查每一次改动，也无法参与所有技术决策。
别忘了，他们也有自己的工作任务——
如果他们把全部精力花在评审和会议上，反而会因为个人产出不足而被公司批评。
“中位数级别”的高产工程师
把这些因素放在一起，大型公司中“中位数级别的高产工程师”通常是这样的：
能力足够通过招聘门槛，具备完成任务的水平；
但要么正在使用对自己来说全新的代码库或编程语言；
要么正努力应对大量代码改动的同时，还要完成自己的工作任务。
他们几乎都在赶工期，或者同时被多个项目的重叠截止日期压着。
换句话说，他们尽力而为，但环境本身并不支持产出高质量代码。
这就是“显而易见的糟糕代码”出现的原因。
例如，一个初级工程师接到修复某个讨厌 bug 的任务，对这份代码库几乎一无所知。
他花了几天时间摸索，想出一个临时补丁式的解决方案。
一位“老手”（如果幸运的话）在空闲半小时内看了一眼，否决原方案，并建议一个稍好、至少能用的替代办法。
初级工程师尽力实现、简单测试通过、经过一次简短评审后便上线。
所有人立刻转向下一个更高优先级的任务。
五年后，有人看到这段代码，惊叹道：“天哪，这写得太糟糕了——这么大的公司怎么会有人写出这种东西？”
大型公司对此心知肚明
作者指出，他曾在多篇文章中分析这种公司内部的技术动态。
最直接的一篇《像软件公司一样思考》中，他认为大公司始终优先追求内部可读性——
即“能一眼看出谁在做什么，并能随时更换人员”的能力——
而非生产力本身。
他们很清楚，让工程师“可替换”、频繁调动，会削弱在某一代码库中积累深度经验的能力。
但这是一种有意为之的权衡：
公司愿意牺牲一部分专业性与代码质量，以换取在“本月最热门问题”出现时，能迅速调动熟练工程师的灵活性。
这种策略究竟是好是坏，作者也不确定。
但显然，它对大公司运作是有效的——尤其在如今“你能多快转向 AI 相关项目”成为竞争核心的时代。
既然公司主动选择这种模式，那么产出一些真正糟糕的代码就不可避免。
当你要求工程师在不熟悉的系统上快速交付成果时，这就是自然后果。
个体工程师对此完全无能为力。
尤其在 2025 年，如今权力的天平更加倾向于公司高层而非工程师。
个人能做的最好努力，就是尽量成为一个“老手”：
在至少一个领域积累专业知识，用它来阻止最糟糕的改动，
并在团队中引导出至少“合理”的技术决策。
但这常常是逆流而行，若处理不当，甚至可能导致你被绩效警告（PIP）或更糟的后果。
“纯粹”与“不纯粹”的工程
作者认为，这一切归根结底源于“纯粹工程”与“不纯粹工程”的区别。
对“纯粹工程师”而言——
他们从事的是自成体系的技术项目，例如编程语言或算法开发。
在他们看来，糟糕的代码只可能出自能力不足。
而“不纯粹工程师”更像水管工或电工。
他们总在赶进度、处理新项目，即便技术功底扎实，
也不可避免地会被某些奇怪、意外的环境因素拖累。
在这种情境下，写出一些“不完美代码”几乎是必然的。
只要系统整体能正常运行，项目就算成功。
在大型公司中，工程师往往无法选择自己是做“纯粹”还是“不纯粹”的工程。
那不是他们的代码库！
如果公司想让你从数据库基础设施转到支付系统开发，他们有充分权力这么做。
你在陌生系统中犯错的可能性——
或你的旧团队因失去你而遭遇困境——
这些都是公司而非工程师本人所做的取舍。
指出大公司代码糟糕的例子是没问题的。
至少这能促使具体问题被修复——因为高层往往乐于把“坏名声”转化为“好公关”。
但作者认为，把责任主要归咎于工程师是错误的。
即便你能挥动魔杖让所有工程师能力翻倍，
糟糕代码仍会存在，因为几乎没有人能在全新的代码库中毫无错误地快速修改代码。
根本原因在于，大多数大公司工程师被迫在自己不熟悉的代码中工作。
