对于代码 review 个人也有些小小的看法：
1．首先我觉得我们所有开发人员要弄明白 现在 Code Review 的目的 ，凡事不弄明白目的，
无法做好完成一件事情，个人觉得有以下一些目的：
a)可以在项目早期就能够发现代码中的 BUG ，提测后可以尽快的释放开发资源；
b)同时可以达到知识共享 ，避免我们所有开发人员犯一些很常见，很普通低级的错误 ；
c)保证项目组人员的良好沟通 ，项目的代码更容易维护
大家还有希望补充上
2．Code Review 很容易变得没有意义或是流于形式，进入 Code Review 个人觉得以下几点
肯定得弄明确：
a) 我们是否理解了 Code Review 的概念和 Code Review 将做什么，这点都不明白，做法可能
就会是应付了事。
b) 我们的代码是否已经正确的 build ， build 的目的使得代码已经不存在基本语法错误 ，我
们总不希望 review 人员浪费在检查连编译都通不过的代码上吧。
c) 我们 Review 人员是否理解了代码 ，做复查的人员需要对该代码有一个基本的了解，其
本功能是什么，具体的业务是怎样的，这样才能采取针对性的检查
3 .具体检查点
1 完整性检查
代码是否完全实现了设计文档中提出的功能需求
代码中是否存在任何没有定义或没有引用到的变量、常数或数据类型
2 一致性检查
代码的逻辑是否符合设计文档
代码中使用的格式、符号、结构等风格是否保持一致
3 正确性检查
代码是否符合制定的标准
所有的变量都被正确定义和使用
所有的注释都是准确的
4 可修改性检查
代码涉及到的常量是否易于修改 ( 如使用配置、定义为类常量、使用专门的常量类等 )
5 可预测性检查
代码是否具有定义良好的语法和语义
代码是否无意中陷入了死循环
代码是否是否避免了无穷递归
6 健壮性检查
代码是否采取措施避免运行时错误（什么空指针异常等，有很多是程序里面处理了，
但打印日志时没有判断，不知道大家有没有犯过这样的错误哟）
7 可理解性检查
注释是否足够清晰的描述每个子程序 ，对于没用的代码注释是否删除
是否使用到不明确或不必要的复杂代码，它们是否被清楚的注释
- 1
- 2
前往页