1秒でも早くプルリクをマージしたい
最近プルリクを作ったり見るときに考えてること。
前提
- プルリクはマージされてシップするまで顧客に対して価値を産んでいない
- 1秒でも早くマージしてシップすることが何より大切
- もちろん質をおろそかにしていいわけではない
この2つをレビュアーとレビュイーが共有する必要がある
どうやったら早くマージできるか
これは単純で
- プルリクの意図/価値を共有しておく
- やり取りの回数を減らす
- 指摘→修正→指摘→修正みたいなのはさける
- 読むべき量を減らす
だけでOK
レビュイーとして
- プルリクの意図を必ず書く
- 「なぜ」これが必要なのか
- 想定した問題やそれに対する考えなどがあったなら書く(パーマネントリンクを添えると最高)
- 想定した結果、あえて選択しなかった手段/方法とかもあるなら書いておいたほうがいい
- 余計な変更は入れない
- コードスタイルの変更などは読むときのノイズになる
- 伝わりづらい/自分でもわかりづらいと思うときはコードコメント or 行コメントを残しておく
- 確認しておきたい/見て欲しい箇所があるなら最初から書いておく
- プルリクのサイズを小さく
- 大きくなるなら実装途中とかで段階的にプルリクを見てもらう
- 設計レベルの差し戻しがあったときにも有効
- 大きくなるなら実装途中とかで段階的にプルリクを見てもらう
- コードの差分では伝わりづらいものに気をつける
- クエリ改善なら変更前後で発行されるSQLだったりEXPLAINの変化だったり
- 画面ならスクショだったり
レビュアーとして
- 細部にこだわりすぎない
- 気になるとこがあっても好みの問題だったり後で直せるレベルというならコメントだけ残しておくけど別に直さなくていいですとか書く
- コメントは後から見て気になったとこを思い出すためにも大事
- 気になるとこがあっても好みの問題だったり後で直せるレベルというならコメントだけ残しておくけど別に直さなくていいですとか書く
- どうやったらマージできるかを書く
- 指摘するだけじゃなくて、どうなったらうれしいかを書く
- 質問とか書いたとき、自分の理解を書いて合ってればマージしていいですと書いておく
後は
- 人が指摘しなくていいものは機械にやってもらいたい
元々は
kamipoさんと飲み会で話したときのに強く影響されています
最近のコードレビューは平和苑でkamipoさんに聞いた精神でやってる
— yak shaver (@chiastolite) 2017年5月30日
社内のサービスは早くマージすることが価値に繋がるのでどうしたらマージできるかを軸にして、OSS(というかRails)の場合は変なコードがマージされると大変なことになるので極力(変なもの不要なものを)マージをしない、させないみたいな話でした
— yak shaver (@chiastolite) 2017年5月31日
レビューのとき細部にこだわりすぎてしまうことがあるので、そういうときにあの話とわさびカルビを思い出すようにしてます!
— yak shaver (@chiastolite) 2017年5月31日