自分がコードレビューでレビュアー側にたった場合の作法について心構えや具体的な言い方、伝え方などをまとめてみた。
今後の自分の戒めとして、忘れないように書き記しておく。
心構え
レビュアー、実装者の関係は対等である
コードレビュー以前の話かもしれないが、まず大前提としてレビュアー、実装者の関係は対等であることを忘れないようにしたい。
相手が誰であろうと、人としてのリスペクトを忘れないこと。横柄な物言いや相手を否定するようなことは絶対に言わない。
自分が常に正しいと考えない
人は間違う。自分が間違っている可能性があることを常に頭の片隅においておくようにする。
寛容的になる
コードレビューで意見が対立する場合は、結構好みの問題であることが多い。人には色々なコダワリがある。
例えば
- コードをなるべく短く、ワンライナー大好き
- コメント絶対書くマン
- 関数型言語、イミュータブル大好き
- Generic、テンプレート大好き
相手のコダワリは可能な限り受け入れ、また自分のコダワリは他人に押し付けないようにしたい。
実装者のサポートをする
実装者は与えられたタスクの要件に従って、実装者なりに試行錯誤をし、コードを作り上げてきた。レビュアーは実装者のコードに対して敬意を払い尊重する必要がある。
書籍の校正をするように、誤字・脱字の発見や改善点などを提案していく。
たとえ自分の実装方法とは異なったとしても、それを押し付けるようなことはせず、実装者のコードに寄り添い、もっと良いコードになるようサポートする。
指摘する際に必要な情報
指摘する際に必要な情報は以下の2つ。
- 理由
- 提案内容
それぞれについて以下に説明する。
理由
理由や根拠がないと、相手は「どうして？」となってしまう。例えば「ボタンの色を赤色ではなく青色にしたほうがよいと思います。」だけだと、なぜそうしたいのかが分からない。相手が何を考えているのかが分からないと理由を推測するしかない。推測出来ない場合は改めて相手に質問することになり時間の無駄になる。あるいはたぶんこうだろうということを推測出来ても、それが確定的ではない場合は相手に確認が必要となり同じく時間の無駄になる。
なので問題を指摘する際はTypoなど100%理由が分かる場合を除いて、なぜそうしたほうがいいと思うのか理由や根拠を必ず説明する。
提案内容
どうしたいのかということが相手に伝わらないと、相手は改めて質問することになる。これが時間の無駄になる。あるいは相手が誤解してしまい指摘した内容と異なる修正作業を始めてしまうかもしれない。例えば「このボタンは赤色だけど他のページと揃えたほうがよいと思います。」だけだと、どの色にしたらよいのかが明確でない。「結局何色にすればいいの？」、「他のページってどのページ？」、「他のページはすべて揃っているの？他のページ全部調べなきゃ・・」など相手に余計な時間を使わせてしまう。
なので問題を指摘する際はどうしたいのかということを相手が理解できるように具体的に明確に説明する。 必要であればコードを提示する。
事例
var options = string[] {
"きのこの山",
"たけのこの里",
};
要求ではなく提案する
NG例:
Reviewer: たけのこの里を先頭にしてください。
Reviewer: たけのこの里を先頭にしてもらっていいですか？
このような言い方は実装者に対して要求・指示しているように聞こえてしまう。
またいきなり要求・指示すると、「議論の余地はない」、「自分が絶対的に正しい」というメッセージにもなってしまう。
両者が対等な関係であることを考えると、このような横柄で一方的な言い方は慎みたい。
OK例:
Reviewer: たけのこの里のほうが販売数が多いため、たけのこの里を先頭にしたほうがよいと思いますが、いかがでしょうか？
このように「自分はこうしたほうがよいと思う」ということを提案するスタンスを取る。何かを要求するのではなく、ただ自分の意見を提案する。
議論が平行線になった場合は？
こちらが提案や問題提起しても、実装者が同意しなければ議論は平行線になってしまう。
そのようなときはチームで協議すればよいと思う。最終的には多数決とかサイコロでもよいので、全員が納得する形で決めればよい。