ソースコードレビューをする際に気を付けること
背景
会社でレビューアとしてコードレビュー(配布形式)をしたんですが、
私が挙げた指摘にいろいろ理由をつけられて、
結局、1つもレビューイがコードを修正してくれなかったので、原因を考えてみる。
原因分析
① レビューの観点がずれていた?
私の挙げた指摘はコードの可読性に関するものが多かった。
(変数名や定数名をもっと分かりやすくできないか。など)
しかし、レビューアは仕様書どおりに実装されているかどうかを
確認してほしかったのかもしれない?
⇒仕様書通りに実装されているかどうかは、テストでチェックするべきではないのか?
何はともあれ、レビューイに事前確認しておくべきだったかもしれない。
② 指摘の理由づけが十分でなかった?
~が分かりづらいなどの指摘を挙げたが、
理由については詳しくレビュー議事録に記載していなかった。
だから、指摘に納得できずに修正が見送られたのかもしれない。
⇒これは自分で納得できた。次から気を付ける。
③ 指摘内容と修正コストが釣り合わなかった?
コメント文や変数名などを修正する必要性は、
実装ミスなどに比べると低いため、そこだけ直してコミットするのは不要と判断したのかもしれない。
⇒コードの読みやすさも大切だと思うのだけれど...納得できない。
④ だだ単に機嫌が良くなかった?
- なにか嫌なことがあり、感情的になっていた。
- 開発者としての自尊心を傷つけられたと思った。
- 年下から指摘されて、イラっときた。など
⇒ただの事故だった可能性。
こればっかりは運がなかったと思うしかない。
今後の対策
- レビューする前にどこを重点的に見てほしいのか、
どういった観点で見てほしいのかレビューイに聞く
(仕様書通りかどうか/可読性は低くないか/コードのパフォーマンスは低くないかなど) - 挙げた指摘には必ず理由を記載する
(~は誤読可能性があります。~は仕様書と乖離があるように読み取れます。など) - レビュー報告は朝一で挙げる
(前日にレビューしておき、疲労が少ないであろう午前中に報告し、事故を減らす)
まとめ
コードレビューは本当に難しい。
遠慮なく、思いやりをもって行う必要がある。
参考ページ