- 主题:[转载]为什么大公司的代码质量不佳？
跟大家想的不一样，大公司的代码质量其实不高。
这看上去违反常理，大型科技公司薪酬优厚，足以吸引众多优秀工程师。而且，大公司的工作环境、配套工具、开发节奏都很好，非常适合从容不迫地完成高质量的工作。
但是，事实就是他们的代码质量完全谈不上优秀。
原因很简单，大公司的大多数代码都是由相对的初学者完成的。
那些工程师并不是不优秀，而是被迫去开发非本领域的项目，属于相对的初学者。
现实生活中，大型科技公司的工程师，很少会一直干下去。事实上，大公司的薪酬方案通常都设定了工程师的四年任期，四年后初始授予的股份全部归属，工程师的收入可能就会大幅下降。这时，如果你没有得到晋升，显然可以考虑离开了。
如果算上内部流动，情况就更糟了。我自己在同一个团队或同一个代码库，停留的时间最长也只有三年，那还是我刚入职的时期。后来，我每年都至少经历一次重组，更换团队或项目。
当然，大公司的代码库寿命没有这么短，很多内部代码库都有十年甚至更久的历史。问题是，这么多年来，这些库经历了许多不同的所有者，不同的工程师都在不断地"摸索"，相当高比例的代码变更是由"新手"完成的。这些人可能是在过去六个月内才加入公司、接触代码库。
你肯定会问，大公司的那些"老手"程序员难道不写代码吗？总有一些工程师在特定领域工作了足够长的时间，积累了真正的专业知识，会进行深入的代码审查，并能可靠地发现问题，这些人在干什么呢？
首先，大公司不在乎"老手"程序员。公司很少致力于培养特定专业的长期人才，而且似乎也根本不在乎留住这些人才。通常情况下，这些人迟早会被调到其他部门，成为一个全新系统的相对新手。
其次，"老手"工程师总是工作量巨大。作为少数精通特定服务的工程师之一，他们的工作非常繁忙。他没有足够的时间亲自审查每一次软件变更，或者积极参与每一个决策过程，他有自己的工作要做。
总之，大公司的现实就是，你总是被分配到新项目，几乎每天都在赶工，要赶上多个项目的截止日期。换句话说，工程师是在一个不利于编写高质量代码的环境中尽力而为。
这样情况下，就很难保证优秀的代码质量了。更常见的情况是，一位初级工程师接手了一个他几乎不熟悉的代码库中一个恼人 bug 的工单。他花了几天时间研究，最终想出了一个蹩脚的解决方案。如果幸运的话，一位"老手"在空闲的半小时里匆匆浏览了一下，否决了这个方案，并提出了一个稍微好一点、至少能用的方案。初级工程师尽力实现了这个方案，测试了它是否有效，经过简单的审查后发布，所有相关人员立即转而处理下一个高优先级的工作。
seangoedecke/bad-code-at-big-companies/
--
修改:hgoldfish FROM 27.152.10.*
FROM 27.152.10.*
大公司代码质量不佳，那小公司代码质量就更差了。。。最好的代码还是开源项目，毕竟做的不好，没脸拿出来给大家看。
【 在 hgoldfish 的大作中提到: 】
: 跟大家想的不一样，大公司的代码质量其实不高。
: 这看上去违反常理，大型科技公司薪酬优厚，足以吸引众多优秀工程师。而且，大公司的工作环境、配套工具、开发节奏都很好，非常适合从容不迫地完成高质量的工作。
: 但是，事实就是他们的代码质量完全谈不上优秀。
: ...................
--
FROM 222.129.50.*
也是没办法，小公司的项目本身就小，能work就是最重要的，只要保证主要流程ok就行
不好的开源项目，基本没人关注，
没关注的项目，不久 maintainer就没动力更新了，然后就死掉了
【 在 buildtolast 的大作中提到: 】
: 大公司代码质量不佳，那小公司代码质量就更差了。。。最好的代码还是开源项目，毕竟做的不好，没脸拿出来给大家看。
:
:
--
FROM 120.244.54.*
chatgpt:
下面是对该帖子的论点与论据的整体分析，包括哪些地方是有道理的、哪些是明显以偏概全或逻辑上有问题的。
? 一、论点是否成立？
帖子的核心论点是：
大公司的代码质量不佳，因为大多数代码由对项目相对“新手”的工程师编写，而“老手”工程师无法长期深耕、忙不过来、也不会留下。
这个论点有部分真实的成分，但总体是以偏概全、过度推论。不同类型的大公司差异巨大（FAANG、传统大厂、金融科技、内部软件、外包），不能都按这种情况套。
? 二、哪些论据是合理的、真实存在的？
以下现象确实在许多大型科技公司普遍存在：
1. 工程师流动率高、重组频繁，人员对代码库不熟悉
大公司每年重组是常态（特别是 Google/Amazon/Meta）。
一个服务的 owner 常常一年换几次。
新人接手陌生代码库确实很多。
? 这会降低一致性与代码质量，增加技术债。
2. “老手”工程师时间极度稀缺
系统核心组件的知识往往集中在极少数人手里。
这些人经常被强行拉去支援各种事情，例如 SRE 协作、紧急事故、设计评审。
? 代码审查确实经常因为老手太忙变成走流程。
3. 赶工 / deadline 导致质量下滑
大公司的工程师虽然不一定像创业公司那样“996”，但：
跨团队依赖会制造大量 deadline。
任何大型项目都伴随 KPI 压力。
上线窗口有限制，错过就是推迟几个月。
? 工程师确实经常在不熟的代码中赶 deadlines，最终导致“能跑就行”。
4. 大代码库长期累积技术债
十年以上的系统会有：
历史包袱
风格不统一
多代人 patch 上 patch
? 这不是谁的错，是复杂系统的自然老化。
? 三、哪些论据是不准确甚至是错误的？
下面是该帖子偏激或错误的部分。
1. “大公司大部分代码由初学者完成”——以偏概全
虽然工程师可能是某个系统的“新手”，但他们：
已经通过大厂严格筛选
不是编程意义上的初学者
具备通用工程能力
? 他们只是对该代码不熟，不等于是“初学者写代码”。
2. “大公司不在乎老手，不培养长期人才”——错误或非常片面
实际情况：
AWS、 Google、 Microsoft 都有 Principal / Staff / Distinguished 工程师体系，明确鼓励长期技术积累。
很多技术骨干在团队里十年以上。
没有一个大型技术组织会故意“不要老手”。
帖子忽略了大量“长期服务 owner”的存在，仅用个人经验扩大化到全行业。
3. “四年后大部分人都会离开 / 只干四年”——错误
现实是：
Meta、Google、Microsoft 的大量工程师待五年、八年、十年以上。
四年只是 RSU 的 vesting 周期，不等于“合同到期”。
很多人会拿到新的 grant 并留下。
? “四年就走人”根本不是行业规律。
4. 忽略了严格的 code review、CI system、lint、自动检测
大公司普遍存在：
Code review 强制制度
干净的 CI pipeline
静态分析、Lint、编译检查
大规模自动回归测试
Oncall 事故复盘机制
这些机制客观上提高了代码质量
即使工程师个人水平波动，系统机制仍能兜底。
? 代码质量远不等于“工程师个人质量”。
? 四、逻辑漏洞：把“个人经验”当成“普遍真理”
这篇文章基本围绕作者个人遭遇展开：
他一直在内部转岗
他所在团队重组频繁
他的代码库缺少 owner
老手稀缺
这些确实 可能发生，但不能推广到所有大公司。
? 作者“所在团队”≠“世界所有大公司”。
? 五、大公司的代码质量到底高不高？
更客观的结论是：
1. 大公司的代码质量平均水平高于中小公司
因为有：
更严格的工程流程
更多自动化
更好的工具链
更完善的架构规范
2. 但大公司的代码库更庞大、更老化、技术债更多
因为：
年限长
多人维护
风格不统一
历史包袱巨大
所以会给人“质量不佳”的印象。
? 更接近真相的是：
大公司的代码相对稳健、可维护，但不一定优雅。
大公司的代码技术债很多，但底线质量普遍高。
大公司的工程师不会写“完美代码”，但体系化工程质量非常高。
? 六、总结
该帖子有部分合理观点，但其论据高度片面，结论显著夸大。
对“人员流动”“陌生代码”“deadline 压力”描述较真实
但对“老手不受重视”“大部分代码是初学者写的”“大公司不培养人才”这些论断明显夸张甚至错误
逻辑上基本是“用个人经历推断整个行业”
更全面的观点是：
大公司代码质量不是高不高的问题，而是“系统性工程下的高可靠性 + 历史包袱导致的混乱并存”。
如果你愿意，我还可以进一步：
给出真实大厂（Google/Amazon/Meta）代码质量体系的分析
对比大公司与中小公司的工程风格与质量特点
分析哪些机制真正决定代码质量（CI、review、SRE、owner 制度）
--
FROM 61.48.128.*
大公司是一坨屎山
小公司估计连山都形成不了，遍地散乱的都是
--
FROM 36.110.6.*