代码审查(Code Review)

代码审查(Code Review)

一、概述

代码审查（Code Review)是软件开发中常用的手段，和QA测试相比，它更容易发现和架构以及时序相关等较难发现的问题，还可以帮助团队成员提高编程技能，统一编程风格等，目前监控团队虽然提倡代码审查，也有相关的辅助工具，但是一直没有真正的推行起来，这半年的时间里，一些线上的bug如果经过代码审查，基本上可以避免的，大家也逐渐认识到代码审查可以有效地提高代码质量。

二、代码审查的作用

1、提高代码质量。

通过代码审查来发现bug及代码中的不规范，这是不容置疑的，通过代码审查，代码将更加整洁，有更好的注释，更好的程序结构。

2、提高开发者开发水平。

开发者知道自己编写的代码会被同事审查，将会更加认真的编写代码，也将会督促开者不断地学习、向有经验的同事请教。

3、提高程序的可维护性。

一份程序代码将会有更多的同事熟悉，更好的代码质量，自

然地也增加程序的可维护性。

4、提高开发者的对编码的责任感。

如果你在编程，而且知道将会有同事检查你的代码，你编程态度就完全不一样了。你写出的代码将更加整洁，有更好的注释，更好的程序结构——因为你知道，那个你很在意的人将会查看你的程序。没有代码审查，你知道人们最终还是会看你的程序。但这种事情不是立即发生的事，它不会给你带来同等的紧迫感，它不会给你相同的个人评判的那种感受。

5、传播知识

在很多的开发团队里，经常每一个人负责一个核心模块，每个人都只关注他自己的那个模块。除非是同事的模块影响了自己的程序，他们从不相互交流。这种情况的后果是，每个模块只有一个人熟悉里面的代码。如果这个人休假或——但愿不是——辞职了，其他人则束手无策。通过代码审查，至少会有两个人熟悉这些程序——作者，以及审查者。审查者并不能像程序的作者一样对程序十分了解——但他会熟悉程序的设计和架构，这是极其重要的。

三、代码审查的执行障碍

1、缺少代码审查的标准

缺少代码审查的标准，往往审查人员习惯性地根据自身开发经验去进行代码审查，容易变成去挑毛病，找bug，容易产生

不良地影响。

2、资深开发人员的较少，工作过多，缺少代码审查的时间安排

在一个小规模团队里，资深的同事总是忙不过来，因为核心的工作都在等着他做，资深的开发人员少，代码审查的质量自然上不去。

3、团队成员的技术差距过大

一个团队中往往有不少经验较浅的开发人员，当然编码水平也就相对较差，如果缺少有效的激励手段，往往资深的开发人员是比较讨厌经常去审查经验很浅的开发人员的代码。

四、代码审查的实践要素。

虽然代码审查是一个被广泛采纳的实践，但是由于存在很多的实践方式，所以开发团队经常搞不清楚它的最佳实践是什么样的，正确的代码审查应该重点考虑的几个因素有以下几点。

1、人员结构

在你的团队中有多少同事拥有足够的专业技能来担当合格的代码审查者？作者曾经和多个开发团队沟通过，这些团队都声称本身只有一个资深的开发人员，如果让他来负责所有的代码审查工作，那么团队的核心开发就无法开展了。作者也遇到过类似的情况。在一个小规模团队里，资深的同事总是忙不过来，因为核心的工作都在等着他做。

2、地理位置

你的团队成员是如何分布的？他们是否是分散在世界各地还是坐在同一个敞亮的办公室里？代码审查需要精力的专注和反馈，如果开发人员能够面对面的沟通，那么审查工作会便于实施。而物理隔离的远程团队很难达到代码审查的满意结果。3、所在领域

你所在的IT领域需要遵守怎样的规则和约束呢？如果你在一个受到严格监管的行业，那么你必须遵循有关审计和报告的规则，这意味着你必须想办法跟踪代码审查的频率和质量。如果所在的领域把安全性作为重点，那么可能在代码审查过程中要引入安全审计。

4、复杂性

你的代码复杂性如何？在代码审查时，需要多个不同专业技能的审查者吗？例如，游戏开发可能会引入非常复杂的业务逻辑来处理文字交互和场景跟踪，同时还需要特定的动画处理和内存管理技术。在审查如此复杂的代码时，应该引入多个审查者从不同角度来检阅代码的质量。

而且在许多情况下，不同的项目有不同的需求——存在多个团队构建应用，需要不同的配置文件。这里有一些技巧可以帮助你改进代码审查过程的工具并解决一些可能会面临的问题：A.促进沟通

任何审查过程，不论是代码还是文档还是绩效，最好是面对面进行。在你使用工具做完代码审查之后，与相应的开发人员约个时间做口头的反馈。如果你们不在同一地区，可以利用视频或者电话来进行沟通，但是这种沟通是必要的，你可以以此作为协作和指导的一种手段。

B.利用专业技能

如果被审查的代码与其他代码领域存在关联，或者对安全、性能、可扩展性等方面存在一定的影响，你可能无法只安排一个人来完成审查工作。你需要多个人来查看代码以确保所有可能的后果都被考虑在内。在这种情况下，最好找到一个工具来协助多个人完成审查工作。该工具的作用包括指定哪个人审查哪个角度并把相应的代码展现出来，而且还可以保存审查人员的注解。

C. 公开审查意见

审查工具的优点之一是多人可以集中地审查相同的代码。把所有人叫到一个屋子里做团队审查非常不利于大家考虑各个不同的方面。但是工具可以帮助你让大家分别查看代码并把所有的意见集中起来：

•避免意见重复，如果别人已经发表了类似的看法，那么后面的人就不用记录了。

•团队学习，通过查看别人的意见能够学习其他人的思维角度和专业领域。

•监督审查过程。

五、代码审查的一些常用经验与注意事项。

1.代码审查要求团队有良好的文化

团队需要认识到代码审查是为了提高整个团队的能力，而不是针对个体设置的检查“关卡”。

“A的代码有个bug被B发现，所以A能力不行，B能力更好”，这一类的陷阱很容易被扩散从而影响团队内部的协作，因此需要避免。

另外，代码审查本身可以提高开发者的能力，让其从自身犯过的错误中学习，从他人的思路中学习。如果开发者对这个流程有抵触或者反感，这个目的就达不到。

2.谨慎的使用审查中问题的发现率作为考评标准在代码审查中如果发现问题，对于问题的发现者来说这是好事，应该予以鼓励。但对于被发现者，我们不主张使用这个方式予以惩罚。软件开发中bug在所难免，过度苛求本身有悖常理。更糟的是，如果造成参与者怕承担责任，不愿意在审查中指出问题，代码审查就没有任何的价值和意义。

3.控制每次审查的代码数量根据smartbear在思科所作的调查，每次审查200行-400行的代码效果最好。每次试图审查的代码过多，发现问题的能力就会下降，