代码审查学习总结

代码评审

中文名 代码评审 别    名 代码复查 性    质 计算机 类    别 检查源代码与编码标准的符合性
目录
1 评审的内容：
2 代码评审的好处：
3 会前准备工作：
4 会议议程：
5 会后总结：
6 评审到什么程度：
7 实践要素：
▪ 人员结构
▪ 地理位置
▪ 所在领域
▪ 复杂性
评审的内容：
通过工具来进行code review不在本次讨论范围内。
编码规范问题：命名不规范、magic number、 System.out……
代码结构问题：重复代码、巨大的方法和类、分层不当、紧耦合
工具、框架使用不当：Spring、Hibernate、AJAX
实现问题：错误验证、异常处理、事务划分、线程、性能、安全、实现过于复杂、代码可读性不佳、扩展性不好
测试问题：测试覆盖度不够、可测试性不好
代码评审不负责检查功能、逻辑是否正确，这些要靠单元测试和QA工作来解决
代码评审的好处：
提高代码质量
在项目的早期发现缺陷，将损失降至最低
评审的过程也是重新梳理思路的过程，双方都加深了对系统的理解
促进团队沟通、促进知识共享、共同提高
交叉评审——代码走查：团队成员互相检查代码
参与者可以是任意两个组员，或开发组长分别与每个组员结对进行
时机可以选择在下班前半小时，对当天改动的模块进行评审
代码作者讲解如何以及为何这样实现、评审者提出问题和建议
每次解决的问题要记录到SVN注释或JIRA
每次评审不要贪多，如下图所示：当一次评审超过400行代码时，能发现缺陷数显著降低——事倍功半
会审：以项目为单位，召开专门的代码评审会议
参与者：包括项目组全体成员，其它组的开发组长也应尽量参加
时机选择：开发进行到某一阶段时，对共性问题进行总结，对好的做法进行提炼和推广
会前准备工作：
组织者应通知各参与者本次评审的范围
参与者阅读源代码，列出发现的问题、亮点，汇总给组织者
准备工作要细致，需要给出问题详细描述以及相关代码在SVN上的URL地址等
评审代码的选择：
最近一次迭代开发的代码
系统关键模块
业务较复杂的模块
缺陷率较高的模块
会议议程：
如果是第一次会议，先由该项目开发组长做整体介绍
参加者依次发言，结合代码讲解发现的问题
每讲完一个问题，针对其展开讨论，每个问题控制在10分钟以内
如果问题不多，还可以安排该组成员对最近开发的代码进行地毯式的讲解和排查；或者针对某个方面对整个项目做评审，例如性能、安全性或测试
会后总结：
把会上提出的所有问题、亮点及最终结论详细的记录下来，供其他团队借鉴
未能讨论清楚的问题，会后解决
实行代码评审制度前的准备工作：
架构师提供开发规范、指南，为代码评审提供依据
建立起单元测试规范，否则无法达到测试覆盖度的要求、难以修正发现的问题
最好有样例代码库作参照，以提高代码评审的可操作性
提供评审案例：用评审前的代码与评审后优化的代码做对比
问题跟踪：对评审中发现的问题代码应加以跟踪，确保问题得以解决，防止复发
评审到什么程度：
进行全面的代码评审成本较高，也没有必要
对发现的问题要本着集体代码所有制的观点和就事论事的原则，因此建议把代码质量与团队绩效（而不是个人绩效）挂钩
实践要素：
人员结构
在你的团队中有多少同事拥有足够的专业技能来担当合格的代码审查者？作者曾经和多个开发团队沟通过，这些团队都声称本身只有一个资深的开发人员，如果让他来负责所有的代码审查工作，那么团队的核心开发就无法开展了。作者也遇到过类似的情况。在一个小规模团队里，资深的同事总是忙不过来，因为核心的工作都在等着他做。
地理位置
你的团队成员是如何分布的？他们是否是分散在世界各地还是坐在同一个敞亮的办公室里？ 代码审查需要精力的专注和反馈，如果开发人员能够面对面的沟通，那么审查工作会便于实施。而物理隔离的远程团队很难达到代码审查的满意结果。
所在领域
你所在的IT领域需要遵守怎样的规则和约束呢？如果你在一个受到严格监管的行业，那么你必须遵循有关审计和报告的规则，这意味着你必须想办法跟踪代码审查的频率和质量。如果所在的领域把安全性作为重点，那么可能在代码审查过程中要引入安全审计。
复杂性
你的代码复杂性如何？在代码审查时，需要多个不同专业技能的审查者吗？例如，游戏开发可能会引入非常复杂的业务逻辑来处理文字交互和场景跟踪，同时还需要特定的动画处理和内存管理技术。在审查如此复杂的代码时，应该引入多个审查者从不同角度来检阅代码的质量。
========

高效代码审查的十个经验

http://www.csdn.net/article/2012-11-07/2811609-Efficient-Code-Review-10-Experience


摘要：我们在实践中发现，随着开发平台和开发语言的不同，最优的代码审查量有所不同。但是限制每次审查的数量确实非常必要，因为这个过程是高强度的脑力密集型活动。时间一长，代码在审查者眼里只是字母，无任何逻辑联系，自然不会有太多的产出。
代码审查（Code Review)是软件开发中常用的手段，和QA测试相比，它更容易发现和架构以及时序相关等较难发现的问题，还可以帮助团队成员提高编程技能，统一编程风格等。


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

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

“A的代码有个bug被B发现，所以A能力不行，B能力更好”，这一类的陷阱很容易被扩散从而影响团队内部的协作，因此需要避免。另外，代码审查本身可以提高开发者的能力，让其从自身犯过的错误中学习，从他人的思路中学习。如果开发者对这个流程有抵触或者反感，这个目的就达不到。

2.谨慎的使用审查中问题的发现率作为考评标准

高效代码审查的十个经验

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

3.控制每次审查的代码数量

根据smartbear在思科所作的调查，每次审查200行-400行的代码效果最好。每次试图审查的代码过多，发现问题的能力就会下降，具体的比例关系如下图所示：

高效代码审查的十个经验

我们在实践中发现，随着开发平台和开发语言的不同，最优的代码审查量有所不同。但是限制每次审查的数量确实非常必要，因为这个过程是高强度的脑力密集型活动。时间一长，代码在审查者眼里只是字母，无任何逻辑联系，自然不会有太多的产出。

4.带着问题去进行审查

我们在每次代码审查中，要求审查者利用自身的经验先思考可能会碰到的问题，然后通过审查工作验证这些问题是否已经解决。一个窍门是，从用户可见的功能出发，假设一个比较复杂的使用场景，在代码阅读中验证这个使用场景是否能够正确工作。

使用这个技巧，可以让审查者有代入感，真正的沉浸入代码中，提高效率。大家都知道看武侠小说不容易瞌睡，而看专业书容易瞌睡，原因就是武侠小说更容易产生代入感。

有的研究建议每次树立目标，控制单位时间内审核的代码数量。这个方法在我们的实践中显得很机械和流程化，不如上面的方法效果好。

5.所有的问题和修改，必须由原作者进行确认

如果在审查中发现问题，务必由原作者进行确认。

这样做有两个目的：

确认问题确实存在，保证问题被解决
让原作者了解问题和不足，帮助其成长
有些时候为了追求效率，有经验的审查者更倾向于直接修改代码乃至重构所有代码，但这样不利于提高团队效率，并且会增加因为重构引入新bug的几率，通常情况下我们不予鼓励。

6.利用代码审查激活个体“能动性"

即使项目进度比较紧张，无法完全的进行代码审查，至少也要进行部分代码的审查，此时随即抽取一些关键部分是个不错的办法。

背后的逻辑是，软件开发是非常有创造性的工作，开发者都有强烈的自我驱动性和自我实现的要求。让开发者知道他写的任何代码都可能被其他人阅读和审察，可以促使开发者集中注意力，尤其是避免将质量糟糕，乃至有低级错误的代码提交给同伴审查。开源软件也很好的利用了这种心态来提高代码质量。

7.在非正式，轻松的环境下进行代码审查

如前所述，代码审查是一个脑力密集型的工作。参与者需要在比较轻松的环境下进行该工作。因此，我们认为像某些实践中建议的那样，以会议的形式进行代码审查效果并不好，不仅因为长时间的会议容易让效率低下，更因为会议上可能出现的争议和思考不利于进行如此复杂的工作。

8.提交代码前自我审查，添加对代码的说明

所有团队成员在提交代码给其他成员审查前，必须先进行一次审查。这次自我修正形式的审查除了检查代码的正确性以外，还可以完成如下的工作：

对代码添加注释，说明本次修改背后的原因，方便其他人进行审查。
修正编码风格，尤其是一些关键数据结构和方法的命名，提高代码的可读性。
从全局审视设计，是否完整的考虑了所有情景。在实现之前做的设计如果存在考虑不周的情况，这个阶段可以很好的进行补救。
我们在实践中发现，即使只有原作者进行代码审查，仍然可以很好的提高代码质量。

9.实现中记录笔记可以很好的提高问题发现率

成员在编码的时候应做随手记录，包括在代码中用注释的方式表示，或者记录简单的个人文档，这样做有几个好处：

避免遗漏。在编码时将考虑到的任何问题都记录下来，在审查阶段再次检查这些问题都确认解决。
根据研究，每个人都习惯犯一些重复性的错误。这类问题在编码是记录下来，可以在审查的时候用作检查的依据。
在反复记录笔记并在审查中发现类似的问题后，该类问题出现率会显著下降
10.使用好的工具进行轻量级的代码审查

“工欲善其事，必先利其器”。我们使用的是bitbucket提供的代码托管服务。

每个团队成员独立开发功能，然后利用Pull Request的形式将代码提交给审查者。复审者可以很方便在网页上阅读代码，添加评论等，然后原作者会自动收到邮件提醒，对审阅的意见进行讨论。

即使团队成员分布在天南海北，利用bitbucket提供的工具也能很好的进行代码审查。
========

代码审查总结

http://blog.csdn.net/limingjian/article/details/40455071
       最近所带项目，因为人员素质良莠不齐，写出的代码质量不一，为了保证项目质量，不得不对代码一行行进行审查。同时，为了对代码审查有个更深的了解及借鉴其它同行实践成果，在网上搜集了不少项目知识，下面是对这些知识做出的整理。
第1章前提
       在 Wikipedia 上，对代码审查的定义是：代码审查（英语：Code Review）是指对计算机源代码系统化地审查，常用软件同行评审的方式进行，其目的是在找出及修正在软件开发初期未发现的错误，提升软件质量及开发者的技术。代码审查常以不同的形式进行，例如结对编程、非正式的看过整个代码，或是正式的软件检查。
1.1代码审查首先要求团队有良好的文化
      团队需要认识到代码审查是为了提高整个团队的能力，而不是针对个体设置的检查“关卡”。“A的代码有个bug被B发现，所以A能力不行，B能力更好”，这一类的陷阱很容易被扩散从而影响团队内部的协作，因此需要避免。另外，代码审查本身可以提高开发者的能力，让其从自身犯过的错误中学习，从他人的思路中学习。如果开发者对这个流程有抵触或者反感，这个目的就达不到。
1.2谨慎的使用审查中问题的发现率作为考评标准
      在代码审查中如果发现问题，对于问题的发现者来说这是好事，应该予以鼓励。但对于被发现者，我们不主张使用这个方式予以惩罚。软件开发中bug在所 难免，过度苛求本身有悖常理。更糟的是，如果造成参与者怕承担责任，不愿意在审查中指出问题，代码审查就没有任何的价值和意义。
第2章代码质量的属性
可理解性：代码需要在各个层面上能够被容易地理解。理想情况下，软件应该非常简单，并没有非常明显的缺陷。
可测试性：代码需要被编写的非常容易被测试。
正确性：代码需要满足功能和非功能性的需求。代码的行为是否与预期一致，其逻辑是否是正确无误的？被审查的代码是否与其他代码拥有类似的结构和功能？
有效性：代码需要有效的使用系统资源（内存，CPU，网络连接，等）。
第3章做代码审查的好处
更容易发现和架构以及时序相关等较难发现的问题。
帮助团队成员提高编程技能
统一编程风格
第4章代码质量低下的症状
所有事情都很艰难
进度慢
测试套件运行缓慢
无法避免的缺陷
你的团队是消极的
知识缺乏共享
新开发人员成长周期太长
第5章怎么审查
1个Review流程：先Review设计实现思路，然后Review设计模式，接着Review成形的骨干代码，最后 Review完成的代码，如果程序复杂的话，需要拆成几个单元或模块分别Review。
尽可能的让不同的人Reivew你的代码：不要总是只找一个人来Review你的代码，不同的人有不同的思考方式，有不同的见解，所以，不同的人可以全面的从各个方面评论你的代码，有的从实现的角度，有的从需求的角度，有的从用户使用的角度，有的从算法的角度，有的从性能效率的角度，有的从易读的角度，有的从扩展性的角度……这样以后会有更多的人帮你在日后维护你的代码。
保持积极的正面的态度：程序最大的问题就是“自负”，尤其当我们Reivew别人的代码的时候。所以，无论是代码作者，还是评审者，都需要一种积极向上的正面的态度，作者需要能够虚心接受别人的建议，因为别人的建议是为了让你做得更好；评审者也需要以一种积极的正面的态度向作者提意见，因为那是和你在一个战壕里的战友。
控制每次审查的代码规模：根据smartbear在思科所作的调查，每次审查200行-400行的代码效果最好。每次试图审查的代码过多，发现问题的能力就会下降。
要带着问题去做：我们在每次代码审查中，要求审查者利用自身的经验先思考可能会碰到的问题，然后通过审查工作验证这些问题是否已经解决。一个窍门是，从用户可见的功能出发，假设一个比较复杂的使用场景，在代码阅读中验证这个使用场景是否能够正确工作。使用这个技巧，可以让审查者有代入感，真正的沉浸入代码中，提高效率。
尽量使用静态代码分析工具以提高审查效率。
二八定律处理高风险代码：审查所有的代码并没有太大的意义，应该把审查的重点放在高风险的代码和容易引起高风险的修改或者重构的代码上。旧而复杂、处理敏感数据、处理重要业务逻辑和流程、大规模重构以及刚加入团队的开发者实现的代码都是审查的重点。
让原作者对发现的问题进行确认：这样做有两个目的，确认问题确实存在，保证问题被解决；让原作者了解问题和不足，帮助其成长。
自我审查：所有团队成员在提交代码给其他成员审查前，必须先进行一次审查。这次自我修正形式的审查除了检查代码的正确性以外，还可以完成如下的工作：
 对代码添加注释，说明本次修改背后的原因，方便其他人进行审查。
 修正编码风格，尤其是一些关键数据结构和方法的命名，提高代码的可读性。
从全局审视设计，是否完整的考虑了所有情景。在实现之前做的设计如果存在考虑不周的情况，这个阶段可以很好的进行补救。
代码审查结束后的回顾总结：成员在编码的时候应做随手记录，包括在代码中用注释的方式表示，或者记录简单的个人文档，这样做有几个好处：
 避免遗漏。在编码时将考虑到的任何问题都记录下来，在审查阶段再次检查这些问题都确认解决。
根据研究，每个人都习惯犯一些重复性的错误。这类问题在编码是记录下来，可以在审查的时候用作检查的依据。
在反复记录笔记并在审查中发现类似的问题后，该类问题出现率会显著下降。
第6章实践要素
人员结构
      在你的团队中有多少同事拥有足够的专业技能来担当合格的代码审查者？作者曾经和多个开发团队沟通过，这些团队都声称本身只有一个资深的开发人员，如果让他来负责所有的代码审查工作，那么团队的核心开发就无法开展了。作者也遇到过类似的情况。在一个小规模团队里，资深的同事总是忙不过来，因为核心的工作都在等着他做。
地理位置
     你的团队成员是如何分布的？他们是否是分散在世界各地还是坐在同一个敞亮的办公室里？ 代码审查需要精力的专注和反馈，如果开发人员能够面对面的沟通，那么审查工作会便于实施。而物理隔离的远程团队很难达到代码审查的满意结果。
所在领域
     你所在的IT领域需要遵守怎样的规则和约束呢？如果你在一个受到严格监管的行业，那么你必须遵循有关审计和报告的规则，这意味着你必须想办法跟踪代码审查的频率和质量。如果所在的领域把安全性作为重点，那么可能在代码审查过程中要引入安全审计。
复杂性
     你的代码复杂性如何？在代码审查时，需要多个不同专业技能的审查者吗？例如，游戏开发可能会引入非常复杂的业务逻辑来处理文字交互和场景跟踪，同时还需要特定的动画处理和内存管理技术。在审查如此复杂的代码时，应该引入多个审查者从不同角度来检阅代码的质量。
第7章一个时间安排的例子
      Eric Landes在一篇名为《敏捷技巧：什么时候以什么方式来进行代码评审》的文章中，提供了一个时间安排的例子：
概览本次代码评审的故事(10分钟)
讨论团队指标(10分钟)
强调评审的特别关注点(5分钟)
深入地评审代码(55分钟)
代码覆盖率
架构
深入的分析报告
总结并记录行动事项(10分钟)

第8章代码检查工具
Review board
Codestriker
Groogle
Rietveld
JCR
Jupiter
Find bugs
第9章参考资料
敏捷开发下平衡质量和进度
坚果云开发团队分享高效代码审查经验
Code Review中的几个提示
简单实用的Code Review工具
从Code Review 谈如何做技术
代码整洁之所以重要的七个理由
揭秘Google是如何做代码审查的
让代码审查成为你的团队习惯
关于代码审查的几点建议
我们如何进行代码审查
========