変更に強い設計をクイズで身につける！
「7つの設計原理」要約＆クイズ

要旨

理由

結論

その他（範囲・効果）

• 原理一覧
  • 単純原理（Simplicity Principle）
  • 同型原理（Isomorphism Principle）
  • 対称原理（Symmetry Principle）
  • 階層原理（Hierarchy Principle）
  • 線形原理（Linearity Principle）
  • 明証原理（Clarity Principle）
  • 安全原理（Safety Principle）
• 期待できる効果例レビューの質と再現性が上がる／暗黙知だった「感覚」が言葉になる／欠陥の早期発見や、そもそもの作り込み防止につながる。

要旨

理由

結論

その他（実践）

• 意味のない抽象化や分岐を削る／1つの文には1つの意味だけ（1ステップ1責務）。
• 名前を見ただけで役割が分かるような意図の伝わる命名を心がける。
• 「まず動くいちばん小さな形」を基準にし、複雑な仕掛けは本当に必要だと分かったときだけ後から足す（計測結果や要件の裏付けがあるとき）。

要旨

理由

結論

その他（実践）

• コーディング規約・プロジェクト用テンプレート・共通ユーティリティなどを整備し、みんなで使う。
• 似たような処理は、引数の並び・戻り値・例外の扱いを揃える（兄弟関数なら見た目も兄弟っぽく）。

要旨

理由

結論

その他（実践・例）

• 命名の分かりやすい対：get/set, start/stop, from/to, begin/end, open/close など。
• 制御の対：if に対する else、try に対する finally、生成に対する破棄（open に対する close など）。
• 「例外ケースだらけで対称が崩れまくる」場合は、要件の切り分けやモデリングをやり直すべきサインとして受け止める。

要旨

理由

結論

その他（実践）

• コードをざっくりマップにすると：
  • セクション：モジュールやコンポーネントの集合。
  • 章：個々の関数やメソッド。
  • 段落：関数内のブロック（ifブロックなど）。
  • 文：1つ1つのステートメント。
• 上位の層から下位の層を呼び出すのはOKだが、横方向への依存や、下位から上位への逆流依存はできるだけ避ける（依存の向きは一方向）。

要旨

理由

結論

その他（実践・効果）

• ガード節（早期return）を使って、「異常系は先に帰す」ことでネストを浅く保つ。
• 複雑な条件式は、そのまま書かずに意味のある名前を持った関数に切り出すか、表（テーブル）で管理するデータ駆動にする。
• 状態遷移が必要なときは、暗黙のフラグをバラバラに増やすのではなく、状態マシン（ステートと遷移表）として明示的に設計する。
• 処理を小さなステップの直列パイプラインに分解し、「1ステップ1責務」で組み合わせると、全体の流れも追いやすくなる。

要旨

理由

結論

その他（実践・範囲）

• 単機能な関数、1ステップ1責務、意味のある命名、トリッキーなワザの封印（読み手を驚かせない）。
• 不変条件・前提条件・事後条件（契約）・アサーションを明文化し、「どんなときにこの関数は正しいのか」をはっきりさせる。
• 境界値・例外系・時刻やロケールなどのハマりやすいポイントは、コメントやテストケースにしっかり落とし込む。
• サンプルコードやテストコードを、動く仕様書（Executable Specification）として添えると理解がぐっと楽になる。

要旨

理由

結論

その他（実践・効果）

• if には基本的にelseを用意し、switch にはdefaultを用意する。ループには上限カウンタやタイムアウトを設定して、無限ループを防ぐ。
• 入力値の検証・サニタイズ（危険な部分を無害化）、タイムアウト設定、再試行＋冪等(べきとう＝ある操作を何回行っても結果は同じ)な設計、サーキットブレーカ(障害を一定回数検知すると即時エラーを返す)、トランザクションとロールバックなどで、安全側への退避ルートを用意する。
• エラーが起きたときにどうするか（処理を続ける／縮退運転に切り替える／即停止して大きく通知する）というエラー方針を、ドメインに照らして決めておく。
• 最小権限（権限を必要最低限に絞る）・確実なリソース解放・監視とアラートなどで、万が一のときも被害を最小限に抑える。
• 例：DBエラーが起きたとき、「そのまま継続」「ひたすらリトライ」「いったんロールバックして中断」という選択肢を比較し、そのシステムにとって本当に安全な選択を設計段階で決めておく。