工程师通常是在一个不利于高质量编码的环境中尽力而为

在软件开发行业，规模大的开发团队，整体代码质量并不高。

最近我在做一个Browser use相关的控制系统，大概思路是通过docker创建一系列自带chrome的Linux虚拟机集群，然后通过CDP调试工具，控制虚拟机里面的浏览器，完成一系列工作。

开发完成简单跑通用例后，除了负责编码的工程师，大家都很乐观，认为这东西可以上线了，原本负责开发的人被委派搞新的需求，新加入的工程师，负责为这个系统增加新功能。

这个系统的代码质量一直不算高，原因如下：

其一：早期为了快速验证可行性，用了LLM生成了大量的模版化代码，有些代码可以精简，但对主功能没有影响，大家就懒得删（能跑就别乱改，这是软件开发的常态）

其二：很有经验的软件工程师，切换到自己不熟悉的领域，就会变成相对的初学者，初学者的代码质量不会太好。

其三：公司很少致力于培养特定专业的长期人才，一些“老手”往往在项目变动后，重新变成“相对的新手”

其四：“老手”适合做代码审查，但“老手程序员”往往工作非常繁忙，他往往没有时间安静专心的审查每一次提交，或者积极参与每一个技术评审。

其五：“代码审查”和“开发任务”是并行的，“开发任务”是很容易量化的，而“代码审查”并不容易量化，“代码审查”甚至会拖慢开发进度，在工期很赶的情况下，根本没有条件去进行严格的“代码审查”，开发团队往往无法扛住产品侧的排期压力，只能放弃一些代码质量。

工程师通常是在一个不利于高质量编码的环境中尽力而为，在日常的工作中，往往是一位相对初学者接手了一个他几乎不熟悉的代码库中一个恼人 bug的工单。他花了几天时间研究，最终想出了解决方案，但依然遇到了问题。他会找老手帮忙排查问题，"老手"会抽时间排查问题，提出了一个稍微好一点、至少能用的方案。初级工程师尽力实现了这个方案，经过简单的审查后发布，所有相关人员立即转而处理下一个高优先级的工作。

本文永久更新地址:

https://fangyuanxiaozhan.com/p/2025-12-06-12-54-50-good-code/