設計セオリーをクイズで定着！
「プログラミングセオリー」要約＆クイズ

要旨

理由

結論

その他（範囲・効果・構成要素）

• 3つの価値（Three values）

  • コミュニケーション（Communication）…人に意味が伝わることを重視する。
  • シンプル（Simplicity）…ムダな複雑さを削ることを重視する。
  • 柔軟性（Flexibility）…あとから変えやすいことを重視する。

• 6つの原則（Six principles）

  • 結果の局所化（Local consequences）…変更の影響を狭い範囲に閉じ込める。
  • 繰り返しの最小化（Minimize repetition）…同じことを何度も書かない。
  • ロジックとデータの一体化（Logic and Data together）…処理とデータを近くにまとめる。
  • 対称性（Symmetry）…同じ種類のものは同じパターンで書く。
  • 宣言型の表現（Declarative Expression）…「どうやるか」より「何をしたいか」を書く。
  • 変更頻度（Rate of Change）…同じ理由・同じタイミングで変わるもの を同じ場所に集める。

要旨

理由

結論

その他（効果・実践）

• 効果：コードレビューのスピードアップ／変更着手のハードルが下がる／バグに早く気づきやすくなる。
• 実践：
  • 命名を一貫させる（同じ意味には同じ単語を使う）。
  • コードだけでは分かりにくい部分は、「なぜそうしているか（Why）」をコメントで補う。
  • インターフェース（外から見える入口）は必要最小限にしてシンプルに保つ。
  • 驚き最小の原則（予想外の動きをさせない）を意識する。

要旨

理由

結論

その他（範囲・指針）

• KISS（Keep It Simple, Stupid）やYAGNI（You Aren't Going to Need It）を守り、足し算より引き算で考える。
• 同じ処理の重複や、暗黙の依存関係を減らす（DRY・対称性の考え方を使う）。
• 場当たり的な例外処理や「とりあえず」のコードは、期限やメモを付けて管理し、放置せずできるだけ早く整理する。

要旨

理由

結論

その他（効果・実践）

• 効果：変更が決まった部分だけで済むようになり、デグレード（前は動いていたところが壊れること）と工数を減らせる。
• 実践：
  • 1つのモジュールの中で役割をはっきりさせて凝集度(４章参照)を上げ、モジュール同士の結合度を下げる。
  • インターフェース（抽象的な窓口）やDI（Dependency Injection＝依存性の注入）を使って、差し替えやすい構造にする。
  • 変更が起きやすい部分とあまり変わらない部分でレイヤーを分けておく。
  • テストで振る舞いを固定し、安心して中身を作り替えられるようにする。

要旨

理由

結論

その他（指針・効果）

• 指針
  • 一緒に変わりやすいコード同士は、近くにまとめて配置する。
  • 1つのモジュールの責務（役割）を明確にしておく。
  • モジュールの境目（インターフェース）では、責任の範囲をはっきり分ける。
• 効果：回帰バグが減る／レビュー・テストの「見るべき場所」を絞りやすい／リリース時のリスクが下がる。

要旨

理由

結論

その他（手段）

• ループ化／関数化／モジュール化で、処理を「最小の意味のかたまり」に分ける（数式の素因数分解のイメージ）。
• よく使うパターンは、テンプレートやコード生成、ライブラリとして切り出し、コピペではなく再利用する。

要旨

理由

結論

その他（実践）

• 特定のデータ型に対しては、そのデータに関するメソッド（操作）を一緒に持たせる。
• 関連するデータとロジックの集まりを、1つのモジュールやクラスとして扱う。
• DTO（Data Transfer Object＝データの入れ物）や生データをアプリ全体にバラまくのではなく、境界部分で専用の型や構造に変換してから内部で使う。

要旨

理由

結論

その他（具体例）

• 「追加する関数」があるなら、対になる「削除する関数」もそろえて用意する。
• 同じグループに属する関数は、同じような引数の取り方にそろえる。
• ある関数の中で呼ぶ関数たちの抽象度レベルをそろえる（SLAPの考え方：高いレベルの説明と低レベル詳細を混ぜない）。

要旨

理由

結論

その他（手段）

• アノテーション（属性・メタ情報）で設定をつけて、コードから離れた場所にルールをまとめる。
• 特定の問題領域に特化したDSL（domain-specific language＝ドメイン特化言語）で、「何がしたいか」を短い記述で表す。
• if文だらけのコードではなく、設定ファイルやテーブルに条件と結果をまとめるデータ駆動設計を使う。

要旨

理由

結論

その他（実践・効果）

• 実践：
  • 頻繁に変わる部分（例：画面や文言）と、あまり変わらない部分（例：ドメインルール）を別レイヤーに分ける。
  • 設定値・定数・メッセージなど「一括で変えたいもの」は、専用の場所に集約する。
• 効果：同じファイルを複数人で編集して衝突することが減る／どこを直せばいいか分かりやすい／変更にかかる時間を見積もりやすくなる。