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