Code Review 要点
参考要点
- 编码习惯
- 命名规范
- 代码优化
- 数据库
- 规范习惯
- 事务处理
- 公共复用
- 并发问题、
代码注释 - 依赖关系——是否引入了外部库或者API?是否有其它用不同依赖或者没有依赖的更简单/更快速/更好的方法来实现这一点?
- 交互和副作用——新代码和代码库的其余部分是如何交互的;新功能是否破坏了任何现有的功能;是否所有相关的单元测试都被更新或添加
- 日志记录——如果没有良好的日志,几乎不可能正确地调试服务器代码。是否所有东西都正确地记录或追踪
- 异常处理——后端异常是如何处理的;它们是如何与用户沟通的;反馈是否在可能情况下激活?
- 可测试性/测试覆盖率——新代码是否被自动测试覆盖?是否所有可疑的测试都被自动或手动地检查过?代码的编写方式是否适合单元测试?
- 外部文档——如果有必要,更新外部文档反映变更?
如何给出建议
礼貌
一般而言,对于那些正在被您审查代码的人,除了保持有礼貌且尊重以外,重要的是还要确保您(的评论)是非常清楚且有帮助的。你并不总是必须遵循这种做法,但在说出可能令人不安或有争议的事情时你绝对应该使用它。 例如:
糟糕的示例:“为什么这里你使用了线程,显然并发并没有带来什么好处?”
好的示例:“这里的并发模型增加了系统的复杂性,但没有任何实际的性能优势,因为没有性能优势,最好是将这些代码作为单线程处理而不是使用多线程。”
解释为什么
关于上面的“好”示例,您会注意到的一件事是,它可以帮助开发人员理解您发表评论的原因。 并不总是需要您在审查评论中包含此信息,但有时候提供更多解释,对于表明您的意图,您在遵循的最佳实践,或为您建议如何提高代码健康状况是十分恰当的。
给予指导
一般来说,修复 CL 是开发人员的责任,而不是审查者。 您无需为开发人员详细设计解决方案或编写代码。
但这并不意味着审查者应该没有帮助。一般来说,您应该在指出问题和提供直接指导之间取得适当的平衡。指出问题并让开发人员做出决定通常有助于开发人员学习,并使代码审查变得更容易。它还可能产生更好的解决方案,因为开发人员比审查者更接近代码。
但是,有时直接说明,建议甚至代码会更有帮助。代码审查的主要目标是尽可能获得最佳 CL。第二个目标是提高开发人员的技能,以便他们随着时间的推移需要的审查越来越少。
接受解释
如果您要求开发人员解释一段您不理解的代码,那通常会导致他们更清楚地重写代码。偶尔,在代码中添加注释也是一种恰当的响应,只要它不仅仅是解释过于复杂的代码。
仅在代码审查工具中编写的解释对未来的代码阅读者没有帮助。这仅在少数情况下是可接受的,例如当您查看一个您不熟悉的领域时,开发人员会用来向您解释普通读者已经知道的内容。
怎么做,如何开展
- 代码规范:明确Coding规则
- 检视清单:结合业务特点,check重点
- 总结优化:透明问题,持续优化
- 激励措施:激发主观能动性
- 开发者由于当初时间紧迫而觉得设计不合理的功能
- 功能不完善
- 设计有欠缺
- 代码有更好实现方案
- 重视项目代码的可读性