こんにちは🐹
最近Kindleを買いまして、お風呂読書が進むようになりました笑
対象本
伝わるコードレビュー 開発チームの生産性を高める「上手な伝え方」の教科書
内容
レビュアーとレビュイーのそれぞれが気をつけることが対話の例付きで書かれておりました。
分類を行うと、以下の3点がコアな本書の伝えたいことかと思います。
- 相手を考える
- 内容は詳細に書く
- 評価対象は人間ではなくコードである
相手を考える
- 言葉選び
- クイズ形式にしない
まずは言葉選びです。なるべく気をつけた方がいいです。最近レビューを受けまして、書かれたコメントを元に自分で考えて修正を行いました。修正後に、「レビューのコメントが伝わってなく、時間がかかるからこちらで修正します。」と書かれてました笑 レビュイー（私）はこれを見て、やる気削がれましたね笑 なので、レビュイーを傷つけないような言葉選びをした方がいいです。
次にクイズ形式にしないです。例えば、「この記述はメソッドを使用したら1行でかけますが、なんだと思いますか」といったコメントです。レビュアーとレビュイーの間で立場関係が出来上がってしまうからです。両者の関係は対等でなければならないため、クイズ形式のレビューは行ってはいけません。また、レビュイーはレビュアーから試されているとプレッシャーを感じてしまうため、避けましょうということです。代わりとして、公式のドキュメントのリンクや、参考になりそうな記事を教えてあげる方が良いとのことでした。
内容は詳細に書く
- 対象のPRに何の実装を行ったか、何をレビュアーに見てほしいかを詳細に書く
- レビュアーはなるべく略さない
最近、レビューを行うことが増えました（業務委託ですが汗）。その中で、詳しい内容が書かれているPRは本当にレビューが行いやすいと感じております。特に、実装中にここでバグが起こりそうといった内容を書いていただけると、そこを中心に確認もできたのでありがたかったです。逆に、何も書かれていないPRが渡された時は「これは何をしたんだ？」となりましたので、レビュイーの方は書いていただけると助かります。
レビュアーの方も、レビュイー側がすでに共通認識としてあると考え、詳細にコメントを書かないことがあると思います。私も作成したapiのレビューを受けて、urlをこれに変更してほしいといったコメントが返ってきたことがあります。なので、そのurlに変えたところ、api/書かれていたurlになってないと言われて、「最初からそう書けばよかったじゃんか」と思ったことがあります。なので、略して書かずにしっかり書いた方がいいです。パスで表せば、私の経験が相対パスで、絶対パスで書いてくれた方が誤認は起こりにくいという感じでしょうか。
評価対象は人間ではなくコードである
書いてある通りですが、本当に意識した方がいいです。私もレビュー時にやらかすところでした。対象のPRでエラーが起こったまま、提出されていることが結構あります。そこで、「本当に確認した？これ、怠け？」と本当に感じてしまうんです。なので、どんなエラーが起こっているのか画像を貼り付け、レビュイー側のPCでも同じようなことが起きているのか確認を取り、一緒に原因を探すことをなるべく心がけています。イライラして、「PR前に確認作業しましたか？」なんて書いてはいけません。確認しているかもしれませんから、、、、
まとめ
- 相手を考える
- 内容は詳細に書く
- 評価対象は人間ではなくコードである
上記の点を意識するだけでもレビューはやりやすくなるのかなと思います。レビューも結局はコミュニケーションであり、練習するしかないのだと本書を通して感じました。私自身、コミュ力は一般人以下のミジンコなので、ここからでも頑張れたらいいなと思います。