不计成本一般是不可能的。成本最低的是上SonarQube，约定每次提交想引入新的issue就必须经过充分讨论，一般代码质量就不会太烂了。这只要付出一点代码重构的时间成本，何况Sonar会提示如何修改，而且在修改SonarQube的issue过程中，程序员也会逐步提高水平。所以SonarQube应该是最实惠有效的消灭低质量代码和提高程序员编程习惯的方案。
但是Sonar毕竟是个机器，它只能让代码质量的下限不那么低，规模大了仅仅有良好编程习惯也解决不了维护性的问题。要进一步提升，充分必要条件是领导发自内心的重视代码质量，这样项目负责人才能有足够的授权、资源和压力来提高代码质量，这三方面缺一不可。然而领导往往不会多么重视代码质量，顶多口头重视重视，毕竟能完成KPI就行了，代码质量低点有什么坏处？一年以后项目很难维护？一年以后这个项目归不归我管还两说呢！但是这不是我们能把握的因素。
首先是授权，因为代码质量高低是很有主观色彩的，反正可以实现功能，为什么你偏偏让我改成那样？相关扯皮是少不了的，有领导授权至少能够说：领导要求代码质量，让我负责把关，这里提交就是我说了算——当然这很不友好，但是这很管用。否则只能扯皮一天，最终不了了之，代码质量就一天天坏下去。
其次是资源，这没什么好说的，团队中每个人都不会把高质量代码形成本能，相关的修改和返工是免不了的，要么加钱要么多给点时间，最好两者都有。
最后也是最重要的是压力，因为没有程序员写代码是为了输出高质量代码，大部分程序员是为了完成任务，但是全部程序员都是为了早点下班。不排除个别程序员为了输出高质量代码而生，但是他们很快就会被开掉因为他们的产出有点低。所以没有代码质量方面的压力，即使项目负责人是个有追求的程序员，也不要指望他／她可以多么重视代码质量。
项目负责人有了足够的授权、资源和压力，具体怎么进一步提高代码质量呢？
首先是组织学习，提高整体水平，应该说大部分程序员，包括主要负责人，都是很需要在面向对象程序设计上多多提高的，只要能把面向对象这四十年老思想用好，大部分项目都能得到一个明显的提升。
其次才是审核，如果没有学习和提高，那么所谓的审核不过是对着别人的代码规范校对自己的代码，那么除了Sonar费电审核费眼以外，和SonarQube有什么区别？检查代码规范应该尽量交给自动化工具，而只是审核的顺带工作。审核更重要的任务是检查是否有设计上的需要改进之处、代码规范有没有要改进的、是否存在可能的缺陷，并且实践学习到的东西。审核是由人来完成的，而且往往是水平比较高的程序员来完成，它的成本是很高的，应该用到刀刃上。
本文内容不用于商业目的，如涉及知识产权问题，请权利人联系51Testing小编(021-64471599-8017)，我们将立即处理
