Code review 目的
1,尽早地发现bug;
这里并不是指一些简单的bug,而是一些可能是因为经验上不足而出现的潜在的bug。因此code review人员一定是要比较有经验的人担当。
2,帮助初级开发人员学习高级开发人员的经验,以达到知识共享;
这点也很重要,使得小组成员不断地进步,这样才能更有效地工作。
3,保证项目组成员有良好的沟通;
code review人员起着小组沟通桥梁的作用,而不是去熟悉每个单元代码,而去调试、编译等工作,那样还不如自己去写整个系统。
4,项目或产品的代码更容易维护;
这里就是检查代码规范、代码注释等。使得代码尽量统一化,最理想的效果是看不出是哪个具体人写的,而是哪个Team写的。
5,避免开发人员犯一些很常见,很普通的错误
好的代码应该:
1. 容易编写,可读性高,易于修改扩展。
2. 代码干净整洁,并表述准确。
3. 代码有价值,并注重质量。
Code Review检查的内容
- 测试文档检查
- 文档描述是否清晰,满足需求
- 测试point是否完整,测试是否cover整个feature.
- 测试用例是否详细,比如步骤,测试环境,预先需求。
- 自动化测试,手动测试等等。
- 类的检查
- 类是否过大。
- 是否可以用设计模式实现。
- 是否违反单一原则。
- 比较高级的面向对象设计原则SOLID (单一功能、开闭原则、里氏替换、接口隔离以及依赖反转)
- 方法检查
- 方法代码是否过长。个人感觉30行内比较好。
- 方法参数是否过多。
- 方法中是否包含复杂的表达式。
- 避免多处返回。
- 方法是否被循环重复调用。
- 代码风格检查
- 代码中的格式,符号,风格等是否一致。
- 使用一些统一的格式化技巧(缩进,空白),增加代码的清晰度。
- 命名规范。
- 避免不必要的Region。
- 常量变量检查
- 所有的变量都正确定义和使用。易于修改。
- 是否没有使用。
- 取值范围是否准确。
- 使用范围是否正确。
- 代码逻辑检查
- 死循环。
- 是否检查过循环是的第一个值、中间的某值和最后一个值。
- 是否正确的代码做正确的事情。
- 运行时错误(边界溢出,被零除,值越界,堆栈溢出)unchecked/checked.
- 参数个数是否正确
- 算法是否优化写法。委托,匿名委托,Lambda, Func/Action delegate.
- 性能检查
- 是否会造成性能上的问题,比如斐波那契数列用递实现。
- 注释检查
- 是否清楚描述上方法的功能。参数的意思。
- 注释是否足够,是否过少。
- 注释是否过时,更新代码后是否同时更新注释。
- Check in的时候完整的注释 做了什么修改
- 检查完必后提供相应的solution.