title: レビュー文化・設計 icon: 🏗️ card_desc: コードレビューの作法と変更しやすいコードの設計 — 結合度・凝集度・DRY/YAGNI/KISS・心理的安全性で、チームで保守できるコードを目指す slug: 13-review-design

13 レビュー文化・設計 — 人間の目と、変更しやすいコード

一言でいうと

「動く」コードを超えて「他の人が保守できる」コードを目指すのが本章のテーマです。コードレビューはミス探しでなく知見を共有し合う場であり、設計の黄金則は「ゆるい結合・強い凝集」。レビューの作法（見る側・見られる側）と、良い設計の指標（結合度・凝集度）・原則（DRY・YAGNI・KISS）を扱います。

1. なぜレビューと設計の作法が必要なのか

自動検査でも防げない問題

第12章のテスト・Lint・型チェックは強力ですが、扱えるのは「機械が判定できる問題」だけです:

• 「もっとシンプルに書けるか」は機械には分からない
• 「この設計で将来拡張できるか」は人間の判断
• 「要件を本当に満たしているか」は仕様の理解が必要

これらをカバーするのが**人間の目（コードレビュー）**と、そもそも変更しやすい設計の2つです。

個人開発とチーム開発

個人開発では「自分さえ分かればいい」で済みがち。しかし:

• 3ヶ月後の自分は別人（なぜこう書いたか忘れる）
• チームでは他の人が読み・変更する前提
• 面接でも「どう設計したか・どうレビューするか」が問われます

「動く」でなく「他の人が保守できる」を目指すのが、本章の作法です。

2. コードレビューとは

言葉の意味

• コードレビュー（code review／コードレビュー）— 他の人が書いたコードを確認し、改善点を伝え合う作業。Pull Request（→ 第2章）で実施するのが現代の定番です。

何を見るか

レビューで見る主な観点:

• 機能: 要件を満たしているか・エッジケース（境界の条件）は大丈夫か
• 可読性: 他の人が読んで分かるか・名前は適切か
• 設計: 責務が混ざっていないか・拡張しやすいか
• テスト: 十分なテストがあるか（→ 第12章）
• セキュリティ: 脆弱性がないか（→ 第5章）

ミス探しでなく「知見共有の場」

レビューは単なるバグ探しでなく、チームでコードの質を底上げし合う場です。「なぜこう書いたか」を言葉にする過程で、書いた側もレビューする側も学び、チームの設計方針が揃っていきます。

3. 🔑 レビューの作法（見る側・見られる側）

見る側の作法

• コードを批判し、人を批判しない: 「この書き方はダメ」でなく「ここは〇〇だと分かりやすい」等、コードに対して具体的に
• 理由を添える: 「直して」でなく「なぜ直すべきか」を添える。根拠がある指摘だけが採用されます
• 提案レベルを分ける: 「必須（バグ・セキュリティ）」と「提案（好み・改善）」を区別する

見られる側の作法

• 小さく出す: 1つのPRで大量変更するとレビュー負荷が高く、見落としも増えます。1機能＝1PRが理想です
• セルフレビュー: 出す前に自分で一度読み返す（→ 第11章 ラバーダック同様、自分の見落としに気づく）
• 指摘は攻撃でない: レビュー指摘はコードを良くするための協働。人格批判でないと受け止める

🔑 心理的安全性

これらの作法の根底にあるのが心理的安全性（psychological safety／サイコロジカル・セーフティ）——「間違えても・指摘しても恥を受けない」状態です。「初心な質問ができない」「指摘すると怒られる」状態ではレビューは形骸化し、問題が表面化しません。良いコードより前に安全に意見を言える空気が、レビュー文化の前提です。

4. 設計とは —— 変更しやすいコード

「動く」と「変更しやすい」は違う

コードは「動けばよい」でなく「後から変更しやすいか」が問われます。要件は変わり、バグは出、機能は増える。そのたびに触りにくいコードは、変更のたびに別の場所を壊し（→ 第12章 回帰）、開発を重くします。

結合度と凝集度

変更しやすさを語る2つの指標:

• 結合度（coupling／カプリング）— モジュール（部品）同士の依存の強さ。低い（ゆるい）ほど良い。片方を変えるともう片方も壊れる ＝ 結合が強い
• 凝集度（cohesion／コヒージョン）— 1つのモジュール（部品）内の機能のまとまり。高い（強い）ほど良い。1つのモジュールが1つの責務に集中 ＝ 凝集が強い

「ゆるい結合・強い凝集」（loose coupling / high cohesion）が、変更しやすい設計の黄金則です。

単一責任・関心の分離

• 単一責任（single responsibility／単一責任原則／SRP／エスアールピー）— 1つのモジュール・関数は1つの責務だけ持つ（→ 第12章「1関数1責務」）。複数の役目を持つと、どれか1つ変えたい時にも全部に影響します
• 関心の分離（separation of concerns／SoC／エスオーシー）— 異なる関心事（UI・DB・業務ロジック等）を分離して別の部品に。混ざると1箇所の変更が全体に波及します

5. 🔑 良い設計の指標と原則

3つの原則

• DRY（ドライ／Don't Repeat Yourself／繰り返すな）— 同じコード・知識を重複させない。直す時に複数箇所触る重複は、修正漏れの温床です
• YAGNI（ヤグニ／You Aren't Gonna Need It／それはまだ要らない）— 今不要な機能・抽象を作らない。「将来使うかも」で作った複雑さは、大抵使われず負債になります
• KISS（キス／Keep It Simple, Stupid／シンプルに）— 必要以上に複雑にしない。賢い書き方より分かる書き方

早すぎる抽象化の罠

「将来の拡張性」を考えすぎて早すぎる抽象化（premature abstraction／過早抽象化）に走ると、逆に変更しにくくなります。抽象は同じパターンが3回現れてから引く、が現場の目安です（→ YAGNI）。先回りした抽象は、現実の要求とズレて邪魔になります。

設計も「なぜ」を残す

良い設計には意図（なぜこうしたか）が残る必要があります。コメントや文書で「ここは〇〇の理由で分離した」等を残すことで、将来の変更者が意図を壊さずに拡張できます（→ 第11章「引き継ぎの前提」）。

6. なぜ「レビュー文化・設計」が開発の作法なのか

作法として位置づけられる理由

• 保守性が価値: ソフトウェアの寿命は書いた後に決まります。変更しやすい設計とレビュー文化があるコードは、長く価値を生みます
• チーム開発の前提: レビューなし・設計無視のコードは、チームの生産性を下げます。「動く」を超えて「保守できる」が現場の基準です
• 自分を守る: レビューは知識を共有しミスを分散する仕組み。1人で全責任を背負わない保険でもあります

面接・実務での意味

• 「どうやってコードの質を保っていますか？」への深い答えは、第12章の検査**＋本章のレビュー・設計**のセットで語れます
• 「結合度と凝集度を説明してください」は設計の定番質問。「ゆるい結合・強い凝集」と即答できるかが指標です
• 「レビューで意見が割れたらどうしますか？」は、心理的安全性とコミュニケーション作法を問う質問。人格でなく根拠で議論できる姿勢が評価されます

7. よくある落とし穴と対処

まとめ

• 自動検査（第12章）でも防げない「設計・可読性・要件」は人間の目＝コードレビューと変更しやすい設計が担う
• コードレビューはミス探しでなく知見共有の場。「コードを批判し人を批判しない」・心理的安全性が前提
• 変更しやすさの黄金則: ゆるい結合・強い凝集（loose coupling / high cohesion）
• 設計原則: 単一責任・関心の分離・DRY（重複なし）・YAGNI（不要なもの作らない）・KISS（シンプルに）
• 早すぎる抽象化は逆効果。同じパターンが3回現れてから抽象化
• レビューも設計も、根底は「他の人が（未来の自分も）安心して触れるコード」を目指す作法