大厂的代码很糟糕,即使优秀工程师也带不动,为什么?
大厂中的糟糕代码并非工程师个人能力不足，而是公司制度和激励机制导致的系统性问题。公司故意选择了一种权衡：牺牲代码质量，以换取工程师的可互换性和快速迭代能力。工程师任职周期短，导致大多数代码变更由“新人”完成
大厂工程师平均任职时间仅2年（引用2013年数据，Google 中位数为1.1年）。股权激励通常四年归属完毕，后续刷新不保证，鼓励跳槽或内部流动。同时，公司频繁进行组织调整。 结果：代码库往往存在十年以上，却由众多短期拥有者维护。大部分代码修改来自“新人”——对公司、代码库或编程语言仅熟悉数月的工程师。这使得错误和低质量代码难以避免。资深工程师的作用有限
少数长期留在同一代码库的资深工程师能通过非正式代码审查和指导来缓解问题。但公司不鼓励长期深耕，而是推动流动；“老手”往往超负荷，既要完成个人任务，又要审查他人代码，无法全面覆盖。典型工程师的工作环境
大厂中大多数高效工程师都是称职的，但他们经常在不熟悉的代码库、语言或领域中工作，同时面临截止期限和多项目并行压力。在这种“不支持高质量产出的环境”下，即使尽力，也容易产生明显低质量的代码。作者举例：一位初级工程师用 “hacky” 方式修复 bug，资深工程师建议稍好但仍不完美的方案，最终匆忙上线。几年后，这段代码被视为“糟糕”。作者本人至少遇到过十次类似情况。公司层面的故意权衡
大厂清楚地将工程师视为“可互换资源”，优先考虑“内部可读性”和快速转向，而非长期专精。这种设计是为了敏捷性和适应性，但副作用就是接受一定程度的糟糕代码。 作者强调：这不是无知，而是深思熟虑的取舍。个体工程师无力改变，因为权力集中在管理层。“纯工程” vs. “非纯工程”
作者区分两种工程实践：在“小而独立”的项目（如开发编程语言）中，糟糕代码通常反映个人能力问题（纯工程）。而在大公司这种截止期限驱动、频繁切换系统的环境中，糟糕代码是结构性的、不可避免的（非纯工程）。大公司强制后者，因此不能简单归咎于个人。
