码迷,mamicode.com
首页 > 其他好文 > 详细

如何做好Code Review? 分享一份我们团队的 Checklist

时间:2020-11-13 12:33:40      阅读:3      评论:0      收藏:0      [点我收藏+]

标签:手记   责任   公众号   导致   一起   net   针对   修改   上线   

如何做好Code Review? 分享一份我们团队的 Checklist

对于很多团队来说,code review通常充满争议。即使团队知道code review很值得,但他们仍然难以使之奏效。code review通常会成为每个人的主观意见的发泄地,这会导致团队内部的争论、感情伤害和不信任。

一旦团队中开始出现不信任,就很难恢复。敌意会增长,积极性会下降,信心也会下降。代码质量也会受到影响。基于这些原因,code review流程尽量客观对你的团队的成功至关重要。

那么,如何使code review尽量客观呢?我建议你使用一个checklist。

Checklists 如何工作

创建和维护一个checklist可以让代码review不会导致团队情绪紧张。我们都知道什么是checklist。NASA将checklist提升到了另一个层次,他们为太空飞行中涉及的每一个过程定义了checklist。发射、着陆、太空行走等每个过程都有对应的checklist。

为什么要这样做?因为他们知道,在实际决策之前,通过对容易出问题的地方仔细思考,可以尽可能地消除决策的主观性。

讨论决策的目的是让所有参与的各方都能发表自己的意见,而不至于担心决策的压力。试想一下。如果你是任务控制部门的负责人,而受训多年的宇航员在发射台待命,而天气只是有点微妙,在那一刻,你有很大的压力。如果你尚未定义可接受的天气条件的阈值,那么几乎不可能做出决定。

Gene Krantz在《失败不是一种选择》(Failure Is Not an Option)一书中写到了其中的一些压力,这本书是他从头开始帮助NASA建立任务控制的回忆录。在书中,Gene讨论了他在NASA的职业生涯中所经历的失败和成功。吃一堑,长一智,从每次失败/成功中总结经验教训。他们总结这些教训的方式是调整每个过程的checklist。有了这些checklist后,他们不仅更容易做出 "去/不去 "的决定,而且他们有信心做出正确的决定。

Code Reviews 也很重要

让我们先说清楚:code review并不像将人送入太空的决定那样紧张。

然而,code review是很重要的。软件已经延伸到各个领域。医学、金融、驾驶...........航天。你所处的行业可能不需要像上面列出的一些行业那样有严格的要求,然而你写的代码会影响到人!你所写的代码会影响到世界。

作为软件工程师,我们需要尽早承担起自己作为软件工程师的责任。我们不能成为懒惰的开发人员,我们不能成为懒惰的review人员,看到代码就随便盖章。我们不能在没有测试验证修改的情况下就批准代码上线。我们不能在最后期限内忽略了代码变坏的明显迹象。

你需要一个checklist。

如何开始

你可能会想知道,我是如何开始的。"你说的很有道理,但我怎么才能弄清楚哪些是在checklist上,哪些不是?"

我的建议是这样的:你去写一份入门checklist。其中包含要你在review中的要求。在你review的过程中亲自参考你的这个checklist,并密切关注你review的代码。随着时间的推移,对它进行细化和增减。

一旦你使用了几次个人checklist,就把它向你的团队开放。不要把它强行塞给任何人,也不要强制要求使用它。只需把它作为共享资源即可。然后你的队友会帮助你完善它,并加入自己的想法/观点。即使他们会在一些事情上不同意你的观点,但如果你在其中花了心思,他们也很有可能会赞赏并使用它。

一旦每个人都开始使用它,那么就可以把它做成一个Google Doc,在每次code review时,你都会把它放在每个开发人员面前。确保它和你的团队的入职指南放在一起。要保证每个人都知道checklist的存在并能随时找到它。

例子

万事开头难。我不一定能帮你完成,但希望我可以帮助你开始。

我们的code review checklist相当短。某些应用程序中有一些针对特定问题的附加项,这些问题通常会被遗漏。我不能分享我们使用的checklist的这些细节,但它的基础部分看起来是这样的。

  • 这些代码更改是否符合业务需求?
  • 这些代码更改是否符合团队的编码质量要求?
  • 这些代码更改是否有相关的测试?
  • 这些代码更改是否有截图或用户界面更改?
  • 是否为这些代码更改更新了变更日志?
  • 是否为这些代码更改更新了应用文档?

这个checklist并不关注细节,比如 "我的变量是否被正确命名",因为这些包含在第二项中。它关注代码review的核心,也就是理解。

checklist可长可短,我的建议是,越短越好,就像没有人想成为code monkey一样,也没有人想成为code review monkey(指按照checklist做机械检查)。让你的checklist专注于帮助作者和reviewer思考经常被遗忘的事情,这对你的团队会有很大的帮助。

英文原文:
https://levelup.gitconnected.com/you-need-a-code-review-checklist-1524e6a2d2cd

参考阅读:

  • 分布式算法 Paxos 的直观解释 (TL;DR)
  • 重构,还是重写?(2020版)
  • 为什么 Kubernetes 变得如此流行(2020版)
  • Pull Request 的艺术
  • Grab熔断器设计:如何应对突发打车峰值
  • 手记:在 MacBook 上运行 Linux 那些坑

本文由高可用架构翻译,技术原创及架构实践文章,欢迎通过公众号菜单「联系我们」进行投稿。

高可用架构

改变互联网的构建方式

技术图片

如何做好Code Review? 分享一份我们团队的 Checklist

标签:手记   责任   公众号   导致   一起   net   针对   修改   上线   

原文地址:https://blog.51cto.com/14977574/2546116

(0)
(0)
   
举报
评论 一句话评论(0
登录后才能评论!
© 2014 mamicode.com 版权所有  联系我们:gaon5@hotmail.com
迷上了代码!