代码审查清单 Code Review

Posted 崔屹东

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了代码审查清单 Code Review相关的知识,希望对你有一定的参考价值。

代码审查清单

常规项

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

安全

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

文档

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

测试

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

优化你的清单

把使用清单作为你的起点,针对特定的使用案例,你需要对其进行优化。一个比较棒的方式就是让你的团队记录下那些在代码审查过程中临时发现的问题,有了这些数据,你就能够确定你的团队常犯的错误,然后你就可以量身定制一个审查清单。确保你删除了那些没有出现过的错误。(你也可以保留那些出现概率很小,但是非常关键的项目,比如安全相关的问题)。

得到认可并且保持更新

基本规则是,清单上的任何条目都必须明确,而且,如果可能的话,对于一些条目你可以对其进行二元判定。这样可以防止判断的不一致。和你的团队分享这份清单并且让他们认同你清单的内容是个好主意。同样的,要定期检查你的清单,以确保各条目仍然是有意义的。

有了一个好的清单,可以提高你在代码审查过程中发现的缺陷个数。这可以帮助你提高代码标准,避免质量参差不齐的代码审查。

分隔线


 

JAVA代码审查清单

代码审查可以帮助提高代码质量,避免由于代码习惯而造成的 bug。下面列出的这些要点因该可以作为大部分代码审查的指导,如果是 Java 应用的话,这些建议应该被视作最佳实践。

文档

1. Javadoc 应该在每一个类和方法中添加。

2. 如果是修复某个 bug,应该添加 bug ID。

3. 走捷径的方法或者复杂的逻辑要有解释。

4. 如果代码会被公开,每个文件头都要标注版权信息。

5. 复杂的 htmljavascript,CSS 应该包含文档。

功能

1. 如果类似的逻辑被使用了多次,应该把它写成一个帮助类,然后在多出调用。

2. 鼓励使用 API 而不是重复编写代码解决相同的问题。

3. 要强调代码的单元测试。

4. 任何新加的代码不应该破坏已有的代码。

5. 假如是 Web 应用,JSP 不应该包含 Java 代码。

技术分享

安全

1. 任何代码都不能执行用户的输入,除非转义过了。这个常常包含 JavaScript 的 eval 函数和 SQL 语句。

2. 禁止那些在短时间内提交非常多请求的 IP。

3. 任何类,变量,还有方法都应该有正确的访问域。

4. 尽量避免使用 iframe。

性能

1. 所有数据库和文件操句柄在不需要的时候都应该被关闭。

2. SQL 语句的写法会导致性能千差万别。

3. 鼓励创建不可变(immutable)的类。

4. 类似的逻辑代码,尽量通过 if else 语句来实现更多的重用。

5. 尽量避免使用重对象(heavy objects)。

6. 如果是 Web 项目,请检查是否使用了合适的图片尺寸,CSS sprites 和浏览器缓存等技术。

7. 全局都需要的信息保存在 application context 中。

编码习惯

1. 没有被使用的变量要删除。

2. 针对不同的 Exception 要用不同的 catch 语句,而不是一个 Exception 解决所有问题。

3. 针对变量,方法和类要用相同的命名方法。

4. 常量应该被写在独立的常量类中。

5. 每行代码的尾部不要有多余的空格。

6. 对于括号,循环,if语句等等要用统一的格式。

7. 每一个单独的方法不应该超过100行。

8. 一个单独的语句不应该超过编辑器的可视区域,它可以被拆分成几行。

9. 检查 String 对象既不是null也不是空的最好方法是 if(“”.equals(str))

10. 假如类有很多成员变量,并且实例化的时候只需要少数变量传入的话,最好使用静态工厂方法,而不是重载构造函数。

11. 给方法添加适当的访问控制,而不是所有都是 public。

12. 遵守项目中使用的框架的最佳实践建议,例如 Spring,Struts,Hibernate,jQuery。

以上的某些注意点可以通过静态代码检查工具完成,例如 CheckStyle,FindBugs 和 JTest。

以上是关于代码审查清单 Code Review的主要内容,如果未能解决你的问题,请参考以下文章

Jupiter Code Review Reference -- Jupiter代码审查工具使用参考

我是如何进行code review的

谈一下我们是如何开展code review的

记一次 C# 代码审查

PYTHON代码审查工具

PYTHON代码审查工具