Code Review的正确姿势

2020/02/18 14:47

作者 wentao

How to Do Code Reviews Like a Human (Part One)

一个教工程师如何“有礼貌“(当然主要是提高效率,促进知识共享)的进行code review的“水文“。插图画的不错,风格有点像“老鼠什么都知道“。Code review的难点在reviewer提出修改意见后,很容易被作者(提交review request的人)理解为认为自己能力不行甚至是人身攻击,此外因为review意见是以文字形式表达,对方无法听到你的声音、看到你的表情和肢体语言,就更加容易误解(论线上聊天为什么这么难:D)。作者给的tips:

  1. Let computers do the boring parts,像code format、去掉没有用到的import之类的,自动化掉
  2. Settle style arguments with a style guide,code style上也别浪费太多精力,遵循一个标准就好
  3. Start reviewing immediately,不要block别人的工作,会3-way merge的人不多
  4. Start high level and work your way down,给出review note的时候,捡重要的、高屋建瓴的先说,别一股脑给太多把别人吓着
  5. Be generous with code examples,给出修改建议的时候如果能附带例子,会给对方很好的感受,显得你很关心他人(别只给关键词让别人搜)
  6. Never say “you”,尽量用“对事不对人“的表达方式写review note,可以考虑将“你”换成“我们“,或者去掉主语
  7. Frame feedback as requests, not commands,用祈使句,“Move the Foo class to a separate file.” -> “Can we move the Foo class to a separate file?”
  8. Tie notes to principles, not opinions,给出修改建议时附上原因,理据服,比如根据设计模式、高票stackoverflow回答等,不要仅仅出自自己很主观的看法

How to Do Code Reviews Like a Human (Part Two)

part 2 讲的是如何避免“陷入僵局”

  1. Aim to bring the code up a letter grade or two,别人的代码可能打分只有D,不要试图通过多轮review将其提升到A(很难,且对方会恨你),能提升到C就好了。不要担心整个codebase会退化为C级,下次他提交的时候会从C这个水平起步,一段时间后会逐渐改善
  2. Limit feedback on repeated patterns,同样的改进意见不用重复给出,指出两三处然后告诉对方pattern让其自行修正就好
  3. Respect the scope of the review,跟本次review主题无关的修改建议不要提或少提,比如提交修改的几行代码附近发现有人使用了magic number
  4. Look for opportunities to split up large reviews,应该没人想看超大的diff吧
  5. Offer sincere praise,大多数人只关注别人做错了什么
  6. Grant approval when remaining fixes are trivial,不用憋到所有issue都resolve了才approve
  7. Handle stalemates proactively,在陷入僵局的时候,主动去解决,先寻求线下沟通,如果还是很难解决,可能是项目的high level design有问题,可能需要更多人参与的design review。当僵局发生时,是适当让步还是让问题升级,有时候也比较需要智慧