メンバーと1on1をしていると、「うっかりミスが多くて Pull Request で毎回コメントをもらってから気づくのを何とかしたい」という相談を受けることがある。
まず、そういう認識を持てていることが素晴らしい。課題意識があるのであれば、どう補正していくかを一緒に考えることができる。
自分がオススメしているやり方は、レビューを依頼する前に徹底的にセルフレビューすることである。巷でよくやられている方法ではあるが、どういうやり方かを雑に書いておく。
レビューを依頼する前に レビュワーになりきって 自分の Pull Request を自分でレビューしてみる
- 頭にレビュワーが思い浮かぶのであれば、その人を "憑依" させるイメージ
- 「この人はここでこういうコメントしそうだな」と思ったら、 先回りして PR上にコメントしておくか、突っ込まれないようにコードやコードコメントを改善する
タイトルや説明が、レビュワーにとって過不足ない内容になっているかを確認する
- PRテンプレートをの内容埋められてなかったり、必要な背景が記載されていなかったりしないか
- Pull Request は自分の作品 というつもりで仕上げることを意識するのが大事
- 特に不安なポイントなどを書いておくのもオススメ
余計な修正が入っていないか、全体的に確認する
- デバッグログが残っていたり、試行錯誤中の不要なコードが残っていたりしないか、自分で1~2周よく見てチェックするのが大事
- Pull Request は自分の作品 なので美しい状態になるよう仕上げきる
コードの意図が分かりづらいところにはセルフコメントを残す
- レビュワーの立場に立ってみて、なぜそうしているのか引っかかりそうなところには 先回りして コメントを残していく
- 例えば、共通化しなかった理由、命名で悩んで捨てた選択肢など
- 仕様がこれでいいのか分かりづらいところには、仕様の該当箇所のリンクを貼って説明しておくとかも
- 「この実装/テストはこのPRではなく次のPRで対応します」とかも。とにかく 先回り をすることが大事
- コメントを書いているうちに コードコメントに書いた方がいいな と気づくこともある
- このセルフコメントは、つけすぎるくらいの方がいい。レビュワーの負担を減らすことは、巡り巡って自分の負担を減らすことになる
意見をほしいところにはセルフコメントを残す
- 実は不安なところや、もっといい書き方があれば教えてほしいところなどにはその悩みをコメントしておく
- レビュワーからすると、どういう粒度でどういうコメントをすべきか悩ましいこともあるので、 先回りして 書いてくれていると非常にやりやすい
「自分のコードを確認するのって当たり前じゃない？」と思う人もいるかもしれない。それはそう。大事だよね。
あるいは、「それができれば苦労はしねえ」と思う人もいるかもしれない。それもそう。難しいよね。
それでも自分はセルフレビューをすることをオススメしたい。続けていくと、だんだんとレビュワーを"憑依"できるようになってきて、「ここでツッコミ受けそうだな」とか「これは説明しといた方がよさそうだな」とか先回りして考えられるようになってくる。
最初から全部できなくていい。少しずつ想像力を身につけていくことが大事なのだ。
このセルフレビューは、Pull Request だけではなく資料作成やデータ抽出などあらゆることに応用が効く。うっかりミスをなくせることはもちろん、他者の立場にたって物事を考える訓練にもなるので自分は好きなのだと思う。シャーマン・エンジニアリングしていきましょう。
