Code Review

详解

翻译为代码审查，大白话就是在代码提交后，由管理员或几个人对提交的差异内容进行审核，一般包括如下 常规项：

1. 代码能够工作么？它有没有实现预期的功能，逻辑是否正确等。
2. 所有的代码是否简单易懂？
3. 代码符合你所遵循的编程规范么？这通常包括大括号的位置，变量名和函数名，行的长度，缩进，格式和注释。
4. 是否存在多余的或者重复的代码？
5. 代码是否尽可能的模块化了？
6. 是否有可以被替换的全局变量？
7. 是否有被注释掉的代码？
8. 循环是否设置了长度和正确的终止条件？
9. 是否有可以被库函数替代的代码？
10. 是否有可以删除的日志或调试代码？

安全：

1. 所有的数据输入是否都进行了检查（检测正确的类型，长度，格式和范围）并且进行了编码？
2. 在哪里使用了第三方工具，返回的错误是否被捕获？
3. 输出的值是否进行了检查并且编码？
4. 无效的参数值是否能够处理？

文档：

1. 是否有注释，并且描述了代码的意图？
2. 所有的函数都有注释吗？
3. 对非常规行为和边界情况处理是否有描述？
4. 第三方库的使用和函数是否有文档？
5. 数据结构和计量单位是否进行了解释？
6. 是否有未完成的代码？如果是的话，是不是应该移除，或者用合适的标记进行标记比如‘TODO’？

测试：

1. 代码是否可以测试？比如，不要添加太多的或是隐藏的依赖关系，不能够初始化对象，测试框架可以使用方法等。
2. 是否存在测试，它们是否可以被理解？比如，至少达到你满意的代码覆盖(code coverage)。
3. 单元测试是否真正的测试了代码是否可以完成预期的功能？
4. 是否检查了数组的“越界“错误？
5. 是否有可以被已经存在的API所替代的测试代码？

推荐方法

Code Review的目的除了提高代码质量，提前发现bug外，还包括统一团队的代码规范，比如经常会碰到有人说你这个变量命名不对，或者这里缩进不应该用tab，甚至这里应当多加一个空白行。而类似架构或者设计模式这样的“大”问题，我个人觉得并不适合在code review的时候去讨论。如果这方面有问题，那说明之前design review没有做好或者有可能根本没有做design review。

像我软内部，我所知道的范围内所有代码都是需要code review的。具体的规则可能每个部门各不相同，比如有的部门给每个组件规定几个owner，改到那块代码必须找至少一个owner做review。有的部门还规定每次code review至少要有一个senior级别以上的码农参与，等等。

从工具上来说，现在的码农还是比较幸福的了。n年以前做code review，就是自己做个bbpack发到邮件上，其实就是一个diff，reviewer就看着windiff，有意见的就拿个小本本记下来：某某行号，某某问题，然后email沟通。

后来车库计划（利用员工闲暇时间随便做点什么的一个计划）里面有人做了一个新的code review工具，叫CodeFlow，极大改善了我们做code review的体验，病毒式地传播到了公司各个部门，可以算是车库计划最成功的项目了。

file

CodeFlow主要把code review的过程做成了一个聊天式的体验，你对哪段code有意见，直接选取那段code然后加个comment，对方就需要对此做出回应。比如你说这个函数名字起的不够优雅，对方可以采取你的意见修改并把这个comment设置成fixed；当然他也可以认为没必要改而设成won’t fix；当然你也可以继续和他撕下去。

当review的作者按照意见修改了一遍代码后，他可以发出一个新的iteration（迭代），然后reviewer们在新的iteration基础上可以再次提出新的意见。

最后每个reviewer可以设置此次review的状态，比如reviewing（正在review），或者waiting（在等作者修改），设成signed off就表示通过了。

总的来说大家对CodeFlow还是挺满意的，它的功能现在基本上都在Visual Studio里面整合了，其他答案也已经有人提到Visual Studio的code review功能了。