フロントエンドのコードレビューで意識したい3つの観点

こんにちは。デザインチームのサカシタです。

私がフロントエンドのコードレビューで毎回確認しているポイントについて紹介します。

コードレビューというと、「バグを見つける作業」というイメージを持つ方も多いかもしれません。
最近では、AIを利用してコードを作成する機会も増えています。AIによって一定の品質のコードを短時間で生成できるようになった一方で、生成されたコードが必ずしもプロジェクトの設計や既存コードの構成に適しているとは限りません。
特に、設計や責務分離が十分に考慮されていない場合、処理が複雑になり、後からコードを読む人にとって難解なコードになってしまうことがあります。

そのため、コードレビューでは単にバグを探すだけではなく、コードの読みやすさや一貫性、将来のメンテナンス性など、さまざまな観点から確認することが重要だと考えています。

この記事では、私が日頃のコードレビューで意識しているポイントを、実例を交えながら紹介します。
これからコードレビューに携わる方や、レビューの観点を増やしたい方の参考になれば幸いです。

コードレビューで確認していること

動作確認やHTMLの基本的なマークアップについては、前提として確認したうえで、私は主に次のような観点でコードレビューを行っています。

１．コードが読みやすいか（可読性）
２．異常系の処理が適切か（品質・堅牢性）
３．コンポーネント・関数の責務（設計）

これらが、日頃のコードレビューで主に確認しているポイントです。

このほかにも、パフォーマンスやブラウザ互換性、セキュリティなどを確認することもありますが、
本記事では特に日頃から意識している3つの観点に絞って紹介します。

コードが読みやすいか（可読性）

まず「コードが読みやすいか」を確認しています。

コードは一度書いて終わりではなく、自分やチームメンバーが後から読み返したり、機能追加や改修を行ったりすることがほとんどです。
そのため、誰が見ても意図が理解しやすいコードになっているかは非常に重要だと考えています。

特に確認しているポイントは次のとおりです。

・1つの関数が多くの役割を持っていないか
・コメントによる補足がないと意図が伝わらないコードになっていないか

例えば、変数名が data や tmp のように抽象的だと、コードを読む人はその変数が何を表しているのかを都度確認する必要があります。
一方で、役割が分かる名前になっていれば、コード全体の流れを把握しやすくなります。
また、jQueryやライブラリを利用したコードでは、fやoなど、処理内容から役割を判断しづらい短い変数名を見かけることがあります。
これらは、その変数が何を表しているのかが分かりづらく、コードをさかのぼって確認する必要があります。
また、変数名だけでは配列なのかオブジェクトなのか判断しづらい場合もあり、コードを理解するまでに余計な時間がかかってしまいます。

また、ネストが深いコードは処理の流れを追いづらくなるため、早期リターンを利用するなどして、できるだけシンプルな構造にできないかを確認するようにしています。

可読性は目に見える機能ではありませんが、日々の開発効率やレビューのしやすさに大きく影響します。

分かりにくい例

const d = res.data;
const x = d.list.filter(v => v.flg);

分かりやすい例

const products = response.products;
const availableProducts = products.filter(product => product.isAvailable);

チームで開発を行う場合、コードを読む人が変数名からある程度処理内容を理解できることが重要です。
変数名だけで処理内容がある程度推測できることで、コードを読む際の負担を減らすことができます。

異常系の処理が適切か（品質・堅牢性）

次に確認しているのが、異常が発生した場合でも適切に処理できるようになっているかという点です。

実装時には、正常に動作するケースだけでなく、想定外のデータやエラーが発生した場合についても考慮する必要があります。

特に確認しているポイントは次のとおりです。

・API通信が失敗した場合の処理が考慮されているか
・想定外の値（nullやundefinedなど）でエラーにならないか
・ユーザー操作による予期しない状態変化が発生しないか
・エラー発生時にユーザーへ適切なフィードバックがあるか

例えば、APIから取得したデータをそのまま画面表示に利用している場合、常に期待したデータが返却されるとは限りません。

通信エラーやデータ不足が発生した場合に、画面が崩れたりJavaScriptエラーが発生したりしないよう、事前に対策されているかを確認しています。

また、ボタンの連続クリックや処理中の再操作など、ユーザー操作によって想定外の状態にならないかも重要な確認ポイントです。

正常なケースだけを見るのではなく、「もし失敗した場合はどうなるか」という視点を持つことで、より安定したサービスにつながります。

異常系への対応は、普段は意識されにくい部分ですが、問題発生時のユーザー体験や復旧のしやすさに大きく影響します。そのため、正常系だけではなく、異常系の処理についても確認するようにしています。

コンポーネント・関数の責務（設計）

次に確認しているのが、コンポーネントや関数が適切な責務を持っているかという点です。

フロントエンド開発では、画面の表示だけでなく、API通信、状態管理、入力制御、データ加工など、さまざまな処理を実装します。

その際に、1つのコンポーネントや関数に多くの役割を持たせてしまうと、コードの理解や修正が難しくなります。

特に以下のような点を確認しています。

・1つのコンポーネントが複数の役割を持っていないか
・表示処理とデータ取得処理が適切に分離されているか
・関数名と実際の処理内容が一致しているか
・共通化すべき処理と、個別に持つべき処理が適切に判断されているか

例えば、Vueのコンポーネント内で、

・APIからデータを取得する処理
・データの加工処理
・画面表示
・イベント処理

がすべて1つのファイルに集中している場合、機能追加や修正時に影響範囲を把握しづらくなります。

そのため、処理の役割に応じてコンポーネントや関数を分割し、それぞれが明確な役割を持つようにすることを意識しています。

ただし、すべてを細かく分割すれば良いというわけではありません。

過度な共通化や細かすぎるコンポーネント分割は、逆にコードの追跡を難しくする場合があります。
そのため、再利用性だけではなく、処理の理解しやすさとのバランスを考えることが重要です。

重要なのは、「この処理はどこにあるべきか」「変更が発生した場合に影響範囲を把握しやすいか」という視点で設計することです。

コンポーネントや関数の責務を適切に分けることで、コードの理解や修正がしやすくなり、チームでの開発効率向上にもつながります。

例えば、画面側のコンポーネントでは表示に必要な処理に集中させ、データ取得や状態管理などは別の役割として切り出すことで、それぞれの責務を明確にできます。

まとめ

今回紹介した、

・コードが読みやすいか（可読性）
・異常系の処理が適切か（品質・堅牢性）
・コンポーネント・関数の責務（設計）

といったポイントは、私が日々のコードレビューで特に意識している内容です。
チームや企業によってレビュー方針やルールは異なりますが、コード品質を高めるという目的や、そのために確認すべき基本的な観点は共通していると考えています。

コードレビューは、問題を指摘するためだけではなく、チーム全体で品質を高め、将来的な変更にも対応しやすいコードを作るための大切な工程だと考えています。

この記事が、これからコードレビューに携わる方や、レビュー時の確認ポイントを増やしたい方の参考になれば幸いです。

ラクーンホールディングスではエンジニア・デザイナーを大募集中です！
少しでも興味がありましたらぜひご応募ください！