もちもちみかん0系くん
『プリンシプル オブ プログラミング』プログラミングセオリーを20問で学べるクイズサイト

プリンシプル オブ プログラミング
プログラミングセオリー 要約＆クイズ

公開日：
最終更新日：

本ページでは、プログラミングの背景にあるセオリー（理論）を要点要約で整理します。単なる知識ではなく、設計の意図を理解することが目標です。

要約で理論を理解し、20問のクイズで定着。なぜその設計を選ぶのか、を論理的に説明できるようになりましょう！

今すぐクイズに挑戦
（20問・約5分・解説つき）
プリンシプルオブプログラミング
101の原理・原則を読む

目次

  1. プログラミングセオリーの要点・要約を読む(3分)
    1. 3.1 プログラミングセオリー（Programming theory）
    2. 3.2 ３つの価値①：コミュニケーション（Communication）
    3. 3.3 ３つの価値②：シンプル（Simplicity）
    4. 3.4 ３つの価値③：柔軟性（Flexibility）
    5. 3.5 ６つの原則①：結果の局所化（Local consequences）
    6. 3.6 ６つの原則②：繰り返しの最小化（Minimize repetition）
    7. 3.7 ６つの原則③：ロジックとデータの一体化（Logic and Data together）
    8. 3.8 ６つの原則④：対称性（Symmetry）
    9. 3.9 ６つの原則⑤：宣言型の表現（Declarative Expression）
    10. 3.10 ６つの原則⑥：変更頻度（Rate of Change）
  2. クイズに挑戦する(20問)
  1. クイズ一覧へ
  2. 第３章目次へ
  3. 次のクイズへ(アーキテクチャ根底技法)
  4. 前のクイズへ(第２章：原則)
  5. 『プリンシプル オブ プログラミング』101の原理・原則総まとめ
  1. 参考文献・出典
  2. このページの著者
  3. シェア

第３章：思想①
～プログラミングセオリー～

3.1 プログラミングセオリー（Programming theory）

  • 要旨：「最高のコード」とは拡張性が高く、余分がなく、読みやすく、理解しやすいコード。その実現を支えるのが「セオリー」で、3つの価値（コミュニケーション／シンプル／柔軟性）に立脚する。
  • 理由：価値→原則→実装という足場を明確にすることで、品質狙い（読みやすさ・拡張容易性）と日々の意思決定を接続できるため。
  • 結論：3つの価値を動機に、6つの原則をつなぎに、具体のコードを解決策として設計・実装する。
  • その他（範囲・効果・構成要素）：
    • 3つの価値（Three values）：
      • コミュニケーション（Communication）
      • シンプル（Simplicity）
      • 柔軟性（Flexibility）
    • 6つの原則（Six principles）：
      • 結果の局所化（Local consequences）
      • 繰り返しの最小化（Minimize repetition）
      • ロジックとデータの一体化（Logic and Data together）
      • 対称性（Symmetry）
      • 宣言型の表現（Declarative Expression）
      • 変更頻度（Rate of Change）

3.2 ３つの価値①：コミュニケーション（Communication）

  • 要旨：コードは人に見せるドキュメント＝コミュニケーション手段である。
  • 理由：開発コストの大半は保守段階で発生し、他者（＝未来の自分を含む）が理解できることが作業効率と品質を左右するため。
  • 結論：「他の人はこのコードを見てどう感じるか」を常に想像し、読みやすさ・意図の可視化を最優先にする。
  • その他（効果・実践）：
    • 効果：レビュー速度向上／変更着手が早まる／バグの早期発見。
    • 実践：命名の一貫性、意図（Why）のコメント、インターフェースの最小化、驚き最小の原則。

3.3 ３つの価値②：シンプル（Simplicity）

  • 要旨：「シンプル」とは余分な複雑性を除いた状態。動作に必要最小限で設計する。
  • 理由：余分な複雑性は価値を生まず、不具合・可読性低下・コミュニケーション阻害を招くため。
  • 結論：本質（玉）を拾い、不要（石）を捨てる設計を徹底する。毒をもって毒を制すようなコードを積まず、根本原因の除去を優先する。
  • その他（範囲・指針）：
    • KISS／YAGNIを遵守（盛り込みより引き算）。
    • 重複や暗黙依存を削減（DRY・対称性）。
    • 壊れやすい例外処理や一時しのぎは期限付きで管理し廃止。

3.4 ３つの価値③：柔軟性（Flexibility）

  • 要旨：柔軟性＝変更のしやすさ。将来の変更を前提にコードを備える。
  • 理由：コードは必ず変化するため、変更容易性が長期品質を決めるため。
  • 結論：拡張に開き・修正に閉じる（OCP）。関係性の高いコードは近接させ、関係性の低い部分は依存を持たないように設計する。
  • その他（効果・実践）：
    • 効果：局所変更で済み、回帰バグと工数が減る。
    • 実践：凝集度↑・結合度↓、抽象契約（インターフェース）とDI、変更頻度に基づくレイヤ分離、テストで振る舞いを固定。

3.5 ６つの原則①：結果の局所化（Local consequences）

  • 要旨：変更の影響が局所にとどまるようにコードを構成する（影響範囲の封じ込め）。
  • 理由：局所化されていないと、一箇所の変更が別領域へ波及し、変更コストが急増するため。
  • 結論：修正に対して閉じる（OCP）設計を採用し、変更は特定モジュール内で完結させる。
  • その他（指針・効果）：
    • 変更点の近接配置、責務の明確化、境界（インターフェース）で遮断。
    • 効果：回帰の抑制／レビュー・テストの焦点化／リリースリスク低減。

3.6 ６つの原則②：繰り返しの最小化（Minimize repetition）

  • 要旨：重複を排除し、1箇所の変更で全体が更新される構造にする（DRY）。
  • 理由：重複は「結果の局所化」を壊し、変更の拡散・不整合・テスト漏れを誘発するため。
  • 結論：コードを最小単位へ分解し共通化する。
  • その他（手段）：
    • ループ化／関数化／モジュール化（素因数分解の発想）。
    • テンプレート/ジェネレータ/ライブラリ化による再利用。

3.7 ６つの原則③：ロジックとデータの一体化（Logic and Data together）

  • 要旨：処理（ロジック）とそれが扱うデータを近く（同関数/同モジュール）に置く。
  • 理由：修正時はロジックとデータが同時に変わることが多く、近接していれば変更が容易で齟齬が減るため。
  • 結論：物理的にコロケーションし、データの近くで振る舞いを定義（カプセル化）。
  • その他（実践）：
    • データ型に関連メソッドを持たせる／集約ごとにモジュール化。
    • DTO/生データを裸で回さず、境界で変換してから処理。

3.8 ６つの原則④：対称性（Symmetry）

  • 要旨：同種の事柄は同じ表現で書く（API/命名/引数/抽象度の整合）。
  • 理由：対称性を明示すると、予測可能性が上がり、読みやすさが飛躍的に向上するため。
  • 結論：パターン・命名・引数・抽象度を揃える。
  • その他（具体例）：
    • 「追加」があれば対になる「削除」も用意。
    • 同一グループの関数は同じ引数を取る。
    • 関数内で呼ぶ関数の抽象度レベルを統一（SLAP）。

3.9 ６つの原則⑤：宣言型の表現（Declarative Expression）

  • 要旨：意図伝達は可能な限り命令形より宣言型で表現する。
  • 理由：宣言型は順序・分岐・状態追跡が不要で、事実が直に読めるため可読性が高い。
  • 結論：宣言的構文やデータ駆動を取り入れ、意図をシンプルに記述する。
  • その他（手段）：
    • アノテーションでメタ情報を付与／DSLで領域特化の宣言を採用。
    • 設定（データ）で挙動を切り替えるデータ駆動設計。

3.10 ６つの原則⑥：変更頻度（Rate of Change）

  • 要旨：「変更理由」と「変更タイミング」が同じものは同じ場所に集約する。
  • 理由：変更理由を複数持つモジュールは脆く、局所化が崩れるため。
  • 結論：単一責任の原則（1モジュール=1変更理由）に従い配置する。
  • その他（実践・効果）：
    • 頻繁に変わる部分と安定部分を分離、モジュール境界で隔離。
    • 効果：変更衝突の減少、レビュー容易化、予測可能な改修計画。

プリンシプル オブ プログラミング(第３章－プログラミングセオリー)

1. 【3.7．６つの原則③『ロジックとデータの一体化』②】
『ロジックとデータの一体化』を実践する主な理由はどれか？

2. 【3.5．６つの原則①『結果の局所化』⑤】
結果の局所化を高めるための有効な方法として最も適切なものはどれか？

3. 【3.5．６つの原則①『結果の局所化』④】
結果の局所化が実現されたコードの特徴として**適切でないもの**はどれか？

4. 【3.1．プログラミングセオリー⑥】
「副作用の影響範囲を最小限に抑える」原則はどれか？

5. 【3.3．３つの価値②『シンプル』⑤】
「毒をもって毒を制す」ような実装が好ましくないのはなぜか？

6. 【3.9．６つの原則⑤『宣言型の表現』②】
次のうち、『宣言型の表現』に該当するものはどれか？

7. 【3.9．６つの原則⑤『宣言型の表現』④】
『宣言型の表現』に分類される記法・技術として**適切でないもの**はどれか？

8. 【3.1．プログラミングセオリー③】
「コードはコンピュータではなく人が読むもの」として重視される価値はどれか？

9. 【3.1．プログラミングセオリー⑦】
「同じコードや構造を繰り返さないこと」で得られる利点に**該当しない**ものはどれか？

10. 【3.6．６つの原則②『繰り返しの最小化』④】
繰り返しの最小化を意識してコードを整理する際、最も有効な考え方はどれか？

11. 【3.1．プログラミングセオリー⑧】
「処理」と「それが扱うデータ」を近くに置くことで得られる利点はどれか？

12. 【3.4．３つの価値③『柔軟性』⑤】
次のうち、**柔軟性の低いコード**の特徴として最も適切なものはどれか？

13. 【3.3．３つの価値②『シンプル』③】
コードをシンプルに保つために**最も適した設計思想**はどれか？

14. 【3.8．６つの原則④『対称性』③】
『対称性』の原則に**反する実装**として適切なものはどれか？

15. 【3.7．６つの原則③『ロジックとデータの一体化』⑤】
『ロジックとデータの一体化』が特に有効となる場面はどれか？

16. 【3.7．６つの原則③『ロジックとデータの一体化』③】
『ロジックとデータの一体化』における「近くに配置する」とは、主にどういった範囲を指すか？

17. 【3.3．３つの価値②『シンプル』①】
プログラミングにおいて「シンプルなコード」とは、どのような状態を指すか？

18. 【3.1．プログラミングセオリー⑤】
将来の要件変更に対応できる設計が備えるべき価値は？

19. 【3.3．３つの価値②『シンプル』④】
次のうち、**シンプルさを損なう行動**として最も当てはまるものはどれか？

20. 【3.2．３つの価値①『コミュニケーション』⑤】
「コミュニケーション価値」を高めるコードを書く上で、**最も重要な視点**はどれか？

プログラミングセオリーの要約を読む クイズ一覧へ

参考文献・出典

  • プリンシプル オブ プログラミング ～3年目までに身につけたい一生役立つ101の原理原則～
  • 上田 勲（著）／秀和システム／第1版14刷／2025年／ISBN978-4-7980-4614-3

※本ページは学習支援を目的とした要約です。実務適用時は原典もご参照ください。

このページの著者

もちもちみかん（システムエンジニア）

社内SEとしてグループ企業向けの業務アプリを要件定義〜運用まで一気通貫で担当しています。

経験：Webアプリ／業務システム

得意：PHP・JavaScript・MySQL・CSS

個人実績：フォーム生成基盤／クイズ学習プラットフォーム 等


詳しいプロフィールはこちら！　　もちもちみかんのプロフィール

採点結果

正答率：0%

-

-
TOPへ

もちもちみかん.comとは


このサイトでは、コーディングがめんどうくさい人向けのお助けツールとして、フォームやCSSをノーコードで生成できる、
　もちもちみかん.forms
　もちもちみかん.css1
　もちもちみかん.css2
と言ったジェネレーターを用意してます。

また、このサイトを通じて、「もちもちみかん」のかわいさを普及したいとかんがえてます！