如何减少团队的低质量代码？ 第1页

要是不计成本，直接招水平高的就行了：啥也不用操心，改需求时间紧任务重？那都不是问题！咱公司招的程序员写高质量代码早已成为本能。

不计成本一般是不可能的。成本最低的是上SonarQube，约定每次提交想引入新的issue就必须经过充分讨论，一般代码质量就不会太烂了。这只要付出一点代码重构的时间成本，何况Sonar会提示如何修改，而且在修改SonarQube的issue过程中，程序员也会逐步提高水平。所以SonarQube应该是最实惠有效的消灭低质量代码和提高程序员编程习惯的方案。

但是Sonar毕竟是个机器，它只能让代码质量的下限不那么低，规模大了仅仅有良好编程习惯也解决不了维护性的问题。要进一步提升，充分必要条件是领导发自内心的重视代码质量，这样项目负责人才能有足够的授权、资源和压力来提高代码质量，这三方面缺一不可。然而领导往往不会多么重视代码质量，顶多口头重视重视，毕竟能完成KPI就行了，代码质量低点有什么坏处？一年以后项目很难维护？一年以后这个项目归不归我管还两说呢！但是这不是我们能把握的因素。

首先是授权，因为代码质量高低是很有主观色彩的，反正可以实现功能，为什么你偏偏让我改成那样？相关扯皮是少不了的，有领导授权至少能够说：领导要求代码质量，让我负责把关，这里提交就是我说了算——当然这很不友好，但是这很管用。否则只能扯皮一天，最终不了了之，代码质量就一天天坏下去。

其次是资源，这没什么好说的，团队中每个人都不会把高质量代码形成本能，相关的修改和返工是免不了的，要么加钱要么多给点时间，最好两者都有。

最后也是最重要的是压力，因为没有程序员写代码是为了输出高质量代码，大部分程序员是为了完成任务，但是全部程序员都是为了早点下班。不排除个别程序员为了输出高质量代码而生，但是他们很快就会被开掉因为他们的产出有点低。所以没有代码质量方面的压力，即使项目负责人是个有追求的程序员，也不要指望他／她可以多么重视代码质量。

项目负责人有了足够的授权、资源和压力，具体怎么进一步提高代码质量呢？

首先是组织学习，提高整体水平，应该说大部分程序员，包括主要负责人，都是很需要在面向对象程序设计上多多提高的，只要能把面向对象这四十年老思想用好，大部分项目都能得到一个明显的提升。

其次才是审核，如果没有学习和提高，那么所谓的审核不过是对着别人的代码规范校对自己的代码，那么除了Sonar费电审核费眼以外，和SonarQube有什么区别？检查代码规范应该尽量交给自动化工具，而只是审核的顺带工作。审核更重要的任务是检查是否有设计上的需要改进之处、代码规范有没有要改进的、是否存在可能的缺陷，并且实践学习到的东西。审核是由人来完成的，而且往往是水平比较高的程序员来完成，它的成本是很高的，应该用到刀刃上。

很简单，只要想提升代码质量的那个人是团队负责人，是老大，那就行。

比如Linus他能控制代码，并非因为他能骂，而在于他是Linux团队老大，你代码能不能用，他说了算，你能不能呆在他团队，他说了算。如果他不是老大，他再能骂都没用。

如果一个团队的代码审查者是老大，是那个直接决定你年终奖，决定你涨不涨薪，决定你升不升职的人，那么只要他想检查代码质量就能提高代码质量。

反之，如果把检查代码的任务交给另外一个没有实权的员工，结果就是谁都不鸟他/她，而且还怪他/她碍事，影响开发进度。