代码评审模板(参考)
2020-08-14 本文已影响0人
内沐
评审目标:
1.尽早的发现和修复代码中的缺陷。
2.以更好的共享和理解代码作为团队成员相互学习的基础。
3.有助于保持设计和实现的一致性。
4.帮助发现大家容易犯的共同错误,从而减少团队的返工。
5.构建投资者对执行过程中技术质量的信心。
6.大家对代码有一个平均的理解,这有助于提高团队成员的互换性,特别当某个成员无法继续工作的时候就显得尤为重要。
7.从不同的角度看问题。“另外一双眼睛”增加了客观性。这个原因也是把开发和测试团队分开的原因,同行评审代码发现问题需要提供给他们一定的距离(译者注:这个距离可以使他们和代码的作者从不同的角度看问题)。
8.骄傲/奖励。对他编码能力的认可对许多程序员来说,是一个显著的奖励。
9.团队凝聚力。一起工作可以让团队成员变得更加紧密。它还可以让因为写代码而造成的隔离得到一个短暂的释放。
编写者 | |
---|---|
检查项 | 是否符合? |
代码没有编译错误 | |
代码不仅包含单元测试用例,而且测试均已通过。 | |
代码包含了恰当的注释和代码文档(如:JavaDoc) | |
代码是清晰明了的,包括缩进、行长、没有保留注释的代码、没有单词拼写错误,诸如此类) | |
恰当的使用了异常 | |
恰当的使用了Log,方便运维的定位错误。 | |
删除了未用的import语句 | |
消除了所有 开发工具 报的警告错误 | |
已尽可能的考虑了NPE | |
所有代码已符合代码规范 | |
代码中没有遗留模板代码和测试用代码 | |
代码中没有使用硬编码,也没有仅用于开发环境的代码。 | |
性能问题是否有考虑? | |
安全问题是否有考虑? | |
代码中是否适当的释放了资源,比如HTTP连接、数据库连接、文件句柄等等。 | |
框架中隐晦部分或特殊情况以文档化或者其它等价的方式说明。 | |
是否优先使用可重用组件或库中相同功能的函数来替换自己的实现? | |
确保线程完全,避免死锁。 |
评审者 | |
---|---|
检查项 | 是否符合? |
评审意见要通俗易懂并侧重于代码的可维护性。 | |
评审意见是否言简意赅。 | |
尽可能的使用泛型。 | |
实参被恰当的使用。 | |
异常被恰当的使用。 | |
重复代码已被剔除。 | |
框架被恰当的使用 – 方法被恰当的定义。 | |
命令类被设计成只对应于某个单独的功能,而不是多合一。 | |
代码中附带正确的单元测试用例 | |
常见问题被标出。 | |
潜在的线程问题被尽可能的排除。 | |
所有考虑到的安全问题都被解决。 | |
代码考虑了性能问题 | |
代码实现与当前的产品设计及技术架构保持一致。 | |
代码是可测试的 | |
代码中是否包含不必要的静态方法或代码段。 | |
代码完全符合代码标准 | |
恰当的使用了Log,包括正确的Log级别和Log描述。 | |
检查NPE |