昨天下班回家坐在车上，突然想到了一个事实——完美的工程代码是不存在。当然我这里单独指工程代码，即正常运行在服务器上，作为生产的一环运行的代码。那些个人或很小团队维护的实验性质，学术性质的代码不在此列。
为什么这么说呢？我觉得主要是工程代码需要团队协作，而只要是人就一定会犯错误。而且经验越少，技术越差，犯错误的概率就越高。如果是一个人，甚至两到三个人，只要定好了代码风格，做好代码复查，基本都能保证代码质量，但是一个团队往往不止2，3个人，而是5，6个，甚至十几个人。这些人中间有的人参加工作十几年了，有的人今年才刚毕业，有人技术好，有人技术差，人员素质怎次不齐。一定会有人源源不断的贡献坏的代码。
有人说：坏代码来了不让他提交不就行了？代码复查这个环节哪里去了？其实代码复查是一个成本很高的工作，我相信很多团队根本没有，就算有，大部分团队也是抽查。因为从需求端过来的任务非常多，不可能每一个任务都安排给有经验的、技术好员工，一定会有任务被安排到新人那边。新人提交的代码也不一定每一段都能被复查到，因为项目催的紧，可能就直接上线运行了。
这就出了问题：可能新人的代码风格很不一致，逻辑很啰嗦，但是代码能运行，能满足客户需要。这个时候且不说后面代码复查可能查不到，就算查到了，研发经理能够确定按照复查要求完全进行重写么？在业务压力和提交压力下，大部分研发经理都不会做这样的决策。但是，千里之堤溃于蚁穴，这种小的，差的片段逐步累积慢慢多了之后，整个工程就有了坏味道了。
甚至会引发破窗效应。一个本来可以写好，有一定代码能力的人，在进行维护的时候，会被原来的差的代码限制思路——因为不想完全从头再来，只在现有的基础上修修补补。这个本来可以写好的人，一定也会贡献一段差代码。甚至打开自己维护的工程，写好代码，打开坏味道工程写坏代码。最终这个坏代码工程变成一个不可维护，牵一发动全身的垃圾山。
如何破解这个问题呢？
我目前只能想到三点：
-
最核心的还是要从源头控制，要求员工提交的代码，必须自己回过头来审视，看有没有坏味道。但这意味着大量的标准出台和员工培训，以及员工个人职业道德和能力的提升。这是一条困难且漫长的路。
-
其次是要减少内卷，任务不要压得太重，要让员工有写好的时间和机会。在现在的市场竞争环境下，基本是不可能的。
-
最后一种办法，就是加强代码复查，每一段要提交的代码都要被复查，并且查到坏味道一定要改。但是这个解决不了根本问题，而且也会增加企业成本。