如何改善团队代码质量

如何改善团队代码质量

对于一个以软件开发为主的企业，软件代码的质量相当重要，但在实际的工作中，对于客户和管理者而言，软件代码的质量又往往不被看到或重视，这里存在一个“冰山理论”，对于软件产品而言，那些能被客户或管理者感知的软件功能只是庞大的软件代码这座“冰山”的一角，所以我们经常形成这样的感叹，在如此紧张的项目进度下，还花时间去改善代码质量，怎么能做得到呢？

其实改善代码质量说难很难，说简单呢也简单。说它难，难在改善代码质量，最终离不开程序员本身的努力；说他简单，简单在改善代码质量的方法，途径还是很多的，只要我们肯去做，总会有或多或少的成效。

改善代码质量，首先要提高程序员的质量意识，让每个程序员知道什么是高质量的代码，如何编写高质量的代码。达到这一点，可以通过不断的培训，提高程序员的编程技能，这个过程是一个多赢的过程，程序员编程技能提高了，个人得到成长；程序质量提高了，产品在开发过程中出现的问题会减少，项目进度更容易控制；程序质量提高了，产品可以更加稳定，客户会更满意，等等，总之，这是一切良性循环的开始。

那什么样的代码才是高质量的代码呢？先引用一些专家的观点说明：

A.我喜欢优雅和高效的代码。代码逻辑应当直截了当，叫缺陷难以隐藏；尽量减少依

赖关系，使之便于维护；依据某种分层战略完善错误处理代码；性能调制最优，省

得引诱别人做没有规矩的优化，搞出一堆混乱来。整洁的代码只做好一件事。

—— Bjarne Stroustup

B.整洁的代码简单直接。整洁的代码如同优美的散文。整洁的代码从不隐藏设计者的

意图，充满了干净利落的抽象和直截了当的控制语句。—— Grady Booch

C.我可以列出我留意到的整洁代码的所有特点，但其中有一条是根本性的。整洁的代

码总是看起来像是某位特别在意它的人写的。几乎没有改进的余地。代码作者什么

都想到了，如果你企图改进它，总会回到原点。—— Michael Feathers

那怎样才能做到上面所说的结果呢？下面给大家概括一些编写高质量代码的方法。

(一)使用有意义的命名

a)命名要名副其实。

变量，函数或类的名称应该告诉你它为什么存在，它做什么事，应该怎么用，如果这些命名还需要用注释来补充，那就不算是名副其实。比如以下代码：

int d；//消逝的时间，以日记

b)避免误导。

比如，别用accountList来指一组账号，除非它真的是List类型。

c)做有意义的区分。

废话是一种典型的没有意义的区分，比如你有一个Product类，如果还有一个ProductInfo 类或ProductData类，那它们的名称虽然不同，意思确无区别。

d)使用读得出来的名称尽量少用缩写。

e)使用可搜索的名称，尽量少用单字母名称或数字常量。

f)别用双关语，避免将同一单词用于不同目的。

g)少用近义词。

(二)函数

a)函数首先要短小

函数应该只做一件事情，做好一件事情，只做一件事情

b)函数参数要少

最理想的函数参数数量是零，其次是一，再次是二，应尽量避免三个以上的参数

c)函数要么做什么事，要么回答什么事，但二者不可兼得。

(三)简洁的注释

注释不能美化的糟糕的代码，所以注释不是越多越好，而是尽量用代码表达意思。最好的注释就是代码本身。而一些无法用代码表述的意思可以用注释，比如：法律信息，解释意图，警示，Todo的内容。

上面从几个比较重要的侧面简要描述了如何编写高质量代码（有兴趣了解更详细的内容，可以研读《代码整洁之道》），要培训我们的员工养成编写高质量代码的意识和习惯，并赋予其相应的技能。

但往往现实是比较残酷的，我们通常都无法一步到位的编写非常高质量的代码，更多的是在一些质量本身就不高的代码基础上继续工作，更为糟糕的是，我们反而经常把本来高质量的代码改得越来越差。那我们如何让质量不高的代码慢慢变成高质量的代码呢？那就会涉及到另外一个技能——重构。

重构这个概念在当下变得已经越来越流行了，那什么是重构呢，所谓重构是这样一个过程：在不改变代码外在行为的前提下，对代码做出修改，以改善程序的内部结构。重构一种有纪律的，经过训练的，有条不紊的程序整理方法，从本质上说，重构就是“在代码写好之后改进它的设计”。

学会如何重构，不但可以慢慢地改善现有不好的代码，还可以不让本来好的代码变坏。

重构是程序员应该养成的一种习惯，是伴随在每天的代码编写工作过程持续进行的，而不是在项目的某个阶段——比如测试之前做的。

那具体应该在什么时候重构呢？

有两个维度。第一，Don Roberts给了我们一条准则：第一次做某件事时只管去做；第二次做类似的事会产生反感，但无论如何还是做了；第三次再做类似的事，你就应该重构。第二，在闻到代码的“坏味道”时重构。

下面重点介绍一下几个典型的代码坏味道以及如何重构的方法。

(一)重复代码

重复代码是代码“坏味道”之首，也是最容易发生的“坏味道”之一，很多程序员不愿意对代码做设计，就简单的粘贴和拷贝代码，从而产生大量的重复代码。对于重复代码的改进，主要的手段就是抽象和提炼公用函数或方法，这个相对简单，也可以直接使用Eclipse 提供的重构工具自动完成一些重复性工作。

(二)过长函数

前面讲解高质量代码时也重点描述了函数一定要短小的原则，但如果前期设计的不好，本来短小的函数，随着后续需求的增加很容易越变越长，所以我们在修改函数时遵循这样一条原则：每当感觉需要用注释来说明点什么的时候，我们就把需要说明的东西写进一个独立的函数中，并以其用途（而非实现手法）命名。我们甚至可以为短短一行代码做这件事。百分之九十九的场合里，要把函数变小，只需要使用“提炼方法”的技能，找到函数中适合集中在一起的部分，将他们提炼出来形成一个新的函数。

(三)过大类

如果想利用单一class做太多事情，其里面往往就会出现太多instance变量。一旦如此，重复代码也就接踵而至了。你可以使用“提炼类”的技能，将数个变量一起提炼至新class 内。提炼时应该选择class内彼此相关的变量，将它们放在一起。如果你的过大类是GUI类，你可能需要把数据和行为移到一个独立的领域对象（domain object）去。你可能需要两边各保留一些重复数据，并令这些数据同步。

(四)过长参数列

刚开始学习编程的时候，老师教我们：把函数所需的所有东西都以参数传递进去。这可以理解，因为除此之外就只能选择全局数据，而全局数据是邪恶的东西。对象技术改变了这一情况，因为如果你手上没有你所需要的东西，总可以叫另一个对象给你。

太长的参数列难以理解，太多参数会造成前后不一致，不易使用，而且你一旦需要更多数据，就不得不修改它。

上面列举了几种比较常见，也相对比较好重构的代码“坏味道”，其他各式各样的代码“坏味道”还很多，有兴趣的读者可以详细研读《重构-改善既有代码的设计》一书，将会大有收获。

通过前面的论述，程序员知道了如何编写高质量代码，也知道了如何将本身不好的代码逐步的改善成为高质量的代码，但这些工作都是改善“冰山”藏在水下的部分，不能让程序员获得明显的成就感，不能让管理层直接感受到这些改善的成效，为了形成一个良好的编写高质量代码的氛围，我们还需要借助一些工具，来建立一个快速的反馈机制，让程序员在改善代码质量，或编写低质量代码时，能快速的得到一个反馈，促进整体工作向良性循环方向发展。

这里为大家推荐一个代码质量管理工具Ｓｏｎａｒ。

Ｓｏｎａｒ是一个开源平台，用于管理源代码的质量。从Ｓｏｎａｒ１．６版本开始，Ｓｏｎａｒ从一个质量数据报告工具，转变成为现在的代码质量管理平台。Ｓｏｎａｒ有以下一个主要特点：

1)代码覆盖：通过单元测试，将会显示哪行代码被选中

2)改善编码规则

3)搜寻编码规则：按照名字，插件，激活级别和类别进行查询

4)项目搜寻：按照项目的名字进行查询

5)对比数据：比较同一张表中的任何测量的趋势

使用Ｓｏｎａｒ之前需要提到另外一个工具，就是Ｍａｖｅｎ。

Ｍａｖｅｎ是基于项目对象模型（ＰＯＭ），可以通过一小段描述信息来管理项目的构建，报告和文档的软件项目管理工具。

如果你已经有十次输入同样的Ａｎｔｔａｒｇｅｔｓ来编译你的代码、ｊａｒ或者ｗａｒ、生成ｊａｖａｄｏｃｓ，你一定会自问，是否有一个重复性更少却能同样完成该工作的方法。Ｍａｖｅｎ便提供了这样一种选择，将你的注意力从作业层转移到项目管理层。Ｍａｖｅｎ项目已经能够知道如何构建和捆绑代码，运行测试，生成文档并宿主项目网页。

由于Ｓｎｏａｒ和Ｍａｖｅｎ有较好的集成性，所以建议大家使用Ｍａｖｅｎ来管理我们的软件项目，将Ｍａｖｅｎ设置成定期执行，在Ｍａｖｅｎ中安装Ｓｏｎａｒ插件，这样定期执行Ｍａｖｅｎ编译时，就可以触发Ｓｏｎａｒ对代码质量进行管理。

由于Ｓｏｎａｒ更多是一个代码质量管理的平台，我们还需要在Ｓｏｎａｒ中添加对代码质量做具体检查的一些插件，那这些插件中比较常用的有以下三个：

这三个插件从不同的角度提供了五百多条规则，对代码进行检查，我们可以根据我们的需要和团队的整体水平以及代码的现状，选择合适的规则。规则一旦启用，Ｓｏｎａｒ就会根据这些规则对代码进行检查，并形成报告反馈给开发者。下面是某个模块检查报告的一个

样例:

形

有了这样一个整体的代码质量体系，就可以促进团队不断的改善代码质量，哪怕是一个微小的改进，大家也能感觉到变化，体会到进步，获得成就感，从而营造一个良性循环的氛围。