Loading... # 大型科技公司优秀工程师写出低劣代码的技术分析 # 一、问题概述 ## 1. 问题背景 大型科技公司偶尔会出现令人惊讶的低劣代码，这种现象在外界看来似乎难以理解。这些公司支付有竞争力的薪资吸引优秀工程师，且开发节奏相对缓慢，看起来有充足时间写出高质量的代码。 ## 2. 核心问题 **为什么优秀工程师在大型科技公司会写出低劣代码？** 这个问题的本质是：在大规模软件开发环境中，系统性因素如何导致个体工程师在非专业领域工作时产生技术债。 ## 3. 分析范围 ### A. 涉及角色 - 初级工程师 - 资深工程师（老手） - 技术管理者 ### B. 涉及系统 - 大型遗留代码库 - 频繁重组的团队结构 - 工程师流动性管理机制 # 二、问题分析 ## 1. 直接原因 ### A. 工程师在非专业领域工作 大型科技公司充满了在自身专业领域之外工作的工程师。这种现象的主要表现： - **平均任期短**：大型科技公司工程师平均任期仅 1-2 年 - **内部流动性高**：工程师经常被重新分配到不同团队 - **代码库寿命长**：许多服务已有十年或更久历史 ### B. 薪酬结构的设计 大型科技公司的薪酬包裹通常设计了 4 年上限： - 初始股票授予在 4 年后完全归属 - 4 年后工程师可能面临 50% 的降薪 - 公司提供的年度续期奖励具有不确定性 - 这种结构实际上激励工程师跳槽 ```mermaid graph LR A[入职] -->|第1年| B[股票25%归属] B -->|第2年| C[股票50%归属] C -->|第3年| D[股票75%归属] D -->|第4年| E[股票100%归属] E -->|面临降薪风险| F{选择} F -->|获得续期| G[留下] F -->|无续期| H[跳槽] ```  ### C. 持续学习状态 许多大型科技公司的工程师持续处于学习状态： - 高比例的代码变更由新手完成 - 新手定义：过去 6 个月内加入公司、代码库或编程语言的工程师 - 工程师不断适应新系统、新语言、新团队 ## 2. 根本原因分析（5 Whys） ### A. 为什么工程师在非专业领域工作？ **第一层**：工程师平均任期短，代码库寿命长 **第二层**：为什么任期短？ 薪酬结构设计为 4 年上限，之后面临降薪风险 **第三层**：为什么这样设计薪酬？ 公司希望保持工程师流动性，以便快速调配资源 **第四层**：为什么需要高流动性？ 公司优先考虑内部可见性而非生产力 **第五层**：根本原因 大型科技公司为了获得快速部署工程师的能力，主动牺牲了部分专业知识和代码质量。这是一种深思熟虑的权衡。 ### B. 为什么没有及时发现和阻止问题？ **老手机制的两个缺陷**： **缺陷 1：过程完全非正式** - 公司几乎不投入资源培养个人对特定系统的长期专业知识 - 一旦工程师获得专业知识，公司也不重视保留 - 老手经常被调往不同服务 - 要么在不获得报酬的基础上自愿承担老手职责，要么放弃并成为新系统的初学者 **缺陷 2：资深工程师总是过载** - 成为少数对特定服务有深入理解的工程师是一项忙碌的工作 - 没有足够时间亲自审查每个软件变更 - 无法积极参与每个决策过程 - 工程师还有自己的工作要完成 - 如果花所有时间审查变更和参与讨论，可能会因个人产出不足而受到惩罚 ```mermaid graph TB A[代码变更] --> B{有老手审查?} B -->|是| C[老手过载] B -->|否| D[低劣代码合并] C --> E{时间充足?} E -->|否| D E -->|是| F[提出改进建议] F --> G[初级工程师实施] G --> H{理解正确?} H -->|否| D H -->|是| I[代码合并] C --> J[个人工作受影响] J --> K[绩效考核下降] ```  ## 3. 中产工程师画像 典型的中产工程师具备以下特征： ### A. 能力水平 - 足够胜任，通过招聘标准并能够完成工作 ### B. 工作状态 - 在对他们来说基本陌生的代码库或语言上工作 - 或者试图在管理自己工作的同时跟上大量代码变更 ### C. 时间压力 - 几乎肯定在截止日期下工作 - 或者同时在多个不同项目的重叠截止日期下工作 ### D. 环境特征 **他们正试图在一个不利于产生高质量代码的环境中尽力而为** # 三、问题演化 ## 1. 典型问题场景 ### A. 场景描述 初级工程师接手一个基本不熟悉的代码库中的错误修复任务 ### B. 处理流程 1. **探索阶段**：花几天时间理解问题 2. **初步方案**：提出一个临时的解决方案 3. **审查环节**： - 如果幸运，资深老手会在空闲的半小时内瞥一眼 - 否决临时方案 - 建议稍微更好的方案 4. **实施阶段**：初级工程师尽可能实施建议方案 5. **测试验证**：测试功能正常 6. **合并发布**：简要审查后发布 7. **立即转向**：所有相关人员立即转向更高优先级的工作 ### C. 长期后果 **5 年后的困境**： - 有人注意到这段代码 - 想法：太临时了，这样的大型软件公司怎么写出这样的低劣代码 ## 2. 系统性因素 ### A. 公司优先级权衡 大型科技公司优先考虑： - **内部可见性**：一目了然地知道谁在做什么并随意更改 - **资源流动性**：快速将熟练工程师部署到月度问题上 - **而非生产力**：牺牲专业知识和软件质量 ### B. 权衡的合理性 这种权衡在 2025 年尤为重要： - AI 相关技术转型速度至关重要 - 公司需要快速调整方向 - 工程师被视为可替代资源 ```mermaid graph LR A[公司目标] --> B{优先级} B -->|可见性| C[工程师可替代性] B -->|生产力| D[专业知识积累] C --> E[快速资源调配] D --> F[高质量代码] E --> G[适应AI时代] F --> H[技术债减少] G -->|选择| I[接受低劣代码] ```  ## 3. 工程师的无力感 ### A. 个人影响力局限 **工程师完全无力改变这种动态**，特别是在 2025 年： - 权力平衡已从工程师转向科技公司领导层 - 个人工程师最多只能尝试成为老手 - 在至少一个领域发展专业知识 - 用它来阻止最糟糕的变更 ### B. 职业风险 即使成为老手也存在风险： - 往往逆着组织潮流游泳 - 如果操作不当可能导致被 PIP（绩效改进计划） - 甚至更严重的后果 # 四、纯工程与不纯工程 ## 1. 工程类型对比 ### A. 纯工程 **特征**： - 工程师在独立的技术项目上工作 - 例如：编程语言开发 - 对低劣代码的唯一解释是无能 ### B. 不纯工程 **特征**： - 更像水管工或电工的工作方式 - 在相对陌生的项目上按截止日期工作 - 即使技术基础无可挑剔 - 总有一些特定设置的尴尬或令人惊讶之处 - 对不纯工程师来说，低劣代码是不可避免的 - 只要整个系统运行良好，项目就是成功的 ## 2. 大公司的现实 在大型科技公司： - 工程师无法决定是从事纯工程还是不纯工程工作 - 这不是他们的代码库 - 如果公司想让你从数据库基础设施转移到构建新的支付系统 - 他们完全有权这样做 - 在不熟悉的系统中犯错是公司权衡的结果 - 而不是工程师的权衡 ```mermaid graph TD A[工程师技能] -->|纯工程| B[独立项目] A -->|不纯工程| C[现有系统维护] B --> D[技术质量可控] C --> E[受系统复杂度限制] E --> F[低劣代码不可避免] G[公司决策] -->|资源调配| H[工程师迁移] H --> C G -->|权衡取舍| I[接受质量损失] ```  # 五、影响分析 ## 1. 对工程师的影响 ### A. 职业发展 - 持续学习压力 - 难以深入掌握特定领域 - 技能广度增加但深度受限 ### B. 心理状态 - 持续的初学者心态 - 对代码质量的无力感 - 对未来不确定性的焦虑 ## 2. 对代码质量的影响 ### A. 技术债积累 - 临时解决方案长期存在 - 缺乏整体架构视角 - 补丁式修复而非根本解决 ### B. 维护困难 - 知识分散且不连续 - 文档更新滞后 - 历史决策背景丢失 ## 3. 对公司的影响 ### A. 短期收益 - 快速资源调配能力 - 适应市场变化 - 降低对特定个人的依赖 ### B. 长期成本 - 代码质量下降 - 系统复杂性增加 - 潜在的稳定性风险 # 六、解决方案探讨 ## 1. 个人层面 ### A. 成为老手 - 在至少一个领域发展专业知识 - 主动参与代码审查 - 指导新工程师 ### B. 局限性 - 逆着组织潮流 - 需要额外时间投入 - 可能影响个人绩效 ## 2. 团队层面 ### A. 知识保留机制 - 改进文档实践 - 建立知识传承流程 - 减少关键人员流失影响 ### B. 代码审查改进 - 确保有经验工程师参与 - 提供足够时间进行深入审查 - 建立审查质量标准 ## 3. 公司层面 ### A. 结构性调整可能 - 重新思考工程师流动性策略 - 在可见性和生产力间寻找更好平衡 - 投资长期专业知识培养 ### B. 现实约束 - 当前的权衡对大公司有效 - AI 时代需要快速转型 - 改变可能影响竞争优势 # 七、总结与反思 ## 1. 核心观点 **大型科技公司优秀工程师写出低劣代码的根本原因不是工程师无能，而是系统性环境使然**： - 大多数大公司工程师被迫在不熟悉的代码库中进行大部分工作 - 这是公司为了资源流动性而做出的主动权衡 - 即使工程师能力提升两倍，仍然会有低劣代码 - 因为几乎没有人能立即进入全新的代码库并快速做出零错误的变更 ## 2. 认知偏差 ### A. 外部视角 - 想象自己的工作环境与每个人都相似 - 缺乏想象力是主要失败 - 认为低劣代码必然是无能的表现 ### B. 内部现实 - 不纯工程的本质决定了低劣代码不可避免 - 只要整个系统运行良好，项目就是成功的 - 代码质量不是唯一衡量标准 ## 3. 局限性认知 ### A. 指出问题的影响 - 可以是修复特定示例的有效方式 - 高管通常会抓住机会将坏公关变成好公关 ### B. 错误归因的风险 - 将主要责任归咎于工程师是错误的 - 忽视了系统性因素 - 无助于根本解决问题 ## 4. 对工程师的建议 ### A. 理解现实 - 接受不纯工程的现实 - 认识到个人影响力有限 - 在约束条件下尽力而为 ### B. 策略性应对 - 选择性成为老手 - 平衡个人工作与知识分享 - 保护自己免受系统性风险影响 ### C. 心态调整 - 适度的愤世嫉俗是必要的 - 不要对公司过度理想化 - 在可能的情况下做出积极改变 *** ## 参考资料 1. [How good engineers write bad code at big companies](https://www.seangoedecke.com/bad-code-at-big-companies/) 最后修改：2026 年 01 月 16 日 © 允许规范转载 赞 如果觉得我的文章对你有用，请随意赞赏