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