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

プリンシプル オブ プログラミング
第４章：視点 要約＆クイズ

公開日：
最終更新日：

コードの良し悪しを見抜くには、多角的な視点が必要です。本ページでは、視点編で学ぶべき要点を要約で一気に解説します。

要約でチェックポイントを学び、20問のクイズで実践。一歩踏み込んだプロの視点を身につけて、より質の高いコーディングを目指しましょう！

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

目次

  1. 第４章：視点の要点・要約を読む(3分)
    1. 4.1 凝集度（Cohesion）
    2. 4.2 結合度（Coupling）
    3. 4.3 直交性（Orthogonality）
    4. 4.4 可逆性（Reversibility）
    5. 4.5 コードの臭い（Bad smell in code）
    6. 4.6 技術的負債（Technical Debt）
  2. クイズに挑戦する(20問)
  1. クイズ一覧へ
  2. 次のクイズへ(第５章：習慣)
  3. 前のクイズへ(第３章：思想)
  4. 『プリンシプル オブ プログラミング』101の原理・原則総まとめ
  1. 参考文献・出典
  2. このページの著者
  3. シェア

第４章：視点
～プログラマの見る角度～

4.1 凝集度（Cohesion）

  • 要旨：凝集度は、モジュールに含まれる機能の純度（まとまりの強さ）を測る尺度で、高いほど望ましい。
  • 理由：機能が一つに集中しているほど、意図が明確になり、理解・変更・再利用が容易になるため。
  • 結論：機能的強度（1モジュール＝1役割）を目標に、責務を明確化する。
  • その他（レベル・効果・指針）：
    • 凝集度の7レベル（弱→強）：
      • レベル1：暗合的強度…偶然の寄せ集め。要素間に特別な関係がない／再利用性が低い。
      • レベル2：論理的強度…抽象的に似た機能をまとめるが、実行は一部のみで関連が弱い。
      • レベル3：時間的強度…同じタイミングで連続実行される処理の寄せ集め（機能間の関連が弱い）。
      • レベル4：手順的強度…大きな手順の一部だけを1モジュールにまとめた状態。
      • レベル5：連絡的強度…手順的＋データの受け渡し／同一データ参照で、手順的より強い。
      • レベル6：情報的強度…特定のデータ構造を扱う複数機能を集合化（複数入口点・各入口は単一機能）。
      • レベル7：機能的強度…すべての命令が単一の役割達成に緊密に関係。
    • 低凝集の弊害：
      • コードが理解しにくい。
      • コードが保守しにくい。
      • コードが再利用しにくい。
      • 脆弱で変更の影響を受けやすい。
    • 高凝集の利点：
      • コードが理解しやすい。
      • コードが保守しやすい。
      • コードが再利用しやすい。
      • モジュール間の疎結合を同時に促進。
    • 指針：
      • できるだけ機能的強度を目指す（1つのソフトウェア／モジュールには1つのこと）。

4.2 結合度（Coupling）

  • 要旨：結合度はモジュール間の関係の強さ（太さ）の尺度で、弱いほど望ましい。
  • 理由：結合が強いと相互依存が増え、変更の波及・理解負荷・障害リスクが高まるため。
  • 結論：データ結合を目標に、明確なインターフェースでやり取りし、変更を局所化する。
  • その他（レベル・注意・指針）：
    • 結合度の6レベル（強→弱）：
      • レベル1：内容結合…内部を共有・改変（最悪）。一方の変更が他方へ直結。
      • レベル2：共通結合…グローバル変数の共同使用。
      • レベル3：外部結合…外部宣言（public）の共有（不要な共有が減る）。
      • レベル4：制御結合…スイッチ変数で振る舞いを指示（相手の内部を知る必要）。
      • レベル5：スタンプ結合…複合データを丸ごと受け渡し（不要な項目も渡る）。
      • レベル6：データ結合…必要なスカラ値のみを受け渡し（最良）。
    • 相互依存の問題：
      • 密結合だと、関連変更により読解・同時修正の負担が増大。
    • 指針：
      • データの受け渡しはできるだけ引数で行う。
      • データの置き場所はグローバル変数を避ける。
      • 制御フラグ依存の関数（例：「1で追加／0で削除」）は分割して役割を分ける。
      • 結合の強さ・太さだけでなく、本数・方向（多対多／双方向）にも注意。

4.3 直交性（Orthogonality）

  • 要旨：コード要素同士を独立・分離させ、互いの影響を最小化する。
  • 理由：直交性があると、変更が局所化されて生産性が上がり、依存が減ってリスクが下がるため。
  • 結論：モジュール間の結合度を最小化し、明確な境界とレイヤーで直交性を保つ。
  • その他（メリット・指針）：
    • メリット：
      • 生産性の向上…変更の局所化により開発・テスト期間を短縮／疎結合で再利用性が促進。
      • リスクの軽減…問題箇所の隔離で堅牢化／依存が少なくテスト容易・検証しやすい。
    • 指針：
      • コードのレイヤー化…独立したモジュールをレイヤーごとに整理・抽象化し、各レイヤーは直下レイヤーの公開抽象のみを使用。
      • リレーションの直交性…データ重複を避け、一意性を保つ（テーブル複製や年度別分割による重複・非正規化を避ける）。

4.4 可逆性（Reversibility）

  • 要旨：「アンドゥ（元に戻す）」が可能な選択・設計を心がけ、不可逆な決定を避ける。
  • 理由：最終決定は幻想であり、特定の事実や技術に深く依存すると前提が変わった際にコードが破綻するため。
  • 結論：変更に耐えるため、柔軟で適応的かつ独立性の高い設計にし、必要に応じて間接化のレイヤーをアーキテクチャ段階で設ける。
  • その他（指針・効果）：
    • 指針：コードに柔軟性を持たせる／特定技術への過度な依存を避ける／モジュールを独立させて変更しやすい状態にする。
    • 効果：やり直し（ロールバック）が容易になり、要件・環境変化に伴うリスクを低減できる。

4.5 コードの臭い（Bad smell in code）

  • 要旨：理解しにくい／修正しにくい／拡張しにくい兆候を「臭い」と捉え、嗅ぎ分けて改善する。
  • 理由：臭いは設計上の問題のシグナルであり、適切なリファクタリングによって品質を回復・向上できるため。
  • 結論：臭いの傾向を知り、小さく安全に改善を重ねる（テストで保護）。
  • その他（代表例）：
    • よく見る：そっくりなコードが散在→重複を1つの関数に統合。
    • 長すぎる：見た目が長大→分割して短く。
    • 大きすぎる：見た目が巨大→「1つ1仕事」の原則で分解し小さく。
    • 多すぎる：モジュールが過多→不要な仲介を削除／統廃合して数を減らす。
    • 名前が合わない：名前と実装が不一致→直ちに適切な名前へ変更。

4.6 技術的負債（Technical Debt）

  • 要旨：速さを優先した汚い実装は「時間を借用」する借金。緊急時に選ぶことはあっても、すぐに返済すべき。
  • 理由：負債は将来の保守・品質・速度に利息（追加コスト）として跳ね返るため。
  • 結論：やむを得ず負債を取る場合は即時対応＋速やかな返済（きれいなコードへの修正）を徹底し、「暫定ソリューション」も同様に扱う。
  • その他（運用・範囲）：
    • 運用：負債の可視化・管理（内容／影響／返済期限）→返済を計画に組み込み着実に解消。
    • 範囲：暫定ソリューションは長生きしがち→放置せず早期に健全化する。

プリンシプル オブ プログラミング(第４章：視点)

1. 【4.3．直交性②】
次のうち、「直交性」の高い設計に最も該当するものはどれか？

2. 【4.3．直交性④】
次のうち、「直交性の低いコード」の特徴として最も適切なものはどれか？

3. 【4.1．凝集度④】
次の凝集度のレベルのうち、「手順的強度」と「情報的強度」の中間に位置するものはどれか？

4. 【4.4．可逆性⑩】
「可逆性」の本質的な意味として最も適切なものはどれか？

5. 【4.2．結合度④】
「モジュールAがモジュールBの動作を決定するような制御情報（スイッチなど）を渡す結合」はどれか？

6. 【4.3．直交性①】
「直交性」のあるコード設計のメリットとして、最も適切なものはどれか？

7. 【4.4．可逆性⑧】
以下のうち、「可逆性の高い設計にする工夫」として適切でないものはどれか？

8. 【4.3．直交性⑨】
次のうち、ソフトウェアの「直交性」を高めるために有効な設計手法はどれか？

9. 【4.2．結合度⑩】
結合度が高い状態に起こりがちな問題として、最も適切なものはどれか？

10. 【4.1．凝集度⑥】
次のうち、「機能的強度」の特徴として最も正しいものはどれか？

11. 【4.6．技術的負債⑥】
技術的負債を「返済」する方法として、最も適切なものはどれか？

12. 【4.1．凝集度⑤】
次のコード説明に最も該当する凝集度レベルはどれか？
「1つのデータ構造（例：顧客情報）をもとに、更新・削除・検索といった複数の独立機能が同じモジュール内に定義されている」

13. 【4.2．結合度②】
次のうち、結合度が最も高く、望ましくないモジュール間の関係はどれか？

14. 【4.4．可逆性⑨】
可逆性のあるアーキテクチャ設計の例として、最も適切なものはどれか？

15. 【4.4．可逆性④】
「可逆性」における判断・設計の基本方針として適切でないものはどれか？

16. 【4.1．凝集度⑧】
「凝集度の低いモジュール」に見られる特徴として、最も適切なものはどれか？

17. 【4.1．凝集度③】
以下のモジュール構造のうち、「時間的強度」の特徴として最も適切なものはどれか？

18. 【4.6．技術的負債①】
「技術的負債」の概念として最も適切な説明はどれか？

19. 【4.3．直交性⑧】
以下の設計上の行為のうち、「直交性を損なう行為」として最も適切なものはどれか？

20. 【4.4．可逆性③】
ソフトウェアにおいて「可逆性が高い設計」として最もふさわしいものはどれか？

第４章：視点の要約を読む クイズ一覧へ

参考文献・出典

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

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

このページの著者

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

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

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

得意：PHP・JavaScript・MySQL・CSS

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


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

採点結果

正答率：0%

-

-
TOPへ

もちもちみかん.comとは


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

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