はじめに

フロントエンドの先輩にレビューをしてもらうことがありますが、
指摘が多かったり、「この前も指摘されたのに同じミスをしている」と感じることがあったので、チェックリスト化しました。

初心者向けであり、一部は社内ルールに沿った内容であることをご了承ください。

経歴

看護師3年 → HTMLコーダー3〜4年 → 現在フロントエンド1年半

フロントエンド歴の中にはWeb制作やマークアップ（HTML/CSS）が含まれるため、開発経験は浅いです。
経験年数：React.jsは1年未満、Vue.jsは1年弱。HTML/CSSは5年以上。

チェックリスト

共通項目

import

記述順は適切か（社内のルールに沿っているか）
社内ルール：react関連、ライブラリ、共通コンポーネント、固有のモジュールの順に記載
不要なものはないか
重複はないか
importがまとめられているか
例：import { Hoge1 } from '@/features/hoge/components';
import { Hoge2 } from '@/features/hoge/components';
ではなく、import { Hoge1, Hoge2 } from '@/features/hoge/components';になっているか
絶対パスでimportしているか。エイリアス表記で統一されているか
例：import { test } from '@/hoge/fuga';

命名

分かりにくい名前や汎用的な名前をつけていないか
例：createFunction（何を作成する関数か分からない）
命名規則があるか、統一された名前をつけているか
idやnameへの名称の付け方は「形容詞＋名詞」または「動詞＋名詞」となっているか
ページコンポーネント・部品コンポーネント名は、アッパーキャメルケースになっているか
例）ContractTabParts
画面用のtsxファイル名は、アッパーキャメルケースになっているか
例）CreatePage.tsx, NewsListPage.tsx
hooksなどのtsファイル名は、ローワーキャメルケースになっているか
例）hooks.ts, createStatus.ts
ディレクトリ名はスネークケースになっているか
例）create_user
コンポーネントフォルダ名はアッパーキャメルケースになっているか
例）UserSearch.tsx, NewsList.tsx
APIクラスをインスタンス化して変数に格納する際、固有のAPIクラス名になっているか
例）NG：api | OK: applicationApi

定数

実装時にsrc/core/config/constants.tsファイルの定数を確認する
定数を利用しているか
マジックナンバーが使われていないか
理由：数字だけだと意味が伝わらない。ステータスの仕様変更があったとき、修正が楽である

関数

日付変換などの関数はsrc/core/utils/convert.tsファイルに記載しているか
使用していない関数を削除しているか
既存の関数を利用できているか

ロジック

不要なロジックを削除しているか
判定ロジックはハードコードにせず、caseなどで分岐し各定数で管理できているか
理由：一部機能のステータスに変更があった際でも他の機能へ影響を与えず修正が可能になるため
複数のAPIリクエストを同時に実行する場合、Promise.all()を利用しているか（並列）
1メソッドには1つの役割となっているか

ReactHookForm

useFormのメソッドをネストされたコンポーネントで使用する場合、propsを渡さずFormProviderとuseFormContextを使用しているか
理由：propsのバケツリレーが不要で、レンダリング回数を削減できるため
watch, formStateの代わりにuseWatch,useFormStateを使用しているか
理由：レンダリング回数を削減できるため
例：const applicationValue = useWatch({ name: 'file', control });
　　const { errors, isValid } = useFormState({ control });

Loader

画面描画時のデータ取得には、React-RouterのLoaderを使用しているか
例：レンダリング前にデータ取得を行うため
すぐに表示する必要がないデータに関してはdeferを使用し、対象部分のみ後から表示させているか

メソッドや値

不要なメソッドや値を削除しているか

hooks

useEffectのクリーンアップで不要なリソースを解放しているか
hooks.tsが長く複雑になっていないか

型

型定義にanyを多用していないか

View

Viewにロジックが記載されていないか
※stateによる表示切り替えなど、簡易なものはOK
Viewの記述が長く複雑になっていないか
　例）目安は300行くらい

画面

1つのView（ページファイル）で複数画面分をまとめていないか
画面単位で分けて実装する
ルーティング単位のファイルでログを出力しているか
例）logger.info('<-- HogeCreatePage -->');

コンポーネント

既存の共通コンポーネントを修正する際、全体の影響を考慮できているか
共通コンポーネントを修正するのではなく、呼び出し元で文言を変えるなどしているか
複数の画面で使用するパーツをコンポーネント化しているか

コメントアウト

不要なコメントアウトを削除しているか
各関数にはJSDoc形式でコメントを記載されているか
処理に関するコメントが適切に書かれているか

仕様未確定の箇所

あとで対応が必要な箇所は、コメントアウトでTODOを記載しているか
API未実装の場合、レスポンスはモックを使用して実装しているか

エラー

console errorが出ていないか
APIエラーが出ていないか

マークアップ

タグは正しく使われているか
正しい構造になっているか
例：誤った入れ子構造になっていないか
divを多用していないか
古いタグや非推奨のタグが使われていないか
タグの閉じ忘れがないか

UI

操作時にローディング画面が表示されるか
ローディング中は他の操作ができないようになっているか
カーソルをあてたときにポインターになるか
チェックボックスやラジオボタンのラベル部分もポインターになるか
成功時 or エラー時にスナックバーが表示されるか
ページネーション（ページ送り、ページャー）で初めのページにいる時は「＜」がdisabledになっているか（最後のページの時も同様）
フォーム未入力時にバリデーションエラーの文章が表示されるか

デザイン

レスポンシブ崩れが起きていないか
要素のホバー時やクリック時のUIはデザイン通りか

文言

文言の表記揺れがないか
例：「お問い合わせ」「お問合せ」、「お客様」「お客さま」、「プリンター」「プリンタ」

【システム開発】コードレビュー PR提出前のチェックリスト（初心者向け・フロントエンド）

目次