拥抱质量：改善团队代码质量的计划草案

//代码质量一直以来是大家关注的问题。

//以下为摘抄别人的文章，觉得不错，回去要好好总结考虑一下。

 

最近致力于产品质量的保障和提升工作，首先希望解决的就是代码质量问题。不受约束的程序代码，就像是一个潘多拉宝盒，打开以后让人惊喜连连，当然，目前我所体会到的是惊远远大于喜。

要想提升代码质量，首先需要确立质量意识。
质量、功能和进度，一个软件项目/产品的三根支柱，但在现实项目中，当质量和其它两项产生冲突时，质量往往是被牺牲的对象。团队对于质量的态度主要停留在 口头重视上，似乎还没有上升到团队意识的高度，也缺乏必要的保障手段。但没有质量的功能，从它面世第一天就开始永无止境的修补，并最终走向被重写的命运， 没有质量的进度，只能是一个虚伪的承诺，因为接踵而至的，是一轮又一轮的 附加开销，有效进度被大大拖延。

要想培养团队的质量意识，需要培训。
要让每一个代码贡献人员，明白什么是好，什么是差，以及如何从差变好。我们准备使用四种形式的不定期会议来进行团队培训。

1、知识性培训 。
为团队选定一个教材范围，教材可以是书籍、文章，制定阅读计划。完成一个阶段的阅读后，指定某些团队成员组织培训材料，交流读书心得。这是理论教育。

2、代码交流会。
有人称它为团队江湖中的“华山论剑”。团队成员可以自告奋勇，拿出自己写的好的或者差的代码进行公开讲解，以分享自己的经验或者请求其他人提供改善的意见。必须注意，要明确表态，这个会议的结论不与员工考评挂钩，以创造良好、开放的交流氛围。

3、个人发布会。
在一个模块开发完毕，且完成单元测试，准备提交测试部门之前，由模块负责人主持召开内部发布会，邀请其他组感兴趣的同事参加。这个会议的功效是多样的：
  保障模块发布质量，为了不在发布会上出丑，负责人会更加谨慎的对自己的作品进行测试。
  可以加强团队成员之间的联系。
  有利于成员形成对产品的整体认识，减少盲人摸象的感觉，提升团队归属感。
  提高发布人的协调组织和公众表达能力。

4、问题分析会。
问题分析会有一定的针对性和警示作用，气氛相对严肃。寻找代码中出现频度较高，或者影响较大，或者有典型意义的质量问题，进行深入的分析。

有了培训，还需要量化代码质量的改善情况，这方面计划采纳如下手段：

1、统一工具。
以CVS客户端为例，团队中有三种使用模式：Eclipse，Eclipse+CVSNT，CVSNT。已经出现过多次因为在不同环境下拷贝文件而造成的版本混乱或者冲突。团队中的工具和使用模式，有必要进行统一，并给予best practice方面的培训。

2、采用更好的项目构建平台。
准备采用Maven替换现有的ant。这个已经做了比较细致的调研和对比，有机会我在后续的文章中进行详述。Maven相比ant的最大优势，在与 Maven是从管理的角度看问题，而ant的主要长处在与将重复性工作自动化。所以，我说，maven是一个平台，一套规范，而ant只是一个工具罢了。

3、采纳Sonar代码质量管理平台
简单的说，Sonar继承了FindingBugs，PMD，CheckStyle等很多知名的开源静态代码分析工具和自动测试工具，可以生成详细的代码分析质量报告，并通过web界面展示出来。
我们希望通过Sonar平台来关注主要的质量指标的变化情况，如：重复代码量、注释比例、代码复杂度、测试覆盖度等。这方面的使用心得，有机会我在后续的文章中进行详述。

4、坚持代码评审。
代码评审，这是最常规的质量控制手段，我就不多说了。

看起来很好，但我知道实施起来任重道远。质量问题，需要做持续的改善。