代码评审模板(参考)

2020-08-14  本文已影响0人  内沐

评审目标:

  1.尽早的发现和修复代码中的缺陷。

  2.以更好的共享和理解代码作为团队成员相互学习的基础。

  3.有助于保持设计和实现的一致性。

  4.帮助发现大家容易犯的共同错误,从而减少团队的返工。

  5.构建投资者对执行过程中技术质量的信心。

  6.大家对代码有一个平均的理解,这有助于提高团队成员的互换性,特别当某个成员无法继续工作的时候就显得尤为重要。

  7.从不同的角度看问题。“另外一双眼睛”增加了客观性。这个原因也是把开发和测试团队分开的原因,同行评审代码发现问题需要提供给他们一定的距离(译者注:这个距离可以使他们和代码的作者从不同的角度看问题)。

  8.骄傲/奖励。对他编码能力的认可对许多程序员来说,是一个显著的奖励。

  9.团队凝聚力。一起工作可以让团队成员变得更加紧密。它还可以让因为写代码而造成的隔离得到一个短暂的释放。   
编写者
检查项 是否符合?
代码没有编译错误
代码不仅包含单元测试用例,而且测试均已通过。
代码包含了恰当的注释和代码文档(如:JavaDoc)
代码是清晰明了的,包括缩进、行长、没有保留注释的代码、没有单词拼写错误,诸如此类)
恰当的使用了异常
恰当的使用了Log,方便运维的定位错误。
删除了未用的import语句
消除了所有 开发工具 报的警告错误
已尽可能的考虑了NPE
所有代码已符合代码规范
代码中没有遗留模板代码和测试用代码
代码中没有使用硬编码,也没有仅用于开发环境的代码。
性能问题是否有考虑?
安全问题是否有考虑?
代码中是否适当的释放了资源,比如HTTP连接、数据库连接、文件句柄等等。
框架中隐晦部分或特殊情况以文档化或者其它等价的方式说明。
是否优先使用可重用组件或库中相同功能的函数来替换自己的实现?
确保线程完全,避免死锁。

评审者
检查项 是否符合?
评审意见要通俗易懂并侧重于代码的可维护性。
评审意见是否言简意赅。
尽可能的使用泛型。
实参被恰当的使用。
异常被恰当的使用。
重复代码已被剔除。
框架被恰当的使用 – 方法被恰当的定义。
命令类被设计成只对应于某个单独的功能,而不是多合一。
代码中附带正确的单元测试用例
常见问题被标出。
潜在的线程问题被尽可能的排除。
所有考虑到的安全问题都被解决。
代码考虑了性能问题
代码实现与当前的产品设计及技术架构保持一致。
代码是可测试的
代码中是否包含不必要的静态方法或代码段。
代码完全符合代码标准
恰当的使用了Log,包括正确的Log级别和Log描述。
检查NPE

上一篇 下一篇

猜你喜欢

热点阅读