読者です 読者をやめる 読者になる 読者になる

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

背景

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

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

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

 

 原因分析

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

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

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

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

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

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

 

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

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

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

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

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

 

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

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

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

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

 

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

  1. なにか嫌なことがあり、感情的になっていた。
  2. 開発者としての自尊心を傷つけられたと思った。
  3. 年下から指摘されて、イラっときた。など

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

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

 

今後の対策

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

まとめ

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

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

 

参考ページ

qiita.com

postd.cc