Technology部の菊池です。
開発を進める際は、コードの品質を担保するためにコードレビューをおこなうことが重要です。ツールによる自動チェックも便利ですが、機械的にチェックできない項目は人的リソースを割いてレビューをおこなう必要があります。
そこで今回は、コードレビューでレビュアーが注意したいレビュー観点や項目をまとめました。テクニカルディレクターなど、レビュアーの方の参考になれば幸いです。
なお、本記事ではターゲットとするレイヤー（フロントエンド、バックエンド）、ならびにフレームワークについては依存しない内容としています。また、ESlintやCode formatterなどの静的解析ツールで抽出可能なコーディングルールについては対象外となりますのでご了承ください。
※静的解析で設定しておきたいルールについては、こちらの記事をご覧ください 静的解析で設定しておきたいルールを解説
Hiroyuki Kikuchi
コードレビューの目的
コードレビューの主な目的は以下の2点です。
- 作成した成果物の品質を担保する
- クリーンコード（可読性、メンテナンス性、拡張性が担保されたコード）を維持担保する
ひいてはバグの早期発見や、経験の浅いメンバーのスキル向上にもつながるなど、さまざまなメリットがあります。
レビュー観点チェックリスト
前提として、レビュアーがチェックするべき内容はツールなどで機械的にチェックできない部分です。その観点を鑑みて、レビュー時に注意すべき項目を紹介します。
基本的な観点
レビュアーがマストで実施すべきレビュー観点は、以下のとおりです。
- チェックリスト
-
- レビュアーは受け入れテストを実施しているか
- PR（Pull Request）作成者は修正した機能について、設計書も更新しているかどうか
- PR作成者は修正した機能に対して、ユニットテストの構築ならびに修正まで実施しているか
- 作成、更新したプログラムがアーキテクチャならびにデザインパターンに準拠しているか
命名規則
静的解析では名前の妥当性まではチェックできません。そのため、レビュアーはファイル名や変数などの命名規則が適切な内容となっているか確認しましょう。
- チェックリスト
-
- ファイル名、変数、関数、クラスなどの名前は、その要素が表現する目的や機能を明確にかつ正確に説明しているか
- ファイル名、変数、関数、クラスなどの名前は、略語や省略形が含まれていないか
単一責任の原則
静的解析では作成したコードが単一的になっているか、凝集度*が高いかどうかまでみることはできません。レビュアーは作成されたコンポーネント、クラス、関数の知識や責務観点についてチェックすべきです。
*凝集度：クラスやモジュール、メソッド内におけるロジックとデータの結び付きの強さを示す指標。ロジックとデータの結びつきや関連性が強いほど高凝集と言われており、ソフトウェア開発において推奨されている。
- チェックリスト
-
- クラスや関数、コンポーネントにおいて知識や責任が単一となっている
- クラスや関数、コンポーネントの名前が責務に適合している
ログ観点
ログは開発や運用において、プログラムの実行結果を確認することを目的としています。ログを正しく組み込めるかどうかで、開発時のバグの早期発見や、実運用におけるトレーサビリティの向上につながります。
とくにDevOps*の観点において、例外処理をハンドリングした場合は、問題確認のトリガーとすることもできます。
*DevOps：Development （システムの開発）とOperations（システムの運用）を組み合わせた造語。柔軟かつスピーディーにシステム開発をおこない、顧客に価値を素早く届けるため開発担当、運用担当が協力し合う概念を指す。
- チェックリスト
-
- ログに個人情報や機密情報が含まれていない
- 例外処理が発生した場合、発生原因についても出力される
- 可能であればバックトレースエラーも出力する
- エラー発生時は発生時のコンディションについても記載する
- 開発者だけが見るべき内容のログレベルは、最低レベルに落とす
- 操作ログに関するログのレベルは、運用時においても見れるようにする
ユニットテスト観点
ユニットテストを実施することで、バグを早期発見できます。レビュアーは適切なテストコードを書けているかどうかチェックしましょう。
- チェックリスト
-
- 網羅率は100％となっているか
- 正常系、準正常系、異常系のテストケースが盛り込まれている
- 実施するテスト内容が、テスト関数名などでわかりやすく記載されているか
- 引数の入力値について境界値観点のテストを実施している
まとめ
レビュアーがコードレビューの観点について解説しました。
まとめると、機械的に実施できるコードチェックは、静的解析ツールを用いてCI／CD内で、各エンジニアが実施し、レビュアーは機械的に見ることができない観点でコードのレビューを実施すればよいでしょう。
なお、今回定義したレビューチェック項目をすべて満たせれば完璧というわけではありません。プロジェクトごとのルールにあわせて適宜修正することが望ましいです。
さいごに、LIGブログではAIやアプリ・システム開発など、テクノロジーに関するお役立ち記事をお届けするメルマガを配信しています。
- ＜お届けするテーマ＞
-
- 開発プロジェクトを円滑に進めるためのTIPS
- エンジニアの生産性が上がった取り組み事例
- 現場メンバーが生成AIを使ってみた
- 開発ツールの使い方や開発事例の解説
- AIをテーマにしたセミナーの案内
- 最新のAI関連ニュースまとめ など
「開発ツールの解説や現場の取り組みを知りたい！」「AIに関する最新情報を集めたい！」とお考えの方は、ぜひお気軽に無料のメルマガをご購読くださいませ。
