对于代码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可理解性检查
       注释是否足够清晰的描述每个子程序 ,对于没用的代码注释是否删除
       是否使用到不明确或不必要的复杂代码,它们是否被清楚的注释
       使用一些统一的格式化技巧(如缩进、空白等)用来增强代码的清晰度
       是否在定义命名规则时采用了便于记忆,反映类型等方法
      循环嵌套是否太长太深?
8可验证性检查
       代码中的实现技术是否便于测试
具体的杨帅同学也整理的很多很多,希望我们讨论会上所有人员能达成一个共识,慢慢去完善!

最后抛出一个问题,希望大家抛砖
Review中,我们发现开发人员代码的一些非逻辑问题(辟如:不符合面象接口编程的思想等,只是个举例,嘿嘿),不修改也行,因为逻辑是OK的,如果修改的话可能又要花上一些时间,此时项目的进度方面将无法保证,该如何去做?