Code Review 好文章

[sqliang]

写在前面

这里先给出程序员写代码相关的汇总
#45

code-review

知乎专栏

• 基础性材料： https://zhuanlan.zhihu.com/p/31581735 ，一个好的代码评审者，不仅需要找出代码中的 bug，还需要提供认真负责的反馈来让团队伙伴得到能力上的提升

  • 在一轮 review 中提出的问题越多，代码作者感到的压力会越大。一般情况下，一轮 review 提出的问题限制在 20-50 个之内
  • 在早期的 review 中先关注一些高层次的问题：重新设计的接口，分解复杂函数等，这些问题解决后在关注低层次的问题
  • review 代码提建议的时候可多写示例代码，通过写一些示例代码减轻作者的负担。 示例不仅局限于单行代码，也可以创建自己的分支，向作者展示大量的概念，如：拆解一个大的函数，或者添加单元测试来覆盖额外的边界情况
  • 使用请求的语气，而不是命令
  • 评论应该基于原则，而不是观点。当你写下一条评论，要记得同时写下要做什么以及为什么要做。软件开发既是一门艺术，也是一门科学。有些时候，即使有了既定的原则，你也不能清楚地证明一段代码是错误，因为有时代码只是丑陋或不直观而已。在这些情况下，请详细解释一下为什么，并保持客观。

• 进阶式材料：https://zhuanlan.zhihu.com/p/31786640， 介绍一些技巧，避免 review 过程中的不愉快。

  • 旨在把代码改进一到两个级别，不要追求完美

  • 对于相同的问题，有限度的反馈。对于同样的问题，只需重复注明2-3次即可。让作者修复类似的问题就好了，而不是去注明每一个问题

  • 遵循 review 的范围。如果变更列表没有涉及到这一行，那它就是超出 review 的范围。（除非新的修改影响了周围的代码）

  • 尝试切分体积很大的 review。你应该鼓励作者把它切分到更小的块。超过的越多，你就越应该打回这个变更列表

  • 真诚的表扬

  • 当剩下的问题都是小问题时，直接批准。

  • 主动处理僵持状态，说出来 -> 考虑涉及阶段的审查 -> 让步或者升级。如果问题一直没有得到解决，那么你最好选择让步，或者把问题升级

  • 脱离僵局之后，与你的上级讨论这种情况；休息一下；学会解决冲突

  • 重新思考 code review

    • 我做错了什么？
    • 我应该在最开始的时候给出一些高层次的评论，让作者不会因为大量的评论而感到挫折
    • 我应该给出更多的代码示例，以及在作者的变更列表中给出更多的积极因素
    • 我应该在所有的评论上都保持一个客观的态度
    • 我让这个僵局持续太久了，当出现没有意义的进展，我应该主动做出改变，来解决深层次的冲突，或者把它升级到我们的上级那里
    • Bob 第一步把 review 切换的做法非常有效。变成了一个一个更小的，更好管理的变更列表
    • Bob 没有尝试在 review 的过程中把代码改造成完美无缺的。对于某些特殊情况的处理，让他可以在长时间内帮助 Mallory 提升质量
    • 如果你觉得代码质量很难提升到符合你的标准，应该思考 review 的那些过程阻碍了你，以及如何解决它们