チームでソフトウェア開発をする際、ソースコードレビューをすることが多いですね。
新人のうちはレビュイー(レビューしてもらう側)がほとんどで、自分がレビューすることはなかなかありませんが、経験を積むにつれてレビュワー（レビューをする側）になる機会が増えてきます。
僕も最近になってレビュワーになることが増えました。
レビュワーになっているということはある程度ソースコードは読める状態ではありますが、いざ他者が作ったコードをチェックするとなると、不安になりますよね。
というわけで今回は、レビュワー初心者向けに実際に僕が感じた、コードレビューをする際に必要な観点についてお話ししていきます！
コードレビューの目的は何か？
まずは、「そもそもコードレビューは何のために行うのか」という話からしていきましょう。
目的は大きく分けて以下が考えられます。
- 品質の担保
- 品質の向上
- メンバーの技術力向上
- 変更箇所の認識合わせ
①品質の担保
仮にコードをレビュワーのチェック無しに自由に変更可能だとしたらどうなるでしょうか？
新機能の作成であれば、求められている仕様とは異なるものが出来上がるかもしれません。
バグ修正であれば、新たなバグの原因になるといったデグレ(品質低下)につながる可能性もありますね。
そして、自由に変更できてしまうと、いざ元の状態に戻すとなった時が大変です。
多くの会社ではGitHubを用いて開発していると思いますが、コミットをどこまで戻せば良いのか、コミットログを順に見ていかないといけないですね。
しかも、途中に消してはいけないコミットがあった場合などを考えると、復旧作業が複雑化してしまいます。
このように、コードの変更には品質低下のリスクがあるわけです。
そのため、レビュワーがチェックしてOKを出さない限りはコードを変更できないという仕組みが重要になります。
そして、(レビュワーからOKが出る)＝(品質が担保される)ということにつながるわけです。
②品質の向上
次は品質の向上についてですね。
分かりやすい例が、新人の作成したコードのレビューです。
新人の作ったコードを見ると、たとえば以下のような特徴が見られることが多いですね。
- コードが冗長で読みにくい
- ファイル名やメソッド名、変数名などが分かりにくい
- 誤字脱字がある
- 仕様通りに動作しない
- バグが発生する
これらはレビューの観点の話にもつながりますが、品質上、修正が必要になりますね。
このように、ソースコードをさらに良い物にするためのチェックというのもレビューの目的になるわけです。
③メンバーの技術力向上
先ほどの品質向上の話ともつながりますが、レビューで指摘されることで次からは同じミスをしないように気を付けるようになりますね。
これによってレビューの指摘箇所が減っていくということは、技術力が上がっていくということになります。
新人のレビューであれば、レビューを通して実装方法を教えることになりますね。
また、ある程度開発ができるようになった人同士で相互レビューをする場面もあります。
すると、「なるほど、こういう書き方もあったか！」と気付くことがよくありますね。
レビュワーもレビュイーも技術力アップにつながるのが、コードレビューのメリットでもあり目的でもあると言えるでしょう。
④変更箇所の認識合わせ
複数人で開発をする場合、誰がどこに変更を加えているかを把握しておく必要がありますね。
自由にコードを変更できた場合、どこに変更があったかをチーム内で共有するのが困難ですが、レビュー時に他の人がどこに変更を加えたかを知っておけば、バグの発生時なども調査をしやすいですね。
また、影響範囲を確認することにもつながります。
たとえば、システム全体の共通処理の部分に変更を加えると影響範囲が大きくなりますね。
影響範囲が広くなると、それによって新たな不具合が発生しないかといった検討も必要になるでしょう。
コードを変更する際は、認識合わせが大切になるわけですね。
コードレビューに必要な観点とは？
では、ここからはコードレビューに必要な観点について見ていきましょう。
先ほどの目的の話ともつながりますが、基本的にレビューで意識すべきなのは品質の担保・向上ですね。
まずは、以下の観点でレビューをしてみましょう。
- 変更内容と変更目的に差異は無いか
- コードの可読性をさらに高められないか
- 変更内容によって、新たなバグが発生するおそれは無いか
①変更内容と変更目的に差異は無いか
ソースコードに変更を加えるということは、「新しい機能を追加する」だとか、「バグを修正する」といった目的があるわけですよね。
というわけで、まずは変更内容と変更目的に差異が無いかをチェックしてみましょう。
以下を意識してみると良いですね。
- 必要な箇所だけに修正が入っているか(不要な変更が混ざっていないか)
- 目的を果たすような変更内容になっているか
たとえば、「○○の表示の不具合を修正します」と言ってレビュー依頼を出してきたのに、
- ○○だけではなく☆☆の表示も変更されている
- ○○の表示の不具合がそもそも直っていない
といったことが、特に新人のコードのレビューだとよくあります。
②コードの可読性をさらに高められないか
コードの可読性はソフトウェアの利用者には関係ありませんが、開発者には大きく影響があります。
機能の追加やバグの修正などでコードに変更を加える際に、元々のコードが読みにくかったらメンテナンスが大変です。
また、後任の開発者がコードを見た時に分かりにくいのも困りますね。
というわけで、以下を意識してレビューしてみましょう。
- 誤字脱字は無いか
- メソッド名や変数名などが、用途が分かりやすいようになっているか
- 命名規則が正しいか
- 複雑な処理の場合はコメント文による補足説明が入っているか
- if文の条件は複雑になっていないか(ネストが深い、アンドを使い過ぎているなど)
- 既存に類似の実装があるなら、それと統一性があるか
色々書いていますが、簡単に言えば、コーディング規約に則った実装になっているかの確認ですね。
③変更内容によって、新たなバグが発生するおそれは無いか
「バグを直したつもりが、新たなバグを引き起こす原因になっていた」といったことはシステム開発だと少なからずありますね。
影響範囲の広い箇所の変更ほど、バグのリスクが大きいので慎重になる必要があります。
というわけで、以下を意識してみましょう
- 影響範囲の広さはどれくらいか
- 新たなバグは発生しないか
もちろん、開発工程の後にテストがあるわけですから、テストの方でバグを確実に潰すというのも大切です。
しかし、レビューの時点で拾えるバグであれば、回収してしまった方がその後のスケジュールにも余裕ができます。
まとめ
さて、今回は初心者向けにレビューで必要な観点についてお話ししてきました。
最初のうちは指摘漏れがあったり指摘誤りをしてしまうこともありますが、レビュー観点を意識しながら丁寧に見ていけば、レビューの質を高めることができます。
優れたシステムエンジニアになるために、レビュワーとしてのスキルもどんどん高めていきましょう！
