如何从零开始做代码评审
最近和一个朋友讨论如何做公司代码的review，刚好我前段时间在看“腾讯开放平台”中的一个安全漏洞的check list(地址：http://wiki.open.qq.com/wiki/安全漏洞checklist)，于是就极力推荐这种模式。简单来说，基本分如下几个步骤：
2.组织内部讨论
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.其他 |
与大家分享并讨论我们的 codereview清单是获取大家支持的最有效的方式。
checklist上的每一项都是将来要执行的工作，在内部讨论时，必须要明确我们列表中的哪些项目是切实可行，符合现在公司的现状的，哪些有些过度为难大家（延期执行还是放弃），还有哪些是被遗漏掉的。
要确保 check list中的每一个检查项项都切实可行，否则规范就会失去可行性。
此外，我们在内部讨论中还应该指定
评审的负责人（指定某个人还是轮岗），评审时间（每周？每月？），评审的覆盖率（抽查？全检查？）
3.以“sprint回顾会议”为基础，监督codereview执行
没有监督就没有落实，上班这几年见过太多的半途而废的制度。
但是管理是有成本的，一般的中小团队还无法单独的建立自己的管理和监督的部门，那我们设立的制度如何保障执行呢？
在敏捷开发中有一个会议叫做“
Sprint回顾会议
”，用来回顾总结我们的工作。 将code review的执行情况做为回顾会议中的一项，可以确保我们的正在正确的执行我们的codereview的工作。当前对code review的建设性意见，也应该在这里提出来。
4.持续优化
没有什么是一成不变的，code review也不例外。
我们实行了一段时间的 codereview，会有很多的心得体会。
1.check list中哪些检查项是不合理的，或者我们从未出现的问题，是否要删除（有些问题很少出现但是很重，就不能删了）。
2.我们遗漏了哪些很重要的检查项？
3.引入新的技术或者是我们团队素质的提高，是否要加入更多的检查项？
去吧，优化我们的清单，保持为我们的团队量身打造清单。