ソースコードレビューをする際に気を付けること

会社でレビューアとしてコードレビュー(配布形式)をしたんですが、

私が挙げた指摘にいろいろ理由をつけられて、

結局、1つもレビューイがコードを修正してくれなかったので、原因を考えてみる。

①　レビューの観点がずれていた？

私の挙げた指摘はコードの可読性に関するものが多かった。

(変数名や定数名をもっと分かりやすくできないか。など)

しかし、レビューアは仕様書どおりに実装されているかどうかを
確認してほしかったのかもしれない？

⇒仕様書通りに実装されているかどうかは、テストでチェックするべきではないのか？

何はともあれ、レビューイに事前確認しておくべきだったかもしれない。

②　指摘の理由づけが十分でなかった？

～が分かりづらいなどの指摘を挙げたが、

理由については詳しくレビュー議事録に記載していなかった。

だから、指摘に納得できずに修正が見送られたのかもしれない。

⇒これは自分で納得できた。次から気を付ける。

③　指摘内容と修正コストが釣り合わなかった？

コメント文や変数名などを修正する必要性は、

実装ミスなどに比べると低いため、そこだけ直してコミットするのは不要と判断したのかもしれない。

⇒コードの読みやすさも大切だと思うのだけれど...納得できない。

④　だだ単に機嫌が良くなかった？

⇒ただの事故だった可能性。

こればっかりは運がなかったと思うしかない。

レビューする前にどこを重点的に見てほしいのか、
どういった観点で見てほしいのかレビューイに聞く
(仕様書通りかどうか/可読性は低くないか/コードのパフォーマンスは低くないかなど)
挙げた指摘には必ず理由を記載する
(~は誤読可能性があります。~は仕様書と乖離があるように読み取れます。など)
レビュー報告は朝一で挙げる
(前日にレビューしておき、疲労が少ないであろう午前中に報告し、事故を減らす)

コードレビューは本当に難しい。

遠慮なく、思いやりをもって行う必要がある。

参考ページ

qiita.com

めんどくさがりダイアリー