如何提高代码质量（管理篇）：代码复查

也许你是一位项目经理，也许你是一位项目骨干成员，或者开发小组长。在我发表“如何提高代码质量”的这一系统文章后，有许多网友都向我抱怨，说他无法把握整个项目组成员的代码质量。我想，这也是所有项目组普遍存在的问题吧，它通常表现为以下几个问题：

软件项目普遍存在的问题

1）新手。任何项目组成员都不可避免地出现新手，他们往往是刚刚从大学毕业的学生。这些新手由于软件开发时间太短，往往技术不成熟，没有形成良好的开发习惯，所以编写代码质量较差，问题很多。他们常常成为项目组的“鸡肋”，用多了项目质量无法得到保证，不用则又人手不够。

2）人员变动。一个维护时间稍长一点儿的软件项目，人员变动是在所难免的。老员工被调动到其它项目去了，由新员工来接替他们的工作。在我的项目组中，人员调动达到了90%，唯一没有调走的就是我自己。新员工在接替老员工进行代码维护，甚至继续进行新的开发的时，由于对原有代码以及设计思路理解的偏差，也会出现大量的低劣代码。

3）不规范的代码编写。即使除去以上两个问题的影响，项目组成员编写的代码同样会出现问题。在项目开发之初，我们往往会制定一个代码编写的规范，但在项目开发过程中，许多成员往往会忽视这些代码规范而进行随意的编写。随意地代码编写会降低代码的可读性、可维护性和易变更性。那么，我们应当采用什么样的管理措施，保证代码的规范，提高代码的质量呢？

以上问题，也是我在项目开发中不断摸索和思考的问题，而一些有经验的项目经理给出了他们的解决之道，那就是“代码复查”。

什么是代码复查

代码复查（Code Review），又叫“代码审查”，其基本思想就是，在开发人员编写完自己的代码后，由其他人来复查他写的代码，从而有效地发现代码中存在的缺陷。代码复查的一个基本理论就是，当我们越早发现代码存在的缺陷，我们解决缺陷的代价就越低。代码复查往往分成以下一个方面进行审查：

1）代码风格。在项目开发之初，我们往往会制定一个代码编写的规范，实际上，这个代码规范就包含了整个项目组的代码风格。由于软件开发人员的设计习惯不同，如果不统一代码风格，一个项目中的代码将五花八门，如变量和常量的命名、接口与实现类的注释、何时回车、怎样缩进等等。一个五花八门的设计风格，必将为日后的维护与改进带来困难。我们通过代码复查，一方面督促开发人员按照规范编写代码，另一方面也使开发人员自身形成良好的编程习惯。代码风格的审查，由于内容比较单一，我们常常可以通过一些代码复查的工具来自动完成，提高复查的效率。

2）重大缺陷。在一些关于代码复查的文章中，列出了一个常常的单子，描述了代码复查应当着重注意的重大缺陷，它们包括：存在SQL注入、易受跨站点脚本攻击、缓存区溢出、托管代码等等。项目组可以不断积累重大缺陷的审查项目，并在每次审查中逐一检查。重大缺陷审查是一个繁琐而细致的工作，如果能编写或使用一些审查软件，可以大大提高我们的审查效率。

3）设计逻辑与思路的审查。我认为，这部分的审查是代码复查中最核心、最有价值的部分。代码风格与重大缺陷的审查，虽然重要但简单而机械，可以通过软件自动检查；而设计逻辑与思路的审查，却是复杂而有深度的审查，需要有一定理论深度和编码经验的人才能完成，而且对新手尤其重要。前面提到，新手是任何项目组不可避免的问题。但遗憾的是，许多项目经理的办法是，只将一些简单而少量的工作交给新手完成，而将大量复杂的工作交给人数不多的那些老手来完成。这样的结果是，新手始终是新手，他们没有经过足够的锻炼；老手累死累活，无法指望新手予以分担工作。对于这个问题，我的办法是，通过代码复查，让老手去指导新手，让团队整体素质达到提高。具体办法就是，在新手完成编码以后，让老手去进行代码复查，指出新手的问题，指导新手设计。这样的过程最初可能需要重构，甚至重新编码。但经过这样的过程，新手将逐渐熟练，迅速成为老手，使整体团队素质提高。

代码复查的形式及优缺点

经过以上的描述，我们可以发现代码复查的优点显而易见。首先，通过对代码风格与规范的审查，可以大大提高代码的可读性与可维护性。现在的软件，往往需要持续的维护与升级，人员变动也在所难免，因此代码的可读性与可维护性尤为重要。代码复查是一种鞭策，因为它的存在，督促着开发人员自觉地规范编码，养成好的编码习惯，提高代码质量。一个值得注意的问题是，如果你不去读别人的代码，永远不能深刻理解什么是可读的代码，而自己的代码不让别人去读并且反馈，也永远不知道自己的代码是否可读，即使你是一个编码多年的老手。代码复查恰恰解决了这个问题，值得你去尝试。

其次，代码复查是一次程序员之间的交流。新手可以有更多的机会向老手学习和指导，提高自身的设计水平（应当说这对于他们是非常宝贵的）；老手通过对新手的指导，整理和升华自己的设计思路与理论，同时也是对自己另一方面的锻炼与提高。另外，当你发现并指出了别人的一个问题以后，同时也是在警示自己不要犯同样的错误，这对审查与被审查者都是有益的。

虽然代码复查有如此突出的优点，但它的缺点也是非常显著的，那就是它需要付出如此巨大的代价。当一个人完成编码以后，还需要另外的人去解读和审查，并要求编程人员完成相应的修改，甚至重构和重写，这本身就是一种巨大的代价。这对于其本身就已经人员和时间非常紧张的软件开发项目来说，无疑是一种雪上加霜。时间、人力与代码质量，其本身就是鱼和熊掌不可兼得，关键是如何去权衡。正因为如此，不同公司选择了不同的代码复查策略。

前不久，我听了韩国一家大型游戏软件公司谈他们的代码复查。由于这家公司在软件开发时，时间和人力不是最关键和紧要的问题而代码质量，所以他们采用了一种严格的代码复查策略。严格的代码复查策略，一种方式是由专人进行代码复查。这种方式，在人员组织形式上，从软件开发人员中单独提出了一些经验丰富的人，组成一个代码复查小组，专职对其它软件开发小组进行代码复查。这种方式，代码复查小组以第三方的身份去复查各个项目组的代码，可以保证复查的公平公正，但压力无疑是巨大的（想想他们要查看那么多的代码）。

另一种方式，是以一个项目开发小组为单元进行代码互查，即一个人的代码，要为小组所有成员进行审查。这种方式毫无疑问，其付出的代价太大了。对这种方式的一种变通方式是将XP中的结对编程进行结合，然结对编程中的两个人相互进行代码互查。采用结对编程的项目组可以尝试这样方式，遗憾的是目前国内采用结对编程的项目组实在太少了。以上两种代码复查的最大弊病就是责任制，即审查者没有太多的责任去发现被审查者的问题，发现了问题对审查者没有任何好处，反倒与被审查者结怨；相反，审查者没有发现问题也不会担负任何责任。这样的结果就导致了代码复查流于形式：审查者草草审查，各方皆大欢喜，问题依然存在。

综上所述，虽然代码复查优势明显，但以上几种形式都不能为普通的软件开发团队所接受，就此我祭出了我的最佳实践：以小组为单位，组长责任制的代码复查形式。

代码复查的最佳实践

代码复查是有代价的，甚至有时是巨大的，因此代码复查不宜频繁，最好一份代码只审查一次。同时，代码复查者应当对所审查的代码负有责任，即能够大胆地审查并指出被审查者的问题，并要求被审查者限期整改。与此同时，被审查后的代码如果还出现缺陷，审查者应当负有责任。只有满足了以上三个条件，代码复查才能为我们所接受。毫无疑问，项目开发小组的组长来担当此责任是最合适的。

一个项目开发组，根据其功能的划分，可以划分为多个小组，每个小组负责一个子模块。在这样一个小组中，小组长无疑是最有经验的开发人员，由他去负责组织和指导其它成员是合适的。小组成员不要太多，往往是3~5人。小组长不要分配太多的开发任务，他的主要工作是指导和监督小组其它成员进行开发。将他从繁重的开发任务中解脱出来，他可以有更多的精力去指导其他成员的设计，并且复查他们的代码。最终，他要对小组所有成员的代码质量负责，由项目经理或质量管理员进行抽查，检验其整体情况。

如果你只是一个小型项目，人员总共在5人之内，那么你不用这样分组。作为项目经理的你就是那个小组长，指导和监督你的成员。这样安排是因为在现代的管理理论中认为，一个人最多只能管理5个人，超过5个人就应当分组管理。而如果你在5人之内当然就不需要分开啦。

作为组长，你可以有效地审查和管理你的小组成员。同时，由于你负有责任，你也不得不认真有效地去完成审查工作。通过以上的组织形式，代码复查可以简便有效地在项目组中开展起来，从而从管理上有效地提高软件开发的代码质量。

 

 

评论

26 楼 kungstriving 2012-11-09  

博主最后提出自己的最佳实践很有借鉴意义，以小组长为主要负责人的代码审查，这个也是我一直努力的方向，只是无奈项目组人员紧张，我的时间也是抽不出来，很难做到。但我相信如果做到了，肯定是代码审查的效果展现之时。

25 楼 mingjian01 2010-07-16  

基本同意，补充一点：怎样保证复查的质量？ 怎样保证复查者除了写代码还有时间对其他人的代码复查，怎样保证复查者是认真完成复查不是自己写的代码而不是草草了事，随便应付？这是非常重要的一点

fangang 写道

在论坛里看了很多对代码复查的讨论，感慨很多。大家对代码复查褒贬不一，总体来说，都认为必要，但难于实践，其中一个核心就是组织形式。组织得不好就会流于形式，甚至遭人厌。

我认为，代码复查要组织得好，要解决3个要点：谁来复查，何时复查与怎样复查。

1、谁来复查。当然是那个对被查者有权威和管理能力的人。让有能力的人担任组长去查，既赋予了管理权利，又从一定程度保证了权威性。

2、何时复查。过于频繁的复查代价太大，影响项目进度，但完成项目再查，很多问题生米已经煮成熟饭了，再修改代价会更大。按我的经验，项目刚开始，特别是新成员加入，要查得频点儿；步入正轨以后则按阶段复查。

3、怎样复查。简单的问题可以通过工具复查。人工的复查更多地应当放到设计思路上，即设计是否合理。

24 楼 wandou 2010-07-15  

提高代码质量的唯一途径是提高开发人员的整体技术水平。任何形式都是徒劳。
在开发水平没有得到提高的情况下，流程越复杂危害越大。

23 楼 danni505 2010-06-02  

代码复查的确是需要的，我们的项目也遇到了类似的问题，对于小组长或者是师徒关系的，在代码的质量控制上需要一个把关者，这样才能在项目后期体现出较低的bug率，项目维护的成本也会因此而减低。
这个在大项目中我觉得更重要，前期多投入点时间和成本做这个事情，一定会对后来的维护产生巨大的作用。
我支持这种管理方式！

更多欢迎和我交流MSN:[e-mail]

22 楼 fangang 2010-03-11  

还有就是责任，这一点很重要，否则就流于形式，这一点我体会太深了。

审查人如果多被审查的内容没有任何责任，审查人往往会随便提一些不痛不痒的问题就过去了，毕竟这是要得罪人的。久而久之，代码复查没有任何效果，渐渐就被人遗忘了。很多代码复查最后寿终正寝都是因为这个原因。

21 楼 gdpglc 2010-03-08  

hendrix00 写道

其实未必需要小组才可以，也可以随机分配代码复查任务，然后将复查结果都汇总到经理or负责人手中，再由负责人将意见结果分发给代码编写者，这样也没必要担心人际关系问题，因为谁也不知道是谁看的自己的代码。其实有人给自己意见是好事，感谢还来不及，哪有什么结怨的问题。唉，反正中国人的人际关系确实复杂，不是俺这个木头能理解的。建议老手和新手间互相进行代码复查，老手可以发觉新手存在的问题给予指导，而新手是张白纸，在染色的过程中也可以给老手一些新鲜的建议。

无记名纯以文档种形的代码复查没听说过，有没有人有过实践？
这种方法我想有以下问题：
1.代码复查纯以文档形式进行，必然使得交流完全依赖于文档，这样很不方便，有些信息可能不便传达。有些难以理解的代码，是不是需要复查者和被查者的交流？
2.被检查的人如果对复查结果有意见如何解决？强制执行没有多大意义。

20 楼 hendrix00 2010-03-05  

其实未必需要小组才可以，也可以随机分配代码复查任务，然后将复查结果都汇总到经理or负责人手中，再由负责人将意见结果分发给代码编写者，这样也没必要担心人际关系问题，因为谁也不知道是谁看的自己的代码。其实有人给自己意见是好事，感谢还来不及，哪有什么结怨的问题。唉，反正中国人的人际关系确实复杂，不是俺这个木头能理解的。建议老手和新手间互相进行代码复查，老手可以发觉新手存在的问题给予指导，而新手是张白纸，在染色的过程中也可以给老手一些新鲜的建议。

19 楼 fjlyxx 2010-02-25  

同意楼上的说法,如果人多事少 又有产品化需求 可以考虑严格的代码审查  但是对新手进行代码审查是很有必要的

18 楼 flyeagle 2010-02-24  

想法是好的，不过实施起来难度太大，尤其是小公司，一忙起来领导也是开发者，而且还是主力，想要抽出时间去做代码复查，几乎不可能，很多只要功能不出错，基本就算完了。

17 楼 fangang 2010-02-24  

在论坛里看了很多对代码复查的讨论，感慨很多。大家对代码复查褒贬不一，总体来说，都认为必要，但难于实践，其中一个核心就是组织形式。组织得不好就会流于形式，甚至遭人厌。

我认为，代码复查要组织得好，要解决3个要点：谁来复查，何时复查与怎样复查。

1、谁来复查。当然是那个对被查者有权威和管理能力的人。让有能力的人担任组长去查，既赋予了管理权利，又从一定程度保证了权威性。

2、何时复查。过于频繁的复查代价太大，影响项目进度，但完成项目再查，很多问题生米已经煮成熟饭了，再修改代价会更大。按我的经验，项目刚开始，特别是新成员加入，要查得频点儿；步入正轨以后则按阶段复查。

3、怎样复查。简单的问题可以通过工具复查。人工的复查更多地应当放到设计思路上，即设计是否合理。

16 楼 mercyblitz 2010-02-24  

fangang 写道

对于程序员，良好的编码习惯是慢慢养成的；
对于管理者，良好的编码习惯是必须通过指导和督促使其养成的。

管理者很多不写代码，架构师才干这事情。

15 楼 fangang 2010-02-24  

liubaoshan 写道

罗嗦了一大堆，没啥收获！

在这篇文章中，最为核心的内容是最后的“最佳实践”。认为文章过于冗长的朋友，可以跳过直接看最后一段。

14 楼 fangang 2010-02-24  

对于程序员，良好的编码习惯是慢慢养成的；
对于管理者，良好的编码习惯是必须通过指导和督促使其养成的。

13 楼 mercyblitz 2010-02-24  

楼主，冒失忽略了些问题:

1.开发水平和工作经验不一定成正比，更多地经验是关注于业务范畴，而不是从维护性和扩张性

2.良好的编码习惯是慢慢养成的，必须自己注重培养

3.业务逻辑问题可以由测试用例检验

4.Code review的过程是难以展开的，不是技术问题，而是人事。再说很少有项目经理会把代码质量放在项目首位

5.Code review不应该着重于重大问题，而是细小的环节。在维护中，记录下值得商榷的问题，有限度地修改。很多可能会在Code review之后，留下新的问题，带来不必要的成本。

12 楼 hommy8 2010-02-24  

听了多位的讨论，我却觉得学习了不少。尤其LZ的思想令我影响最深，LZ讲得非常中肯，非常实际。  记得好像有一本书叫什么代码重构的，应该不错...

我听说亚信里面，固定时间（可能是每个月吧）会展开代码审核会，每个成员要向所有同组的成员，把自己的代码展示出来供大家一起审核，项目经理基本都为每个新加入亚信的同事（里面可能有几年经验，新加入的新同事）指出编码不规范的地方。如果编码非常不规范，还要惩罚这个新同事。

我觉得整个项目组的编码规范都向同一个方向是一件好事，问题是如何能做到...

11 楼 liubaoshan 2010-02-23  

罗嗦了一大堆，没啥收获！

10 楼 wanjianfei 2010-02-23  

现在东西只能经理通过自己的经验和对下面开发人员的了解去把握了，不好把握，也不能一棒子打死

9 楼 zhangdp_neu 2010-02-23  

新手是一方面。
深层的原因，进度和质量的取舍。

8 楼 fangang 2010-02-23  

打蛇打七寸，提高代码质量也是如此。什么是高质量的代码其实是没有定论的，但新手代码质量不高却是大家的共识。因此我认为，要提高代码质量，最快捷而有效地办法就是应当把关注度更多地放到新手身上，快速提高新手的代码质量。这就是那个“七寸”！

7 楼 抛出异常的爱 2010-02-23  

cleanerje 写道

gdpglc 写道

我觉得：
对于新手的代码应该复查，因为：
一方面新手的代码的确存在许多问题；另一方面新手相对于老手比较谦虚。

对于有一到三年工作经验的人，我觉得代码复查有时不好进行。因为这时的程序员大都能写出正常运行的逻辑，因此通常不会出一些常见的毛病，比如： 类名、方法名命名错误、可以大段简化的逻辑、自已编写了库中已存在的方法、没有有关闭数据库连接、等等。这样的人在代码上出现的问题，我认为常常是需要一定理论支持的设计问题，不修改并不影响业务逻辑正确性，但却会使得代码在理论上没有好的可读性和可扩展性。这时，的代码复查很容易引起分歧，导致出现人员问的矛盾。
我想这时应该放松代码复查，不必苛求高质量的代码，只要能正确运行的代码就行了。

因此，对于有工作经验的代码复查得点应该放在得大缺陷上。而重在缺陷通常会出现在复杂逻辑的模块处。因此，对于有工作经验的人代码复查，应该针对复杂部分进行，并以查找重大缺陷为目的。

只要对代码进行增加或修改就要进行代码复查。
不要以为是老手就不进行复查，这是典型的思维无趣。
再说，不管是新手还是老手，如果写出的代码质量很好，复查花费的时间也会少很多。

深表怀疑......
PS:
1.代码审查质量会提高
但要有个限度.
只会过度优化.....
2.只有连作者也不能明确的代码
审查也没有用.