「動くコード」は最低ライン。「読めるコード」が求められる

「動くコード」は最低ライン。「読めるコード」が求められる

プログラミング学習中は「動けばOK」と考えがちですが、現場では違います。コードは書く時間の何倍もの時間、読まれるものです。

チーム開発では、あなたが書いたコードを他のメンバーが読み、修正し、機能を追加します。読みにくいコードは、チーム全体の生産性を下げ、バグの温床になります。

コードレビューで指摘されない5つの習慣

習慣1：変数名・関数名で意図を伝える

コードを読む人が、変数名を見ただけで「何のデータか」がわかるようにしましょう。

命名のルール

• 真偽値 — is、has、canで始める（isLoading、hasPermission）
• 配列 — 複数形にする（users、products）
• 関数 — 動詞で始める（getUser、calculateTotal、validateEmail）
• 定数 — 大文字スネークケース（MAX_RETRY_COUNT、API_BASE_URL）

習慣2：関数を小さく保つ

1つの関数は、1つのことだけを行うようにしましょう。

目安として：

• 1関数あたり20行以内を心がける
• 関数名で何をするかが完結に説明できる
• 引数は3つ以下にする

長い関数は、処理の単位で分割しましょう。「データの取得」「データの加工」「結果の表示」を1つの関数にまとめるのではなく、それぞれ独立した関数にします。

習慣3：ネストを浅く保つ

if文やループが深くネストすると、コードの可読性が大幅に下がります。

ネストを減らすテクニック

• 早期リターン — 条件を満たさない場合は早めに関数を抜ける
• ガード節 — 異常系のチェックを最初に行い、正常系の処理をフラットに書く
• 処理の分割 — 深いネストの内部処理を別関数に切り出す

目安として、ネストは3段階までにしましょう。それ以上深くなる場合は、構造を見直すサインです。

習慣4：コメントは「なぜ」を書く

コメントは「何をしているか」ではなく、「なぜそうしているか」を書きましょう。

• 悪いコメント：// ユーザーを取得する（コードを読めばわかる）
• 良いコメント：// 退会済みユーザーも含める（管理画面では表示が必要なため）

コメントが不要なケース

• 変数名や関数名で意図が伝わる場合
• コードがシンプルで自明な場合

コメントが必要なケース

• ビジネスロジック上の理由がある場合
• パフォーマンス上の理由で通常と異なる実装をしている場合
• 一時的な対応（ワークアラウンド）の場合（TODO/FIXMEコメント）

習慣5：一貫性を保つ

チーム開発では、個人の好みよりもチームの一貫性が重要です。

• コーディング規約に従う — ESLint、Prettierの設定に従い、自動フォーマットを活用する
• 既存コードのパターンに合わせる — プロジェクト内で統一されたスタイルを崩さない
• ファイル構成のルールに従う — コンポーネントの配置、命名規則を統一する

コードレビューで成長する

コードレビューは「ダメ出しの場」ではなく、「コードの品質を上げるためのチーム活動」です。

指摘を受けたとき

• 感情的にならず、指摘内容を理解する
• なぜそう修正すべきかの理由を理解する
• 同じ指摘を二度受けないよう、学びを蓄積する

自分でチェックするポイント

PRを出す前に、以下を自分でチェックしましょう。

• 変数名・関数名は意図が伝わるか
• 不要なコードやconsole.logが残っていないか
• ネストが深くなりすぎていないか
• 同じ処理が複数箇所にコピペされていないか
• エラーハンドリングが適切か

読みやすいコードは「思いやり」の表現

読みやすいコードを書くことは、未来の自分とチームメンバーへの思いやりです。3ヶ月後に自分のコードを読み返したとき、すぐに理解できるコードを書きましょう。

ゆめさくエンジニアでは、18ヶ月の実践カリキュラムの中で、現役エンジニアの講師によるコードレビューを繰り返し受けることができます。指摘を受けて修正する経験を積み重ねることで、自然と読みやすいコードが書けるようになります。

初めてのコードレビューチェックリスト

レビューで見るべき10項目を具体的に解説

エラーハンドリングの考え方

本番環境で動くコードの書き方を学ぶ

チーム開発の流れを完全解説

Git/PR/レビューの実務フローを理解する

ゆめさくエンジニアのカリキュラム

18ヶ月で実務力を身につける実践型カリキュラム