产品研发质量保证----代码审计

邀请团队成员相互复查工作。复查的形式并不重要，结对编程（pair programming）、伙伴复查（buddy review）、同行复查（peer review）、走查（walk-through）、正式代码检查（formal code inspection）都可以。复查能够为项目方方面面带来好处。项目经理要为团队提供多种方法。这些方法以特定顺序介绍：从最不正式到最正式。以我的经验来看，这也可以从最有效和易于保持的，到最没有效果和难以维系的。

结对编程。先不要假定"这里没人愿意这么做"，要允许大家这么做。（而且可以提醒大家，他们已经完成过结对调试了。）我会问大家谁自愿进行结对。我建议他们在开始之前，先去阅读一些相关资源，比如［WK02］和［SH06b］，还有http://www.pairprogramming.com。

不出意外的话，会有人愿意尝试结对的。相对独自工作来说，他们可以学到如何通过结对编程使工作变得更有效率。

除了减少缺陷、加快开发速度外，结对编程还能带来很大的好处：有两个人完全熟悉并知道如何处理同一块代码。而且，如果人们经常切换不同的结对对象，他们就会深入了解目前团队正在开发的系统的各个部分。此外，对代码作者的反馈也没有延迟。

用哪种生命周期都没有关系。结对这种技术总是可以用来让更多人了解代码。

伙伴复查。伙伴复查无法达到与结对编程同样的学习效果。没错，每个人都可以了解产品某个功能的代码，但是不会像作者那样深入。作者得到的反馈也会有一点点延迟——即完成复查所需的时间。

同行复查。同行复查与伙伴复查的意思差不多（把你的代码给别人看看），但是很多人倾向于一次复查一个完整的模块，不管是一个文件还是几个文件。复查大量代码要更难，很难找出需要进行复查的大块时间，而且很难记住脑子里面所有的想法。

同行复查很难达到与伙伴复查同样的学习效果。以我的经验来看，这样做经常只能复查代码风格，而不是内容。对于作者的反馈延迟可以长达一星期。

走查。用走查的方式，一些人会集中在一个房间之内，由代码作者说明产品，过一遍文档。这里几乎没有团队学习的过程，而作者得到反馈的延迟时间也相当长——也就是用来组织会议需要的时间。

正式检查。如果做得好，正式检查可以帮助团队通过讨论了解产品。不过我很少看到正式检查能够在组织内长久实施下去。即使是启动检查的人，也很难维持检查的动力。

维持检查很困难，因为检查别人的代码会打乱每个人的节奏，还有项目的节奏。要想进行一次费根式（Fagan-style）的检查，人们必须离开自己的工作任务上下文，详细阅读产品代码，准备评论自己看到的东西。我发现，为了一次两小时的检查会议，要花上几小时甚至一天的时间去准备。

费根式检查（Fagan inspection）是一种在开发文档中试图发现缺陷的结构化过程。这些文档可以包括代码、需求说明、设计文档以及其他软件开发过程涉及的文档.

为了保证产品的质量，代码的审计工作应该纳入到日常的管理规范里面，每周每个开发人员的任务里面至少有一项审计任务。审计别人代码的同时能学到别人的编码技巧和思路，同时也能保证整个团队的风格是一致的。