コードレビューをするときに意識していること
こんにちは。企業でエンジニアをしているサーモンです。
今回はエンジニアの仕事のうち、コードレビューについて解説します。
コードレビューとは
チームでコーディングをしていると、コードレビューという作業が発生します。
レビューとは、あるメンバーのアウトプットがチームで受け入れられる品質になるように確認することです。
この過程を経ることで、アウトプットをチームで共有することができ、同時に品質に対する責任を持つことができます。
レビューの対象は多岐に渡りますが、特にコードをレビューすることをコードレビューと言います。
現代のアプリ開発では、リポジトリにプルリクエストを出すことでコードレビューが始まります。
なお、レビューを依頼する側をレビュイー、依頼された側をレビュワーと言います。
コードレビュー時の心構え
コードレビューに慣れていないレビュワーは、他人のコードに指摘をすることが怖いと思います。
自分の意見に自信がなかったり、小さな指摘しか思い浮かばない場合もあるかもしれません。
それでも大丈夫です。
コードレビューにおいてはレビュワーとレビュイーは対等な関係です。
そのため、レビュワーの意見が絶対ではなく、質問や提案という形でコメントしてもOKです。
そのコメントに対してレビュイーが回答する過程で、より大きな問題に気づいたり、さらに良い解決策を思いついたりすることもあります。
まずは気づいたことに伝えてみるくらいの気持ちでやってみましょう。
それでは、レビュワーが具体的に確認するとよい項目を紹介します。
まずは既存機能の確認
メンバーの変更によって既存の機能に不具合が生じていないかを確認します。
具体的には、テストが通るかを確認します。
自動テストの環境が構築されている場合はその結果を確認し、人の目でチェックするべき項目は別途実施しましょう。
この時点で不具合が見つかった場合は、その旨をレビュイーに伝えてしまってOKです。
テストがない場合は、テストの追加を依頼することも検討すると良いでしょう。
機械的に判断できるところから
初めは具体的で機械的にチェックできる観点でレビューするのがとっつきやすいです。
例えば、チームで採用しているコーディングルールに従っているかを確認するとよいでしょう。
特に採用しているものがなければ、利用している言語の代表的なコーディングルールを引用するのがおすすめです。
また、周辺のコードとの一貫性について言及するのも良いです。
例えば、変数の宣言や初期化のタイミングを揃えることで可読性が上がりますし、周辺のコードのリファクタリングにもつながるかもしれません。
変数名やコメントの「分かりやすさ」を議論する
一見何をしているか分からない名前の変数については、積極的にコメントするべきです。
レビュイーは何度もコードを読んでいるため変数の役割を理解しています。
しかし、まだコードを読み始めのレビュワーにとって分からない場合は、変数名が適当でない可能性があります。
ロジックも分からないところは質問をした上で、コードから読み取りづらいトリッキーな箇所はコメントを書いてもらうのがよいです。
こういった項目はレビュワーにとっての分かりやすさが重要であるため、自信を持ってコメントしましょう。
実行時のパターンが網羅できているか確認する
例えばユーザーが想定外の操作をした場合など、一般的でないケースでの動作に問題がないか確認しましょう。
異常系のテストで確認できる場合はよいですが、環境依存のためテストが難しいといった理由で、テストが追加されていない可能性もあります。
簡単な原則やテクニックを採用する
SOLIDやYAGNIといった、一般的に受け入れられている原則を学んでレビューに活かしてみましょう。
これまでの項目は現在のコードについて着目していましたが、こういった原則から考えることによって、将来の変更に備えることができます。
デザインパターンやアーキテクチャを取り入れていく
GoFのデザインパターンや、MVVMのようなアプリのデザインパターンを学ぶことで、よりよい実装について議論できるでしょう。
また、DDDのような設計手法を知っていると、適切なクラスに実装できているか、コンポーネントを分けた方がいいかといった観点でレビューすることができます。
まとめ
今回はコードレビューについてまとめました。
コーディング作業はコードを書くだけでなく、読む側の立場に立って参加することもあるというわけです。
テキストとは異なり、唯一正解のコードがあるとは限りません。
なので、メンバーの書いたコードに対する率直な意見をコメントし、ぜひ有意義な議論の場にして頂ければと思います。