对于代码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的，如果修改的话可能又要花上一些时间，此时项目的进度方面将无法保证，该如何去做？
