如何从零开始作代码评审

以参考个人博客   如何用eclipse作代码的code review

最近和一个朋友讨论如何作公司代码的review，恰好我前段时间在看“腾讯开放平台”中的一个安全漏洞的check list(地址：http://wiki.open.qq.com/wiki/安全漏洞checklist)，因而就极力推荐这种模式。简单来讲，基本分以下几个步骤：

 

1.制做 code review须要的checklist。

check list简单说来就是一个检查清单列表。要作code review,咱们第一步是须要清楚咱们review到底要作哪些工做，而后咱们将他们一条一条的列在纸上，每一项是一个检查项。（咱们这里只简单的列了个清单，实际操做要复杂的多）。

 

NO	检查点
1	基本 1.代码可以成功构建，并执行 2.代码规范是否在严格执行（命名、缩进、函数长度限制、格式、注释） 3.项目规范是否在严格执行（目录命名规范、等） 4.是否存在重复的代码（复制粘贴或者重复开发，有库函数的地方调用库函数） 5.是否有须要模块化的代码 6.代码逻辑方面（未关闭的流，未结束的循环） 7.日志是否被正确的使用 8.其余（这只是demo，你们脑补吧）
2	安全 1.是否全部的输入项都进行了检查（长度、类型、格式、范围、防止脚本注入） 2.用户拼接参数，是否会有漏洞 3.防攻击的代码是否被正确的使用（xss,csrf,sql注入，每种语言都有本身的成熟的解决方案）
3	数据库 1.事物是否正确使用（隔离级别） 2.是否有正确的作sql优化 3.其余
4	其余 1.接口命名规范（好比遵循restful标准） 2.合理的使用注释中 TODO   REVIEW功能 3.复杂逻辑的代码是否有注释 4.性能方面 5.线程安全 6.其余

 

2.组织内部讨论

与你们分享并讨论咱们的 codereview清单是获取你们支持的最有效的方式。

checklist上的每一项都是未来要执行的工做，在内部讨论时，必需要明确咱们列表中的哪些项目是切实可行，符合如今公司的现状的，哪些有些过分为难你们（延期执行仍是放弃），还有哪些是被遗漏掉的。

要确保 check list中的每个检查项项都切实可行，不然规范就会失去可行性。

此外，咱们在内部讨论中还应该指定 评审的负责人（指定某我的仍是轮岗），评审时间（每周？每个月？），评审的覆盖率（抽查？全检查？）

 

3.以“sprint回顾会议”为基础，监督codereview执行

没有监督就没有落实，上班这几年见过太多的半途而废的制度。

可是管理是有成本的，通常的中小团队还没法单独的创建本身的管理和监督的部门，那咱们设立的制度如何保障执行呢？

在敏捷开发中有一个会议叫作“  

Sprint回顾会议

 ”，用来回顾总结咱们的工做。 将code review的执行状况作为回顾会议中的一项，能够确保咱们的正在正确的执行咱们的codereview的工做。当前对code review的建设性意见，也应该在这里提出来。

 

4.持续优化

没有什么是一成不变的，code review也不例外。

咱们实行了一段时间的  codereview，会有不少的心得体会。

1.check list中哪些检查项是不合理的，或者咱们从未出现的问题，是否要删除（有些问题不多出现可是很重，就不能删了）。

2.咱们遗漏了哪些很重要的检查项？

3.引入新的技术或者是咱们团队素质的提升，是否要加入更多的检查项？

 

去吧，优化咱们的清单，保持为咱们的团队量身打造清单。