大公司代码质量差的主要原因是：多数工程师任职时间短(1-2年)，且常在自己不熟悉的领域工作。公司薪酬设计导致四年后员工可能面临50%的降薪，促使人才流动频繁。这些因素导致新手在非专业领域进行大量代码修改，最终影响代码质量。

标题：优秀工程师为何在大公司写出糟糕代码

每隔几年，总会有人注意到大型科技公司偶尔会产出令人惊讶的草率代码。这种现象的背后，隐藏着大公司独特的运作机制。

核心原因在于：大公司充斥着大量非本领域专家。数据显示，科技巨头员工的平均在职时间仅1-2年。薪酬体系更是设计了"四年天花板"——初始股权四年后完全归属，导致工程师可能面临50%的薪酬缩水。即便有年度补充激励，这种机制仍促使员工频繁跳槽。

代码库的寿命却远超人员任期。许多服务已运行十年以上，期间更换过无数负责人。这意味着： - 大部分代码修改由"新手"完成（入职/接触代码库/使用编程语言不足半年） - 仅有少数"老手"能提供深度代码审查，但他们面临双重困境： 1. 专业知识传承完全依赖非正式机制 2. 经验丰富的工程师永远超负荷工作

典型工作场景： 1. 初级工程师接到陌生代码库的故障单 2. 花几天时间想出临时解决方案 3. 资深工程师抽半小时粗略审核，否决最差方案 4. 采用折中方案后立即转向更高优先级任务 5. 数年后才有人发现这个"明显糟糕"的代码

这其实是大公司有意为之的权衡： - 牺牲代码质量换取人力资源灵活性 - 优先考虑"内部可视性"（随时调配人员） - 确保能快速响应月度重点任务（如当前AI转型）

工程师个体无力改变这种机制，尤其在2025年权力更偏向管理层的背景下。最现实的策略是成为某个领域的"老手"，但这也需要逆流而上。

本质上是"纯粹工程"与"混合工程"的区别： - 纯粹工程师（如开发编程语言）将糟糕代码归咎于能力不足 - 混合工程师（如 plumbing式工作）认为在陌生系统中犯错不可避免

最终责任在于公司制度，而非工程师个体。即便所有工程师能力翻倍，在持续接触陌生代码库的背景下，糟糕代码仍会出现。

（注：原文中的注释链接和延伸阅读部分已根据中文阅读习惯进行精简处理）

以下是评论内容的总结，平衡呈现不同观点并保留关键引用：

1. 短期交付压力导致代码质量下降

   • 多数评论认为管理层对短期成果的不合理压力是主因，导致工程师忽视代码质量
   • "工程师面临不合理的短期交付压力，管理层缺乏对工程技艺的尊重"（jeltz）
   • "截止日期总是获胜，因为老板看不懂代码"（matt3210）

2. 组织架构与人员流动问题

   • 大公司故意保持工程师可替换性，牺牲代码质量换取灵活性
   • "这是刻意权衡：放弃部分代码质量来获得工程师快速调配能力"（Herring）
   • "中层管理频繁重组，同样缺乏长期维护代码的动机"（mtnygard）

3. 工程师能力与决策问题

   • 部分指出糟糕代码源于工程师基础不牢或错误决策
   • "我看到的大部分坏代码源于人们赶工和基础不扎实"（jeltz）
   • "有时是无能工程师做出愚蠢决定，而公司政策阻止修复"（innocentoldguy）

4. 工程与商业价值脱节

   • 多数企业不认为优秀代码是必要需求
   • "真正的工程工作被视为低级工作，外包给合同工"（zkmon）
   • "优秀代码更多是被固执工程师'偷渡'进去的"（pxc）

5. 不同规模公司的对比

   • 有评论质疑大公司必然代码差的说法
   • "大公司就像小公司集合体，代码质量因团队而异"（tyleo）
   • "小公司同样有糟糕的意大利面条代码"（huqedato）

6. 解决方案建议

   • 主张通过责任制改善：
   • "最佳方案是风险/奖励机制，让员工真正负责"（austin-cheney）
   • 也有认为招聘标准需要调整：
   • "过度优化算法题选拔会招到缺乏协作能力的开发者"（samdoesnothing）

关键数据争议： - 关于任期统计的质疑："因员工数量增长，中位数任期自然较短"（nathancspencer） - 相反案例："我的FANG团队平均任期约7年"（01100011）

保留幽默评论： "问题在于动机，鲍勃。我的唯一动力就是不被找麻烦"（area51org） 以及斯坦福监狱实验的隐喻引用（lambersley）