Code Review 要点

Code Review 要点

参考要点

  • 编码习惯
  • 命名规范
  • 代码优化
  • 数据库
  • 规范习惯
  • 事务处理
  • 公共复用
  • 并发问题、
    代码注释
  • 依赖关系——是否引入了外部库或者API?是否有其它用不同依赖或者没有依赖的更简单/更快速/更好的方法来实现这一点?
  • 交互和副作用——新代码和代码库的其余部分是如何交互的;新功能是否破坏了任何现有的功能;是否所有相关的单元测试都被更新或添加
  • 日志记录——如果没有良好的日志,几乎不可能正确地调试服务器代码。是否所有东西都正确地记录或追踪
  • 异常处理——后端异常是如何处理的;它们是如何与用户沟通的;反馈是否在可能情况下激活?
  • 可测试性/测试覆盖率——新代码是否被自动测试覆盖?是否所有可疑的测试都被自动或手动地检查过?代码的编写方式是否适合单元测试?
  • 外部文档——如果有必要,更新外部文档反映变更?

如何给出建议

礼貌

一般而言,对于那些正在被您审查代码的人,除了保持有礼貌且尊重以外,重要的是还要确保您(的评论)是非常清楚且有帮助的。你并不总是必须遵循这种做法,但在说出可能令人不安或有争议的事情时你绝对应该使用它。 例如:

糟糕的示例:“为什么这里你使用了线程,显然并发并没有带来什么好处?”

好的示例:“这里的并发模型增加了系统的复杂性,但没有任何实际的性能优势,因为没有性能优势,最好是将这些代码作为单线程处理而不是使用多线程。”

解释为什么

关于上面的“好”示例,您会注意到的一件事是,它可以帮助开发人员理解您发表评论的原因。 并不总是需要您在审查评论中包含此信息,但有时候提供更多解释,对于表明您的意图,您在遵循的最佳实践,或为您建议如何提高代码健康状况是十分恰当的。

给予指导

一般来说,修复 CL 是开发人员的责任,而不是审查者。 您无需为开发人员详细设计解决方案或编写代码。

但这并不意味着审查者应该没有帮助。一般来说,您应该在指出问题和提供直接指导之间取得适当的平衡。指出问题并让开发人员做出决定通常有助于开发人员学习,并使代码审查变得更容易。它还可能产生更好的解决方案,因为开发人员比审查者更接近代码。

但是,有时直接说明,建议甚至代码会更有帮助。代码审查的主要目标是尽可能获得最佳 CL。第二个目标是提高开发人员的技能,以便他们随着时间的推移需要的审查越来越少。

接受解释

如果您要求开发人员解释一段您不理解的代码,那通常会导致他们更清楚地重写代码。偶尔,在代码中添加注释也是一种恰当的响应,只要它不仅仅是解释过于复杂的代码。

仅在代码审查工具中编写的解释对未来的代码阅读者没有帮助。这仅在少数情况下是可接受的,例如当您查看一个您不熟悉的领域时,开发人员会用来向您解释普通读者已经知道的内容。

怎么做,如何开展

  • 代码规范:明确Coding规则
  • 检视清单:结合业务特点,check重点
  • 总结优化:透明问题,持续优化
  • 激励措施:激发主观能动性
  • 开发者由于当初时间紧迫而觉得设计不合理的功能
  • 功能不完善
  • 设计有欠缺
  • 代码有更好实现方案
  • 重视项目代码的可读性

参考

  • 0
    点赞
  • 1
    收藏
    觉得还不错? 一键收藏
  • 打赏
    打赏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

CoLiuRs

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值