「ダメ出し」じゃない！成長を促す効果的なコードレビューのやり方

はじめに

本記事はIT会社勤務の100名程の研修生を見てきた元Java研修講師が、コードレビューをする際に気をつけていたことをお話しします！実務でのコードレビューとは異なる点もあるかもしれませんが、何かの参考になればと思います。

大前提：

現場のルールでコード規約が定められていたらそれに従うべき。違うコードの書き方のほうが効率的であったとしても、無断でその書き方に修正して良い訳ではない。

読みやすさ(可読性)：

• 名前の付け方

変数名や、メソッド名、クラス名などの付け方自分が見て分かりやすいだけでなく、他の人が客観的に見て分かりやすく読みやすい名前にしましょう。

レビューの際には、「その変数名だめ！」というのでネガティブな指摘はしないようにする。何が今回良くなかったかを説明する。「aみたいな変数名は良くない⇨どんな情報が入ってるか分かりやすい変数名にしよう(例：数字ならnumber)」「Listの変数名は”〜List”にしよう(この変数はリストなんだと分かりやすくするため)」などの命名規則について指摘をする。

• コメント

メソッドやクラスにjavadocのコメントが付いているか、処理内容と違いが無いようなコメントを書けているか。を指摘します。ここでもあらかじめ書いてきたコメントに対して否定的な意見は言わずに、このコメントをこういう風に書いたらもっと分かりやすいのではないかと提案します(例：)。それをどう受け止めて次に活かすかは本人次第ですが、まずこちらとしては否定せずに提案することを意識していました。

• 無駄な処理

使っていない変数や未使用のimport文、コメントアウト化してしまっている処理などは原則消してもらうようにする。未使用な処理については、個人で確認できる範囲内なので次からは確認するように。と指摘することで再発を防ぐのと同時にレビュワーの作業時間も削減できる。

• 不要な改行・インデント

改行が多過ぎたり、不要なところで改行していたり、インデント(行の始めを下げること)が不適切だったりすると、可読性の低下になります。個人で確認をして改善できるところは、早い段階で修正するようにしましょう。

無駄なロジックがないか：

ここの指摘をするのがレビューをする中で大変難しいところです。

処理はきちんと動いているが、書いてるコードが長すぎる場合や無くても良い処理がある場合も少なくありません。ここをこう書けばもっとシンプルに書けるのにな。これは無駄なロジックだな。とかコードを読み慣れてきた人は気付くことが多くなると思います。しかし、レビューする人が考えているコードが絶対に正しいとは限りません。なので、相手のコードを完全に否定するのではなく、きちんとコードが書けていると説明をする前提で、こんなコードの書き方もあるんだよ。と紹介してあげるような流れが良いかと思いますし、自分も意識していたことでした。

まとめ

単にコードレビューをして指摘するのは簡単でしょう。しかし、その先の成長を促すならレビューの仕方を考えないといけません。今回紹介したのは、あくまでも例の１つですので、もっと良いレビュー方法があると思います。しかし、数回レビューしただけでは最適解を生み出せません。レビューもコーディングと同じように繰り返し行っていって色々な選択肢を増やして、最適解を見つけていくことが良いレビューへの近道になると思います。