もちもちみかん0系くん
もちもちみかんどっとこむ（プログラミングの基礎と原則が学べるクイズサイト）

プログラミング クイズ

KISS・DRY・OCPなど設計の基礎・原則を5分で学べます。
全12章×毎回20問・全問解説つき・スマホ対応・無料。

  1. ホーム
  2. プログラミング クイズ

プログラミング クイズとは？

プログラミングの基礎知識や設計の考え方を短時間で確認できる4択クイズです。
本ページでは KISS・DRY・OCPなどの設計の基礎を扱い、初心者は基礎の習熟に、中級者は理解度のセルフチェックに最適です。

プログラミング クイズを開始
（20問・約5分）

■免責事項■

本クイズは、プログラミングおよびソフトウェア設計に関する理解を深めることを目的として作成されたものであり、正確性・完全性・最新性を保証するものではありません。

本クイズの内容は、一般的な設計原則や哲学的背景に基づいて構成されていますが、すべての現場や状況に適用できるとは限りません。

出題内容や解答・解説において、誤りや誤解を招く表現が含まれている可能性があります。あらかじめご了承ください。

本クイズの利用により生じたいかなる損害・損失についても、当方は一切の責任を負いかねます。

問題文・選択肢・解説の内容は予告なく変更・更新される場合があります。

教育・学習・社内研修などに利用される場合は、各自の判断と責任のもとでご活用ください。

目次

  1. よくある質問
  2. プログラミング基礎・原則の要点(抜粋)
  3. プログラミング クイズ（抜粋）
  4. 第１章：前提
  5. 第２章：原則
  6. 第３章：思想① プログラミングセオリー
  7. 第３章：思想② アーキテクチャ根底技法
  8. 第３章：思想③ アーキテクチャ非機能要件
  9. 第３章：思想④ ７つの設計原理
  10. 第３章：思想⑤ UNIX思想
  11. 第３章：思想⑥ UNIX哲学
  12. 第４章：視点
  13. 第５章：習慣
  14. 第６章：手法
  15. 第７章：法則
  16. 参考文献・出典

よくある質問（FAQ）

プログラミング クイズとは？
基礎用語から設計原則までを短時間で確認できる4択クイズ集です。無料で、スマホでも解けます。
プログラミング クイズでは何が学べますか？
KISS・DRY・OCPなどの主要な設計の基礎を5分で学べます。全12章×毎回20問、全問解説つきです。
何問ありますか？
全12章あり、章によって異なりますが、各60問程度から、毎回ランダムに20問を出題します。
1回あたりの所要時間は約5分です。
対象レベルは？
初学者〜中級者向けです。KISS・DRY・OCPやUNIX哲学など、設計の基礎を中心に扱います。
解説はありますか？
全問解説つきです。間違えた問題の復習もしやすい構成です。
出題や選択肢の順序は毎回同じですか？
問題も選択肢も毎回シャッフルされます。
ただし表示される選択肢ラベルは A・B・C・D の順で固定です。
遊び方を教えてください
各設問は4択です。答えを選んで「次へ」を押してください。最後にスコアが表示されます。
キーボード操作：上下または左右キーで選択、Enterキーで決定（対応ブラウザのみ）。
途中でやめた場合、進捗は保存されますか？
現在は保存しません。ページを離れると最初からになります。
料金はかかりますか？
無料で利用できます。
スマートフォンやタブレットでも使えますか？
はい。最新の Chrome / Safari / Edge / Firefox での利用を推奨しています。
JavaScript を有効にしてご利用ください。
学習の参考になる関連情報はありますか？
各章に学習の為のコンテンツが用意してあります（KISS・DRY・OCP・UNIX哲学など）。
参考文献：プリンシプル オブ プログラミング～3年目までに身につけたい一生役立つ101の原理原則～
不具合や誤りを見つけました
お手数ですが、お問い合わせフォームからご連絡ください。内容を確認し、順次修正します。
注意事項
本クイズは学習支援を目的としたものであり、正確性・完全性を保証するものではありません。
仕様や内容は予告なく変更される場合があります。

プログラミング原則の要点（抜粋）

代表的な設計原則は KISS・ DRY・ OCP・ YAGNI・ PIE・ SLAP の6つで、重複を避けつつ単純さと拡張性、意図の明確さ、抽象度の統一を保つ考え方である。

要点一覧（抜粋）

  1. KISS：必要最小限で単純に作る
  2. DRY：処理や作業の重複をなくす
  3. OCP：拡張に開き変更に閉じる
  4. YAGNI：今必要でない機能は実装しない
  5. PIE：意図が伝わる表現で書く
  6. SLAP：同じ抽象度でまとめる

このページの要点

KISS原則とは？

KISS原則とは、必要最小限で単純に作り、余計な複雑さを避ける指針である。 将来の不確実な要件を先読みせず、今の要件を最もシンプルに満たす。

DRY原則とは？

DRY原則とは、重複をなくして単一の場所で知識を管理する考え方である。 不整合と保守コスト増を防ぐため、再利用と抽象化で一元化する。

OCP（オープン・クローズドの原則）とは？

OCP原則とは、機能追加には開き既存の安定部分の変更には閉じる設計原則である。 拡張点の追加で新しい要件に対応する。

YAGNI原則とは？

YAGNI原則とは、今必要でない機能は実装しないという考え方である。 先回りの拡張が招く複雑化を避け、現在の価値に集中する。

PIE原則とは？

PIE原則とは、意図を正しく読み取れる表現でコードを書く指針である。 名前・構造・コメントを工夫し、迷いなく理解できる状態を目指す。

SLAP原則とは？

SLAP原則とは、異なる抽象度を混在させず同じレベルでまとめる指針である。 高レベルの手順と低レベルの詳細を分離して可読性を高める。

プログラミング クイズ（抜粋）

初心者向けのプログラミング クイズから超基礎を8問ピックアップ（4択）。用語・原則の理解を短時間で確認できます。

KISS原則に基づいた設計判断として最も適切なものはどれか？

  1. 将来の可能性に備えて拡張機能を今のうちに実装する
  2. 現在の要件を満たす最もシンプルな方法を選ぶ
  3. 複雑でも柔軟な抽象化を最初から導入しておく
  4. 新しいライブラリを試すことを優先してコードに組み込む

答え：B

解説：KISSは「必要最小限を単純に」。将来予測の作り込みや過剰な抽象化は避ける。

DRY原則の本質に最も近い考え方はどれか？

  1. 似た処理でも都度最適な形に書き換えるべき
  2. 繰り返す行為を人手で丁寧に管理する
  3. 可能な限り重複を取り除き、1箇所で管理する
  4. あえて重複を残して安全性を担保する

答え：C

解説：DRYは「1つの事実は1箇所だけ」。重複は不整合と保守コスト増の元。

OCPの基本的な設計指針はどれか？

  1. すべてのコードは毎回書き直すべきである
  2. 機能追加のたびに元のコードを直接修正すべきである
  3. 拡張は許容し、既存コードの修正は極力避けるべきである
  4. 実装の詳細をコードの先頭に明記すべきである

答え：C

解説：OCPの原則では、コードは新たな要件に「拡張」できるようにしつつ、既存の安定したコードを「修正」しないようにすることが求められる。

YAGNI原則の主な主張として最も適切なものはどれか？

  1. 将来の要件を先読みして、あらかじめ実装しておくべき
  2. 実装の拡張性を優先し、複雑でも柔軟性を高めるべき
  3. 今すぐ必要な機能に限定して、コードを書くべき
  4. できるだけ機能を盛り込んで万全を期すべき

答え：C

解説：YAGNIは「今必要でないものは書くな」という原則であり、不要な機能追加はコードを複雑化させ、結果として保守性を損なう原因となる。

PIE原則における「意図を明確に表現するコード」が重要とされる主な理由はどれか？

  1. コンピュータに正しく処理させるため
  2. テストの自動化を進めるため
  3. 他の開発者がコードの意図を読み取るため
  4. コード量を減らすため

答え：C

解説：PIEは「人にとって読みやすいコードを書く」ことを重視し、読み手が意図を正しく理解できるように、コードを明快に表現することを推奨している。

SLAP原則において「抽象化レベルを統一して書く」ことの主な目的は何か？

  1. 処理を高速化するため
  2. 再利用性を高めるため
  3. 要約性と可読性を両立させるため
  4. コードサイズを縮小するため

答え：C

解説：SLAP（抽象化レベルの統一）は、関数やブロックの粒度を揃えることで、全体の構造を理解しやすくし、保守性や可読性を高めることを目的としている。

『割れた窓ガラスの法則』とは、どのような考え方か？

  1. 小さな問題でも放置すれば大きな問題につながる
  2. 大きな問題から優先的に修正するべきという考え方
  3. 窓の設計に注意すべきという建築理論
  4. 見た目よりも中身を重視するべきという思想

答え：A

解説：小さな乱れを放置すると全体が荒廃するという考え方で、ソフトウェア開発にも適用される。

「驚き最小の原則」において、ユーザーにとって最も重要な設計方針はどれか？

  1. インターフェースをなるべく複雑にする
  2. 利用者の想定外の動作を多用する
  3. 利用者が予想しやすい挙動にする
  4. 新しい操作方法を常に導入する

答え：C

解説：「驚き最小の原則」とは、ユーザーが「そう動くと思った通りに動く」ことに価値を置く設計原則である。意外性より予測可能性が重要。

第１章：前提
～プログラミングの変わらぬ真実～

解説を読む(2分) クイズに挑戦する(15問)

第２章：原則
～プログラミングのガイドライン～

解説を読む(2分) クイズに挑戦する(20問)

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

解説を読む(3分) クイズに挑戦する(20問)

第３章：思想②
アーキテクチャ根底技法

解説を読む(3分) クイズに挑戦する(20問)

第３章：思想③
アーキテクチャ非機能要件

解説を読む(3分) クイズに挑戦する(20問)

第３章：思想④
７つの設計原理

解説を読む(3分) クイズに挑戦する(20問)

第３章：思想⑤
UNIX思想

解説を読む(3分) クイズに挑戦する(20問)

第３章：思想⑥
UNIX哲学

解説を読む(3分) クイズに挑戦する(20問)

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

解説を読む(3分) クイズに挑戦する(20問)

第５章：習慣
～プログラマのルーティン～

解説を読む(3分) クイズに挑戦する(20問)

第６章：手法
～プログラマの道具箱～

解説を読む(3分) クイズに挑戦する(20問)

第７章：法則
～プログラミングのアンチパターン～

解説を読む(3分) クイズに挑戦する(20問)

参考文献・出典

  • プリンシプル オブ プログラミング ～3年目までに身につけたい一生役立つ101の原理原則～（上田 勲）

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

プログラミング クイズ

0 / 0
読み込み中...
スコア：0 / 0

プログラミング基礎原則のまとめ①

1.1 プログラミングに銀の弾丸はない

  • 要旨：万能な技術や特効薬（銀の弾丸）は存在しない。
  • 理由：ソフトウェアには以下の４つの複雑さがあり、ソフトウェアの本質が、定義上それらを取り除けないものだからである。
    • 複雑性：対象が大きく多様で本質的に複雑。
    • 同調整：現実世界の変化に継続的に同調し続ける必要。
    • 可変性：要求・環境の変化に伴い絶えず修正・進化を強いられる。
    • 不可視性：概念の集積体で目に見えない（製品・プロセス・意思決定の履歴も不可視）。
  • 結論：歴史から学び、地道な改善を積み重ねる。ただし、偶有的な複雑さ（スキル不足・設計不備・非効率ツールなど）は排除・軽減可能であるためこちらを改善し、本質へ注力する。
  • その他（行動指針）：
    • 本質的な複雑さから逃げずに向き合う。
    • 偶有的な複雑さは設計力・技術力・チーム運営で着実に削る。

1.2 コードは設計書である

  • 要旨：「基本設計 → 詳細設計 → プログラミング → テスト → デバッグ」まで広義の設計であり、最終アウトプットが設計書＝コードである。
  • 理由：多くの事実は実装して初めて露わになり、最終的にはコードが設計を確定させるため。
  • 結論：プログラミング＝設計として捉え、全員が仕様作成から実装まで担う。よってできるだけ早くコードを書き始め、動くものから妥当性を検証する。また、設計理由（Why）はコメントや補足ドキュメントで明示する。
  • その他（実践ポイント）：
    • 動くコードでフィードバックループを回す。
    • Whyはコメントや設計メモとして残す（決定理由・代替案・トレードオフなど）。

1.3 コードは必ず変更される

  • 要旨：コードは一度書いて終わりではない。将来必ず変更される。
  • 理由：ソフトウェアは本質的に複雑で、要求変更・不具合修正・新仕様対応が継続的に発生するため、完璧は到達不能。
  • 結論：「いずれ変わる」前提で変更に強いコードを書く。最重要は読みやすさ（理解しやすい＝変更しやすい）。
  • その他（変更に強くするコツ）：
    • 明確な命名と一貫した構造。
    • 小さな関心事に分割し疎結合を保つ。
    • テストで振る舞いを固定し、安心してリファクタリング。

プログラミング基礎原則のまとめ②

2.1 KISS（Keep It Simple, Stupid.）

  • 要旨：常に単純性・簡潔性を最優先し、「動かすための最小」を選ぶ。余計なことはしない。
  • 理由：場当たりの修正は無秩序と複雑化を招き、理解・保守・信頼性を損なうため。
  • 結論：最小構成で設計・実装し、削る姿勢で品質を守る。
  • その他（指針）：
    • 新技術の無理な導入はしない。
    • 今不要なものは今書かない（多くは結局不要）。
    • プログラマが勝手に要件変更しない。
    • Less is more（より少ないことは、より豊かなこと）。
    • オッカムの剃刀（必要以上に多くの前提を仮定すべきでない）。

2.2 DRY（Don't Repeat Yourself.）

  • 要旨：重複をなくす。同じコードも、コードをなぞるだけの重複コメントも避ける。
  • 理由：重複は読み手と修正を迷わせ、テストの抜けや不整合を生むため。
  • 結論：抽象化により重複を排除し、一箇所の変更で済む構造にする。
  • その他（手段と適用範囲）：
    • ループ化／関数化／モジュール化で要素を最小単位へ（素因数分解の発想）。
    • DRYはビルド／テスト／デプロイ工程などプロセスにも適用（共通化・自動化）。

2.3 YAGNI（You Aren't Going to Need It.）

  • 要旨：「多分必要」は多くの場合必要にならない。今必要なものだけ実装する。
  • 理由：将来想定の盛り込みは、未使用機能と無駄な複雑さを生みやすい。
  • 結論：現時点の要件に集中し、必要になった時にその時点のコストを支払う。シンプルさは結果的に変更に強い。
  • その他（実践のコツ）：
    • 将来拡張の余地は残しても、複雑さは増やさない。
    • 過剰汎用化や早すぎる最適化を避ける（KISS/DRYと整合）。

2.4 PIE（Program Intently and Expressively.）

  • 要旨：コードは人が読む。意図を明確かつ表現的に伝える。
  • 理由：読み手が理解できてこそ変更が始まる。ただし、コードは主にWhat/Howしか示せず、Whyは失われやすい。
  • 結論：読みやすさ最優先。コードで誤解を減らし、Why（設計理由）はコメントや補足で補完する。
  • その他（実践ポイント）：
    • 明確な命名と一貫した構造、短い文・小さな関数。
    • コメントは意図・前提・トレードオフを記す（コードの繰り返しはしない：DRY）。

2.5 SLAP（Single Level of Abstraction Principle.）

  • 要旨：関数やブロックごとに抽象化レベルを揃える。同じ高さの記述を並べて、読む/要約する負荷を下げる。
  • 理由：レベルが揃っていれば要約性＋閲覧性が同時に高まり、処理の流れが自然に立ち上がって読みやすくなるため。
  • 結論：プログラムを文書のように構造化し、上位は下位のみを呼ぶ（横刺し・逆流は避ける）。
  • その他（指針）：
    • 序章：プログラムの趣旨を述べるコメント。
    • 目次：関数一覧（外形を先に示す）。
    • セクション：モジュール群のまとまり。
    • 章：各関数。
    • 段落：関数内のコードブロック。
    • 文：ステートメントは短く、1文1責務。
    • 呼び出し規律：上→下はOK／横・上方向の直接呼び出しは避ける。

2.6 OCP（Open-Closed Principle）

  • 要旨：コードは拡張に開き、既存のコード修正には閉じるよう設計する。
  • 理由：ソフトウェアの寿命は想定より長く、変化に晒され続けるため、安定運用と変更容易性の両立が必要。
  • 結論：インターフェース／抽象を境界に据え、実装を直接呼ばずに差し替える。必要最小の抽象でシンプルさも維持。
  • その他（適用指針・割り切り・戦略）：
    • 境界設計：ポリモーフィズム/DI/プラグイン等で新機能は追加で注入。
    • 割り切り：過剰抽象は禁物。まずはシンプルに、最初の一撃（初回修正）は受け入れ、次から同種変更を受けない構造へ整える。
    • 関連原則：カプセル化やクラス化で影響範囲を局所化。

2.7 名前重要

  • 要旨：命名は最重要。名前は読み手にとってのUIであり、意味を不可逆に伝える。
  • 理由：適切な名前は仕様理解を直接支援し、誤読・手戻り・変更コストを大きく減らすため。
  • 結論：まず仕様を深く理解し、その理解から命名→コードへ落とす。実装を読み返し、命名が最適か随時検証する。
  • その他（実践ポイント）：
    • 説明→命名→説明の検証（ループバックチェック）を回す。
    • ドメイン語彙に合わせ、一貫性と具体性を優先（曖昧語・略語乱用を避ける）。
    • 名前で意図と契約を伝える（単位・範囲・前提を含意）。

プログラミング基礎原則のまとめ③-１

3.1 プログラミングセオリー

  • 要旨：「最高のコード」とは拡張性が高く、余分がなく、読みやすく、理解しやすいコード。その実現を支えるのが「セオリー」で、3つの価値（コミュニケーション／シンプル／柔軟性）に立脚する。
  • 理由：価値→原則→実装という足場を明確にすることで、品質狙い（読みやすさ・拡張容易性）と日々の意思決定を接続できるため。
  • 結論：3つの価値を動機に、6つの原則をつなぎに、具体のコードを解決策として設計・実装する。
  • その他（範囲・効果・構成要素）：
    • 3つの価値：
      • コミュニケーション
      • シンプル
      • 柔軟性
    • 6つの原則：
      • 結果の局所化（副作用や出力の所在を近接させる）
      • 繰り返しの最小化（DRY）
      • ロジックとデータの一体化（扱うデータの近くで処理する）
      • 対称性（似たものは似た形で書く）
      • 宣言型の表現（意図を直に表す）
      • 変更頻度（変わる所と変わらない所を分離）

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

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

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

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

3.4 ３つの価値③：柔軟性

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

3.5 ６つの原則①：結果の局所化

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

3.6 ６つの原則②：繰り返しの最小化

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

3.7 ６つの原則③：ロジックとデータの一体化

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

3.8 ６つの原則④：対称性

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

3.9 ６つの原則⑤：宣言型の表現

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

3.10 ６つの原則⑥：変更頻度

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

プログラミング基礎原則のまとめ③-２

3.11 アーキテクチャ根底技法（基礎原理）

  • 要旨：良いコードを下支えする基礎原理群を共有し、設計判断をぶらさない土台にする。
  • 理由：原理を共有すると、複雑性の制御・再利用性・変更容易性に一貫性が生まれるため。
  • 結論：プロダクト横断の共通チェックリストとして運用し、日々の設計・レビューに適用する。
  • その他（基礎原理リスト）：
    • 抽象
    • カプセル化
    • 情報隠蔽
    • パッケージ化
    • 関心の分離
    • 充足性、完全性、プリミティブ性
    • ポリシーと実装の分離
    • 参照の一点性
    • 分割統治

3.12 アーキテクチャ根底技法①：抽象

  • 要旨：概念に明確な線引き（抽象）を行い、モジュール同士を区別する。
  • 理由：良い抽象は無駄がなく使いやすい形で広く再利用でき、思考も効率化されるため。
  • 結論：本質に集中するため捨象を徹底し、抽象境界に一貫した名前と契約を与える。
  • その他（実践）：
    • 「捨てる勇気」：余計な属性や分岐を削り、汎用の公式を適用可能にする。
    • ドメイン語彙で境界命名、抽象に対するテスト（契約テスト）を用意。

3.13 アーキテクチャ根底技法②：カプセル化

  • 要旨：関連するデータ＋ロジックを一つのモジュールに包む（膜で包む）。
  • 理由：無関係の混入を防ぎ見通しが良くなり、変更の影響がモジュール内部に閉じるため。
  • 結論：関係の強い要素を同一モジュールにグルーピングし、変更範囲と影響度を明確化する。
  • その他（たとえ・効果）：
    • 例：材料（じゃがいも・にんじん・玉ねぎ）を料理化するのではなく、カプセル化しておけば用途が増える（カレー/シチュー/肉じゃが）。
    • 効果：見やすさ向上／影響の局所化／変更容易化。

3.14 アーキテクチャ根底技法③：情報隠蔽

  • 要旨：モジュール内部を極力非公開にし、外部は最小のインターフェースで扱う。
  • 理由：やり取りがシンプルになり、全体の複雑性を低減できるため。
  • 結論：公開は必要最小限に限定し、実装詳細は隠す（後方互換の余地を確保）。
  • その他（指針）：
    • モジュール利用者には利用に必要な情報だけを与え、それ以外は見せない。
    • モジュール実装者には実装に必要な情報を与えるが、外部には公開しない。

3.15 アーキテクチャ根底技法④：パッケージ化

  • 要旨：モジュールを意味単位にまとめてグループ化（全体を意味のある単位へ分割）。
  • 理由：関連要素を束ねることで整理され、複雑度が下がるため。
  • 結論：関連モジュールをボトムアップで集合化し、開発の進行に合わせて成長・進化させる。
  • その他（位置づけ）：
    • モジュール化＝ミクロの複雑性低下、パッケージ化＝マクロの複雑性低下。

3.16 アーキテクチャ根底技法⑤：関心の分離

  • 要旨：機能や目的といった関心ごとにコードを集約し、互いを独立モジュールとして分離する。
  • 理由：変更は多くが関心単位で発生し、分離しておけば局所変更で済むため。
  • 結論：異なる責務は分ける（MVCなど）。横断的関心事はAOP等で切り出す。
  • その他（例）：
    • DBとのやり取り／UI／その橋渡しの分離。
    • 各処理本体とログ機能の分離。

3.17 アーキテクチャ根底技法⑥：充足性・完全性・プリミティブ性

  • 要旨：モジュールが表現する抽象は充足（十分）・完全（漏れなし）・プリミティブ（純粋・原子的）であるべき。
  • 理由：充足不足は本質の見失い、完全でなければ安心して利用できず、プリミティブでなければ使いづらくなる。
  • 結論：モジュールの抽象を明確化し、提供関数は十分・完全・純粋なラインナップに整える。余計な機能は削除または別モジュールへ分離。
  • その他（判断基準の再掲）：
    • 充足性：抽象の意図を伝えるのに十分か。
    • 完全性：抽象の特徴を過不足なく備えるか。
    • プリミティブ性：操作が純粋・原子的で合成の混入がないか。

3.18 アーキテクチャ根底技法⑦：ポリシーと実装の分離

  • 要旨：「ポリシー（前提依存の選択やビジネス規則）」と「実装（前提に依存しない汎用ロジック）」を同一モジュールに混在させない。
  • 理由：ポリシーは変わりやすく、実装は安定しやすい。混在するとポリシー変更に実装が引きずられ再利用性が失われる。
  • 結論：ポリシーと実装を別モジュール化し、DI/設定/戦略パターン等で接続する。
  • その他（範囲・効果）：
    • ポリシーモジュール：前提・選択・ビジネスロジック。
    • 実装モジュール：純粋ロジック（ポリシーを引数やインターフェースで注入）。
    • 効果：変更の局所化／テスト容易化／流用性向上。

3.19 アーキテクチャ根底技法⑧：インターフェースと実装の分離

  • 要旨：モジュールはインターフェース（使い方の定義）と実装（機能の中身）を分離し、クライアントはインターフェースのみに依存する。
  • 理由：公開面が簡潔になり理解・利用が容易に。実装は背後で自由に変更できる。
  • 結論：「インターフェースに対してプログラムし、実装に対してではない」を徹底。直接実装呼び出しは禁止。
  • その他（範囲・効果）：
    • インターフェース＝契約／実装＝隠蔽。バージョン進化や差し替えに強くなる。
    • テストはインターフェース基点の契約テスト＋実装のユニットで二層化。

3.20 アーキテクチャ根底技法⑨：参照の一点性

  • 要旨：要素の宣言・定義は一度きりとし、状態更新を極力排す（単一代入）。
  • 理由：副作用を抑え、推論と検証が容易になる（バグの温床である可変共有状態を削減）。
  • 結論：再代入を避け、参照透過な関数・不変データ中心に設計する。
  • その他（概念整理）：
    • 単一代入：変数は一度代入したら変更しない。
    • 参照透過性：①戻り値が引数のみに依存（純粋）／②呼び出しが他の動作に影響しない（副作用なし）。

3.21 アーキテクチャ根底技法⑩：分割統治

  • 要旨：解きづらい大問題は、解きやすい小問題に分割し、各個に解いて統治する。
  • 理由：一体のままでは複雑性が高く最適解に到達しにくいが、分割で見通し・並行性・検証性が向上する。
  • 結論：粒度を調整しつつ小さくして各個撃破。責任単位・データ単位・計算単位で境界を引く。
  • その他（適用例）：
    • 全体設計：独立して設計できる部分へ分割。
    • モジュール設計：責任／責務で分割。
    • アルゴリズム：ボトムアップでサブ問題化して解決。
    • 大量データ：小さな単位へ分割し分散・並列実行を検討。
    • 備考：外堀から埋めるアプローチも分割統治の一形態。

プログラミング基礎原則のまとめ③-３

3.22 アーキテクチャ非機能要件

  • 要旨：機能以外の品質（非機能）は、アーキテクチャ設計で機能と同等に重視すべき領域。
  • 理由：非機能は運用・保守・拡張のコストとリスクを左右し、プロダクト価値の持続性を決めるため。
  • 結論：非機能観点で設計し、要件定義→設計→テストの各段で合格基準を明確化・検証する。
  • その他（範囲・観点・実践）：
    • 主要観点：
      • 変更容易性
      • 相互運用性
      • 効率性
      • 信頼性
      • テスト容易性
      • 再利用性
    • プロセス：
      • 要件定義：各観点の必要水準を合意。
      • 設計：非機能を満たす構造（境界・分離・標準化・冗長化等）を具体化。
      • テスト：非機能テストの合格基準を設定し「How」に着目して検証。
    • セキュリティ（CIA）：
      • 機密性(Confidentiality)：未認可主体に情報を非公開（アクセス制御・暗号化）。
      • 完全性(Integrity)：資産の正確性と完全さを保護（改ざん検知・署名）。
      • 可用性(Availability)：要求時に使用可能（冗長化・ウイルス/攻撃対策）。
    • 検証・運用上の要点：
      • ペネトレーションテストの実施（必要に応じ外部診断の活用）。
      • 利便性とのバランス：過度なパスワード要求等でUXを損なわない設計。

3.23 アーキテクチャ非機能要件①：変更容易性

  • 要旨：修正・拡張・再構成・移植を素早く安全に行える能力。
  • 理由：ソフトウェアは長寿命で変化対応が常態。迅速な要望反映と品質維持に直結するため。
  • 結論：設計を保守性／拡張性／再構築性／移植性の観点で評価・最適化する。
  • その他（観点別の設計指針）：
    • 保守性：変更の局所化、副作用の最小化（境界/インターフェース、テスト境界）。
    • 拡張性：クライアント非影響でモジュール交換可能（OCP、DI、プラグイン化）。
    • 再構築性：実装非依存の柔軟配置（レイヤ分離、構成の宣言化/コード化）。
    • 移植性：プラットフォーム依存部の隔離（HW/OS/UI/システムAPIを専用モジュールに集約）。
  • その他（劣化対策）：
    • ソフトウェアエージング(経年劣化)を前提に、正確なドキュメント、アーキテクチャ破壊を避ける変更規律、真摯なレビュー、変更予測に基づく柔軟設計で劣化速度を低減。

3.24 アーキテクチャ非機能要件②：相互運用性

  • 要旨：他システムとやり取りできる能力（機能連携・データ連携）。
  • 理由：ソフトウェアは大きなシステムの一部。高い相互運用性は用途拡大・期間短縮・コスト削減につながるため。
  • 結論：外部機能/データへのアクセス仕様を明確化し、業界標準のプロトコル・データ形式を採用する。
  • その他（実践・効果）：
    • 契約ベースのAPI設計（OpenAPI/GraphQLスキーマ等）、スキーマとバージョニングの管理。
    • データ交換は標準フォーマット（JSON/Avro/Protobuf等）と互換層で互換性を確保。
    • 効果：再利用性と拡張性の向上、内製範囲の縮小、異種環境との連携容易化。

3.25 アーキテクチャ非機能要件③：効率性

  • 要旨：限られたリソースで適切な性能を引き出す能力（時間効率性＋資源効率性）。
  • 理由：リソースは有限。無駄なく使い切る設計が、体感性能・運用コストの両方を左右するため。
  • 結論：節約（ムダ削減）と拡張（スケールさせる）の両輪で設計し、必要に応じて間接化を導入して疎結合・保守性・再利用性を確保する。
  • その他（範囲・指標・設計の勘所）：
    • 時間効率性：スループット／レスポンスタイム／ターンアラウンドタイムを計測・目標化。
    • 資源効率性：CPU時間・メモリ・ストレージ・ネットワークを監視・最適化。
    • 間接化の活用：キャッシュ層、キュー、アダプタ、抽象化（「レイヤを一段深く」で解ける問題は多い）。

3.26 アーキテクチャ非機能要件④：信頼性

  • 要旨：例外・不正利用・異常系でも機能を維持できる能力（フォールトトレランス＋ロバストネス）。
  • 理由：現実の運用では障害も誤操作も避けられず、異常時の設計が可用性と安全性を決めるため。
  • 結論：冗長化／フェールソフト／フェールセーフを設計原則に据え、可能ならフールプルーフで誤操作自体を無害化する。
  • その他（範囲・手当）：
    • フォールトトレランス：例外時も正しい振る舞いを保証（ロールバック、再試行、二重化）。
    • ロバストネス：不正入力や誤操作時に定義状態へ退避（安全側へ遷移）。
    • 設計パターン：サーキットブレーカ／タイムアウト／アイソレーション／優先度制御。

3.27 アーキテクチャ非機能要件⑤：テスト容易性

  • 要旨：ソフトウェアを効果的・効率的に検証できる能力（設計段階からテストを織り込む）。
  • 理由：正しく動くことに加え、容易に確かめられる構造が品質と開発速度を支えるため。
  • 結論：本体にテスト容易化の構造（依存の分離、インターフェース化、観測性）を組み込み、必要なら本番コード内のテスト支援も許容する。
  • その他（設計・検証の要点）：
    • 依存の注入（DI）、テストシーム、モック可能なインターフェース、純粋関数の活用。
    • 観測性：ログ／メトリクス／トレースで原因追跡を容易に。
    • テスト戦略：ピラミッド（ユニット中心）／契約テスト／E2Eは最小限で価値最大化。

3.28 アーキテクチャ非機能要件⑥：再利用性

  • 要旨：「する」と「される」の両面で再利用を最大化し、作らないことで品質と速度を上げる。
  • 理由：既知の解の活用はリードタイム短縮と欠陥低減に直結。一方、汎用部品化には固有の難しさがあるため。
  • 結論：３の法則を指針に汎用化し、APIの安定化・ドキュメント・バージョニングで採用性を高める。
  • その他（３の法則・実践）：
    • 難易度３倍の法則：再利用可能部品の設計は単用途の３倍難しい（一般化と境界設計が必要）。
    • テスト３種類の法則：共通化前に３つの異なるプロダクトで実地検証。
    • 実践：標準化（API/スキーマ）、セマンティックバージョニング、README/使用例、互換ポリシー、適正な粒度のパッケージ化。

プログラミング基礎原則のまとめ③-４

3.29 ７つの設計原理

  • 要旨：障害を作り込まないための７つの核心観点を共通言語として用い、設計とレビューの軸を揃える。
  • 理由：観点がぶれると指摘が一貫せず、品質が安定しないため。
  • 結論：以下の原理を設計規範／レビュー基準として採用し、チェックリスト化する。
  • その他（範囲・効果）：
    • 原理一覧：
      • 単純原理
      • 同型原理
      • 対称原理
      • 階層原理
      • 線形原理
      • 明証原理
      • 安全原理
    • 効果：レビューの再現性向上／暗黙知の形式知化／欠陥の早期発見・未然防止

3.30 ７つの設計原理①：単純原理

  • 要旨：常にシンプルにこだわり、見通しの良い自然なコードを書く。
  • 理由：障害は複雑な箇所に集中しやすいから。
  • 結論：高級テクニックより単純・直截・最小を選ぶ（必要十分で止める）。
  • その他（実践）：
    • 不要な抽象化や分岐を削る／一文一義／意図が一読で伝わる命名
    • 「まず動く最小」を基準にし、複雑化は証拠（計測・要件）が出たときのみ

3.31 ７つの設計原理②：同型原理

  • 要旨：「同じことは同じ形で」表現し、コードの一貫性を保つ。
  • 理由：形が揃うと「違和感＝不具合の芽」が浮き上がり、気づきやすくなるため。
  • 結論：自己流は避け、スタイル・パターン・命名・構造を統一する。
  • その他（実践）：
    • コーディング規約／テンプレート／共通ユーティリティの徹底
    • 似た処理のシグネチャ・戻り値・例外ポリシーを揃える

3.32 ７つの設計原理③：対称原理

  • 要旨：対称性（対）を意識して構造・制御・命名を設計する。
  • 理由：対称は予測可能性を高め、理解容易性と欠陥検出性を向上させるため。
  • 結論：条件には反条件を、操作には逆操作を設け、例外で対称が崩れる場合は要件から見直す。
  • その他（実践・例）：
    • 命名の対：get/set, start/stop, from/to, begin/end, open/close
    • 制御の対：if/else、try/finally（またはスコープ管理）／生成と破棄の対応
    • 例外多発時は要件が未整理のシグナルとして再整理

3.33 ７つの設計原理④：階層原理

  • 要旨：階層構造でコードを編成し、上位→下位の主従関係を明確にする。
  • 理由：階層化により抽象化して全体像を掴みやすくなり、理解・変更が容易になるため。
  • 結論：大分類→中分類→小分類（セクション→章→段落→文）の秩序で構造化し、上位からは下位を外部視点で扱う。
  • その他（実践）：
    • コードの階層マップ：セクション（モジュール集合）／章（関数）／段落（ブロック）／文（ステートメント）
    • 上位は下位を呼び出すが、横串・逆流の依存は避ける（層間依存の単方向性）

3.34 ７つの設計原理⑤：線形原理

  • 要旨：処理の流れは直線的（Linear）であることにこだわり、分岐と状態を最小化する。
  • 理由：スイッチ乱用や状態増殖は可読性を下げ、制御フローを複雑化させて障害の温床になるため。
  • 結論：分岐は減らす／単純化し、直線的に読めるコードを目指す（俯瞰して複雑化を常時チェック）。
  • その他（実践・効果）：
    • ガード節で早期returnし、ネストを浅く保つ。
    • 複雑な条件は述語関数化／表引き（テーブル駆動）で見える化。
    • 状態機械が必要なら明示的なステートと遷移表で管理（暗黙のフラグを増やさない）。
    • 処理を小さな直列パイプラインに分割して組み合わせる（1ステップ＝1責務）。

3.35 ７つの設計原理⑥：明証原理

  • 要旨：「一見して正しい」と判断できる明瞭なロジックを書く（明証性）。
  • 理由：コードは繰り返し読まれるため、読みやすさの維持が保守性＝品質に直結する。
  • 結論：ロジックの根拠をコード・コメント・図で示す。コードで足りないWhy/5W1Hはコメントや補助資料で補完する。
  • その他（実践・範囲）：
    • 単機能関数／一文一義、意味のある命名、不要なトリックの排除。
    • 不変条件・前後条件（契約）・アサーションで正しさを明文化。
    • 境界／例外／時刻・ロケール等の落とし穴を明示（コメントやテストケースに反映）。
    • サンプル・テストを使用例（Executable Spec）として添える。

3.36 ７つの設計原理⑦：安全原理

  • 要旨：起こり得ない条件も想定し、安全側に倒す設計・実装を行う（elseやデフォルト経路を怠らない）。
  • 理由：現実の運用では「想定外」が発生し、放置すればデータ破壊やサービス停止に波及するため。
  • 結論：フェールセーフ／フェールソフト／フォールトトレランスを織り込み、最も安全な振る舞いを選ぶ（中断・ロールバック・リトライを設計判断で使い分け）。
  • その他（実践・効果）：
    • ifのelse必須、switchのdefault、ループのセーフガード（上限・タイムアウト）。
    • 入力検証／サニタイズ、タイムアウト、再試行＋冪等、サーキットブレーカ、トランザクションとロールバック。
    • エラー方針の明確化：継続／縮退（重要機能のみ）／即時停止＋けたたましく通知（クラッシュは早く）。
    • 最小権限・確実なリソース解放・監視とアラートで被害最小化。
    • 例：DBエラー時に「継続／リトライ／ロールバックで中断」を比較し、ドメイン的に真に安全な選択を採用。

プログラミング基礎原則のまとめ③-５

3.37 UNIX思想

  • 要旨：UNIX思想は、長年の実践から生まれた設計・実装の技法群であり、今日でも有効な指針となる。
  • 理由：UNIXが長命なのは、初期に下した良質な設計判断（単純・明確・組み合わせやすさ）が核にあるため。
  • 結論：以降の各原則（モジュール化／明確性／組み立て部品／分離／単純性）を設計レビューと日々の実装の基準にする。
  • その他（効果）：
    • 変更容易性・再利用性・可観測性の向上
    • 障害の局所化・副作用の低減・学習コストの抑制

3.38 UNIX思想①：モジュール化の原則

  • 要旨：関係の強い要素をまとめてモジュール化し、最小限のインターフェースに削ぎ落とす。
  • 理由：シンプルなモジュールは他と絡まず、問題を局所化でき、全体を壊さず改良できるため。
  • 結論：余計な公開点を排除し、モジュール集合としてソフトウェアを構成する（小さく・疎に・明確に）。
  • その他（指針）：
    • 凝集度↑／結合度↓を常時モニタ
    • インターフェースは用途別に分割（不要な「ついでの引数」を持たせない）

3.39 UNIX思想②：明確性の原則

  • 要旨：「巧妙さ」より「明確さ」。人が読んで一目で分かるコードを目指す。
  • 理由：コードは人が何度も読むドキュメントであり、読みやすさが保守コストを決めるため。
  • 結論：意図が伝わる命名・整形・コメントを徹底し、推測を要する書き方を排除する。
  • その他（実践）：
    • Whyはコメント／What・Howはコードで表現
    • 例外方針・前提条件・制約を見える化

3.40 UNIX思想③：組み立て部品の原則

  • 要旨：入出力をデータストリーム（推奨：テキスト／JSON）として扱い、つなげて使える部品にする。
  • 理由：テキストインターフェースは単純で相互運用性が高く、部品同士が情報隠蔽されたまま合成できるため。
  • 結論：独自バイナリや過度なシリアライズより、シンプルなストリームインターフェースを優先し、パイプ可能な設計にする。
  • その他（効果）：
    • 疎結合／テスト容易／CLI・バッチ・サービスの再利用が容易
    • 監視・デバッグ（ログの人間可読性）も向上

3.41 UNIX思想④：分離の原則

  • 要旨：メカニズム（安定）とポリシー（変化）を分離する。
  • 理由：不安定なポリシーに安定なメカニズムが引きずられると、再利用性と保守性が損なわれるため。
  • 結論：境界を明示し、ポリシー変更はメカニズム非改変で差し替え可能にする。
  • その他（例／適用）：
    • サービス：フロント（ポリシー）／バック（メカニズム）の明確分離
    • エディタ：設定駆動の拡張インターフェース（ポリシー）と編集エンジン（メカニズム）
    • 設定ファイル／DI／プラグインで方針を外出し

3.42 UNIX思想⑤：単純性の原則

  • 要旨：設計・実装は常にシンプルであることを最優先にする。
  • 理由：複雑さは障害・失敗・コスト増の主要因であり、自制しない限り自然に増殖するため。
  • 結論：「Less is more(より少ないことは、より豊かなこと）」を合言葉に、最小構成で出荷し、必要性が立証された分だけ段階的に足す。
  • その他（文化・運用）：
    • 「シンプルは美徳」を称賛する文化を醸成（複雑さを安易に褒めない）
    • 設計審査で削れる理由を必ず検討（足す前に引く）

3.43 UNIX思想⑥：倹約の原則

  • 要旨：大きい＝量と複雑さを避け、継ぎ足しではなく小さく作る。
  • 理由：巨大化は「毒をもって毒を制す」設計を招き、複雑化→保守困難→破綻のリスクを高めるため。
  • 結論：常に削ってから足す。小さな関数・小さなモジュールで構成し、不要物は除去する。
  • その他（範囲・効果・実践）：
    • 関数の責務を限定（単一責任）／死蔵コード(持っているだけで使わない)や重複を排除
    • ファイル・APIのLOCや引数数に上限の目安を設ける

3.44 UNIX思想⑦：透明性の原則

  • 要旨：動作を外から理解可能に設計する。透明性（何をどうしているか即把握）と開示性（内部状態を監視・表示可能）を備える。
  • 理由：見える化はデバッグ／障害調査を容易にし、運用リスクを下げるため。
  • 結論：設計初期から観測点を組み込み、本番コードにもデバッグしやすさを内蔵する。
  • その他（実践）：
    • 構造化ログ／メトリクス／トレース／ヘルスチェック／診断エンドポイント
    • 失敗時の再現情報を最小コストで取得できる仕組みを用意

3.45 UNIX思想⑧：安定性の原則

  • 要旨：ソフトウェアを安定化させる（透明・単純を保つ）。
  • 理由：不安定なソフトウェアはユーザー価値を著しく損なうため。
  • 結論：読み解ける内部構造と単純な制御で、入力変動や例外に強い実装を保つ。
  • その他（実践）：
    • コードレビュー：作者が内部構造を説明できない＝危険信号
    • 特異／極端入力の検証：ツールや他ソフトからの入力でストレステスト

3.46 UNIX思想⑨：表現性の原則

  • 要旨：情報はロジックでなくデータで表現する（テーブル駆動・設定駆動）。
  • 理由：手続きロジックは人に理解されにくい一方、データ構造は把握しやすいため。
  • 結論：ロジック複雑化かデータ複雑化の選択では、データ構造の充実を優先する。
  • その他（範囲・例）：
    • DBカラムや設定で分岐を外出し／ルールテーブル・DSLで意図を宣言化

3.47 UNIX思想⑩：驚き最小の原則

  • 要旨：インターフェースは利用者の予想通りに動くよう設計し、驚きを最小化する。
  • 理由：学習すべき新規事項が減り、習得コストが下がるため。
  • 結論：ユーザーの既知を最大活用し、用語・挙動・見た目を一貫させる。
  • その他（設計指針）：
    • 類似ソフトのインターフェースをモデル化／想定ユーザーの素養に合わせる
    • 伝統・慣習を尊重／「一見似て非なる挙動」を避ける

3.48 UNIX思想⑪：沈黙の原則

  • 要旨：出力は最小限に抑え、重要情報だけを見せる「寡黙な」動作を徹底する。
  • 理由：冗長な出力は重要情報を埋没させ、利用者の判断を誤らせるため。
  • 結論：本当のエラーのみを標準エラーへ出力し、進捗等は冗長（verbose）切替を用意してデフォルトは無効にする。
  • その他（範囲・実践）：
    • 情報レベル（ERROR/WARN/INFO/DEBUG）の基準を合意し、不要なINFO/DEBUGを排除
    • CLI/サービスともにサイレントを標準、詳細はフラグ・設定で明示

3.49 UNIX思想⑫：修復の原則

  • 要旨：回復に失敗したエラーは早期に大きく失敗（fail fast & loud）させる。
  • 理由：無理な継続は被害を拡大し、原因究明も困難にするため。
  • 結論：検知した時点で処理を中断し、状況をけたたましく通知（ログ／アラート）して再発見性を高める。
  • その他（範囲・実践）：
    • 失敗点で必ずエラーを表面化（握りつぶさない）
    • ロールバック／再試行／隔離停止の方針を事前設計

ソフトウェア入出力の箴言（I/O ポステルの法則の再解釈）

  • 要旨：入力には寛容（意味をできる限り汲む）、出力は厳格（クリーンで正確）。ただし「寛容」は動作であって仕様解釈ではない。
  • 理由：相互運用性を高めつつ、仕様の足並みの乱れ（HTML史の反省）を防ぐため。
  • 結論：入力は検証・正規化して受容し、出力は規格に忠実に整形する。仕様解釈は厳密・一貫に保つ。
  • その他（実践）：
    • 入力：バリデーション＋意味推定（必要最小限）、受容不能は明示エラー
    • 出力：スキーマ/プロトコル準拠、互換性テストを自動化

3.50 UNIX思想⑬：経済性の原則

  • 要旨：最も高価な資源はプログラマの時間。環境への投資は回り回って最小コストを実現する。
  • 理由：劣悪な環境は手作業や待ち時間を増やし、生産性・品質・士気を下げるため。
  • 結論：性能の良いハード・ツール・情報アクセスに積極投資し、開発のボトルネックを除去する。
  • その他（効果）：
    • ビルド/テスト短縮、レビュー迅速化、欠陥削減、離職防止

3.51 UNIX思想⑭：生成の原則

  • 要旨：コードを生むコード（ジェネレータ／テンプレート／スキャフォールド／AI）を用いる。
  • 理由：人は細かい反復に弱く、手作業はミスと不整合の温床になるため。
  • 結論：定型は自動生成し、人は設計判断とレビューに集中する。
  • その他（範囲・実践）：
    • API/モデル定義→コード生成、設定→コード化、雛形の標準化
    • 生成物はCIで体制化（差分検知・再生成の容易化）

3.52 UNIX思想⑮：最適化の原則

  • 要旨：速さより正しさ。まず正しい実装、その後に計測に基づく最適化。
  • 理由：拙速な最適化は透明性・単純性を損ない、設計を台無しにするため。
  • 結論：必要性の証明→計測→ボトルネック修正→再計測の順で改善。削除こそ最大の最適化も忘れない。
  • その他（実践）：
    • ポリシーと実装を分離し、安定部分で最適化／不安定部分はプロトタイプで学習
    • 不要分岐や死蔵データ(持っているだけで使わない)の削除でメンテ・性能を同時に改善

3.53 UNIX思想⑯：多様性の原則

  • 要旨：「唯一の正解」はない。選択肢を持ち、文脈で選ぶ。
  • 理由：対象も要件も多様で、単一解は原理的に成立しないため。
  • 結論：原理・原則は指針に留め、断定的主張は疑い、複数案を比較検証する。
  • その他（範囲）：
    • 言語/FW/配置/プロセスの多様性を前提に意思決定を記録

3.54 UNIX思想⑰：拡張性の原則

  • 要旨：将来の拡張を前提に、後方互換を保ちつつ差し替え/追加できる設計にする。
  • 理由：初期設計が完全であることはなく、拡張点が無いと健全な進化が阻害されるため。
  • 結論：プラガブルな接続部・拡張ポイントを設け、必要箇所には「将来フック」のコメントで意図を明示する。
  • その他（実践）：
    • 拡張はインターフェース/イベント/プラグインで実現、コア改変を避ける
    • 契約（仕様）を固定し、実装を差し替え可能に

プログラミング基礎原則のまとめ③-６

3.55 UNIX哲学（全体）

  • 要旨：UNIXの長寿と実績を支える「設計の哲学」を設計指針・実装規範として活かす。
  • 理由：普遍的かつ実践的な考え方が、今なお第一線で通用する品質・進化性をもたらしてきたため。
  • 結論：以降の各原則（小さく作る・一仕事・早い試作・移植性・テキスト志向・組み合わせ活用）を日々の設計/コーディングに適用する。
  • その他（範囲）：設計・実装・運用の全工程で意思決定の拠り所にする。

3.56 UNIX哲学①：小は美なり

  • 要旨：ソフトウェアは小さく、焦点を絞って作るほど価値が高い。
  • 理由：小ささは理解容易・保守容易・軽量・組み合わせやすさを生み、過剰複雑化や将来の不測事態へ強くなるため。
  • 結論：小さく始め、小さいまま保ち、機能追加は慎重に（Less is more）。
  • その他（効果・具体）：
    • 理解が容易／保守が容易／軽い（リソース負荷が小さい）
    • 他ソフトと組み合わせやすい（柔軟）
    • 大きいコードは理解困難・デバッグ困難・不測事態に弱い

3.57 UNIX哲学②：１つ１仕事

  • 要旨：1つのソフトウェア（関数/モジュール）には1つの役割だけを担わせる。
  • 理由：焦点が定まり不要部分が排除され、本質が明確になり理解と再利用が進むため。
  • 結論：取得と整形などの関心は分離し、「文」も短く一動作に限定する。
  • その他（例・注意）：
    • 例：ディレクトリ一覧＝「取得」と「一覧整形」を分離
    • 守らないとスパゲッティ化しやすい／1文1処理を徹底

3.58 UNIX哲学③：即興プロトタイプ

  • 要旨：できるだけ早くプロトタイプを作り、試行錯誤でブラッシュアップする。
  • 理由：メカニズムは安定するがポリシーは不安定。早期可視化で誤り・不足を早く潰せるため。
  • 結論：早期プロト→短サイクルで改善→段階的リリースで最適点に収束させる。
  • その他（効果・段階）：
    • 効果：前提誤りの早期発見／要件不備の手戻り削減／初期から欠陥除去
    • 段階：①高性能だが機能不足 → ②機能過多で性能低下 → ③必要十分機能でバランス最適化

3.59 UNIX哲学④：効率性より移植性

  • 要旨：効率と移植性のトレードオフでは、移植性を優先する。
  • 理由：移植コストの低減が長期の新機能開発余力を生み、寿命全体の価値を高めるため。
  • 結論：HW依存を隔離し、再利用しやすい単位でモジュール化するアーキテクチャを選ぶ。
  • その他（実践）：抽象化・層分離・OS/CPU依存箇所の明確化。

3.60 UNIX哲学⑤：データはテキスト

  • 要旨：データ保存・ストリームはテキスト（いまならJSON等）を基本とする。
  • 理由：最もポータブルで、人が即確認でき、既存ツールで扱いやすく、デバッグにも強い。
  • 結論：バイナリ専用形式は最小限にし、標準テキスト形式を優先採用する。
  • その他（補足）：CSV/JSONなどの選択。テキストI/O前提のパイプ連携を設計に織り込む。

3.61 UNIX哲学⑥：レバレッジ・ソフトウェア

  • 要旨：単機能の良い部品を組み合わせ、他者の成果を「てこ」にして価値を増幅する。
  • 理由：「良いプログラマは良いコードを書く。偉大なプログラマは良いコードを借りてくる」――再利用で到達速度と品質を同時に高められるため。
  • 結論：巨大一体型を避け、単価値ツール＋グルー言語（スクリプト等）で構成して大きな仕事を成す。
  • その他（実践）：既存ライブラリ/CLIの連結、パイプ＆フィルタ構成、内製は「核」に集中。

3.62 UNIX哲学⑦：シェルスクリプト活用

  • 要旨：シェルスクリプトを「グルー言語」として用い、既存コマンドの力をてこにして移植性と生産性を高める。
  • 理由：コマンド群は他者の成果＝再利用資産であり、シェルは多環境で動きやすく、使われるほど効果が増幅するため。
  • 結論：小さなソフトをパイプで連結し、シェルから編成・自動化して大仕事を成し遂げる。
  • その他（実践ヒント）：
    • 標準入出力/終了コードを正しく使う（連結しやすさ向上）
    • POSIX準拠・テキストI/O前提で移植性を確保
    • 設定で振る舞いを切替（対話に頼らない）

3.63 UNIX哲学⑧：対話インターフェース回避

  • 要旨：過度な対話UIは避け、スクリプト可能なインターフェースを優先する。
  • 理由：対話は学習負荷・待ち時間・解析コード増大・連携不能・「小は美なり」違反等の問題を招くため。
  • 結論：基本は非対話（CLI/設定/ファイルI/O）。必要なら初心者向けUIと熟練者向け非対話の双方を用意する。
  • その他（問題点の内訳）：
    • 各アプリ固有操作の暗記が必要
    • ソフト同士が会話（連携）できない
    • 入力待ちで時間ロス
    • 入力解析コードが肥大・醜化

3.64 UNIX哲学⑨：フィルタ化

  • 要旨：すべてのソフトを「データを受け取り加工して出す」フィルタとして設計する。
  • 理由：人が生むデータを扱う本質は変換であり、フィルタ化は組合せ・再利用・検証を容易にするため。
  • 結論：標準入力→処理→標準出力（+標準エラー）の直列化を前提に設計する。
  • その他（設計要点）：
    • テキスト（例：JSON）を基本形式に
    • 状態を最小化し副作用を避ける（チェーンに強い）
    • 終了コードとエラー出力で健全な合図

UNIX哲学：小定理（10）

  • 要旨：設計・運用の判断を助ける小さな指針を併用し、UNIX的な実用主義を徹底する。
  • 理由：細部の選択が累積して、移植性・生産性・保守性の差になるため。
  • 結論：以下の10項をチームの共通ルールとして軽量に適用する。
  • その他（小定理一覧）：
    • ① 環境カスタマイズ：ユーザーが好みに合わせて調整できる余地を用意。
    • ② 軽薄短小カーネル：カーネルは小さく、アプリは外側で拡張。
    • ③ 小文字使用：短く小文字の命名で可読・入力性を向上。
    • ④ 森林保護：紙に依存せず、操作可能なデジタル文書を活用。
    • ⑤ 沈黙は金：無意味な出力を避け、重要情報だけを表示。
    • ⑥ 並列思考：仕事を分割し並行実行でスループットを上げる。
    • ⑦ 商品コラボレーション：小さな部品の総和で大を超える価値を。
    • ⑧ 90パーセント解：最後の10%に固執せず現実的最適点を狙う。
    • ⑨ 劣るが優る：最小公約数の実利が長生きする（UI至上主義に偏らない）。
    • ⑩ 階層指向：自然に倣い階層構造で整理・理解を容易に。

プログラミング基礎原則のまとめ④

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 コードの臭い（Code Smells）

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

4.6 技術的負債（Technical Debt）

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

プログラミング基礎原則のまとめ⑤

5.1 プログラマの三大美徳（怠惰・憤怒・傲慢）

  • 要旨：怠惰・憤怒・傲慢を、手戻りや手作業を減らし品質を上げるための実践的な美徳として活用する。
  • 理由：反復や非効率への反発が、自動化・並列化・プロ意識を促し、全体コストを下げスループットと品質を高めるため。
  • 結論：仕組みで楽をし、コンピュータに働かせ、誇りを持って恥じないコードを作る。頭脳労働の無理なハードワークは避ける。
  • その他（詳細）：
    • 怠惰：全体の労力を減らすために手間を惜しまない気質。
      • 繰り返し作業をマクロ化・生成・ツール化して自動化／仕組み化。
    • 憤怒：コンピュータがサボることに怒る気質＝コンピュータを効率よく使う姿勢。
      • 仕事を小さく分割し同時実行、計算資源を最大活用してスループット向上。
    • 傲慢：高いプライドで美しいコードと設計を追求する気質。
      • プロ意識を持ち、人に見せて恥ずかしくない成果物を作る。
    • 注意：一生懸命さや外圧では思考速度は上がらない→長時間労働に頼らず仕組みで解決。

5.2 ボーイスカウトの法則

  • 要旨：触れたコードは来た時より少しだけきれいにして戻す。
  • 理由：コードは常に洗練され続けるべきで、最終的な真実はソースに宿るため、小さな改善の蓄積が品質を底上げする。
  • 結論：プル前よりよくしてコミットすることを習慣化する。
  • その他（指針）：
    • 急がば回れ：
      • ユニットテスト省略は避ける：わずかな変更でも手動テストが増え、後の変更が困難に。
      • 不適合な既存システムの流用は避ける：目的不一致の無理は破綻につながる。
      • 不適切なライブラリの放置は避ける：複雑化と保守困難を招き、いずれ破綻する。
    • 小さな改善例：命名改善／重複削減／関数抽出／コメント整備／テスト追加。
    • 効果：保守性と信頼性の向上、回帰リスクの低減、チームの学習促進。

5.3 パフォーマンスチューニングの箴言

  • 要旨：時期尚早な最適化は害になりやすい。まずは良いコード（局所化・情報隠蔽）を作り、必要時のみ計測に基づいて最適化する。
  • 理由：最適化にはトレードオフがあり、性能の代わりに大切な性質を失うことが多いから。
  • 結論：測って→直し→また測るの循環で、ボトルネックを特定、改善を行う。良い設計を先に整えれば、後からのチューニングは安全に局所適用できる。
  • その他（範囲・手順・手段）：
    • 最適化の弊害：
      • 可読性の低下：最適化後は前より読みにくくなる。
      • 品質の低下：読みにくさは欠陥増につながる。
      • 複雑性の増大：結合度が上がり移植性も損なう。
      • 保守の阻害：前提条件が増え汎用性・拡張性が下がる。
      • 環境間の競合：特定環境では速いが他で遅くなる。
      • 作業量の増大：結局仕事を増やしがち。
    • まずは良いコード：情報隠蔽などの原則に沿って変更の局所化を実現→他へ影響なく後から変更可能。
    • コード以外の改善点：
      • 実行環境
      • デプロイ/インストール設定
      • ミドルウェア
      • ライブラリ
      • 相互運用しているシステム
      • アーキテクチャ
    • 鉄則（手順）：
      • ① 必要性を証明（ユーザー指摘やSLO逸脱など）。
      • ② 計測してボトルネック特定（「推測するな、計測せよ」）。
      • ③ ボトルネックを最適化（局所修正）。
      • ④ 再計測して効果を確認。
      • ⑤ テストで機能回帰がないか検証。
    • 手段：プロファイラを利用（例：Chrome のネットワーク/パフォーマンスタブ）。

5.4 エゴレスプログラミング

  • 要旨：エゴを手放し、助言・指摘を歓迎して学ぶ。人ではなくコードを批評する。
  • 理由：防衛的態度は必要な改善を妨げ、品質を下げるため。
  • 結論：「十戒」を念頭に、謙虚さと尊重をもって継続的に改善する（ただし個性を殺さないバランスも大切）。
  • その他（十戒）：
    • 自分も間違えることを受け入れる。
    • 書いたコードは自分ではないと理解する。
    • 上には上がいることを受け入れる。
    • 相談なしの全面書き直しをしない。
    • 自分よりスキルが劣る人にも敬意と忍耐を。
    • 唯一変わらないのは変化という事実。
    • 本当の権威は地位ではなく知識から。
    • 信念のために戦う。ただし敗北は潔く受け入れる。
    • 部屋にこもりきりにならない。
    • 人に優しく、コードに厳しく（人ではなくコードを批評）。

5.5 １歩ずつ少しずつ

  • 要旨：小さな作業を1つずつ行い、確認→次へのサイクルを繰り返す（ステップ・バイ・ステップ）。
  • 理由：小さく確実な前進の積み重ねは、結果として品質と時間効率を高めるため。
  • 結論：実装も思考も段階を刻んで進める。論理ステップを構築し、各ステップを速く確実に。
  • その他（思考のコツ）：
    • 瞬時に答えを得ようとしない。分からなくても考え続ける。
    • すぐに結論へ飛びつかない。一度否定し他の可能性を検討。
    • 既に考えたことを覚える（思考ループに陥らない）。
    • 書きながら考える（視覚化で理解が進む）。
    • 直感も活用してまず試す。ただし直感のみで決めない。

5.6 TMTOWDI（There's more than one way to do it.）

  • 要旨：目的達成の手段は1つではない。選択肢を用意する。
  • 理由：対象も要件も多様であり、解法も多様だから。
  • 結論：与えられた指示を鵜呑みにせず、別のやり方やより楽な方法がないかを常に検討する。
  • その他（指針・効果）：
    • 制約・評価基準（性能/可読性/保守性/コスト）を明確化し、複数案を比較。
    • プロトタイピングやスパイクでリスクと学習を前倒し。
    • 結果として、より適切で持続可能な解を選択できる。

プログラミング基礎原則のまとめ⑥

6.1 曳光弾（Tracer Bullet Development）

  • 要旨：優先的に検証したい部分を先行実装し、簡易でも実環境で動くエンドツーエンドの骨格を通す。
  • 理由：動く最小構成を早期に用意すると、学習・調整・検証のサイクルが加速するため。
  • 結論：まず土台（骨格）を作り曳光弾として通す→以後は肉付けしながら目標とのズレを継続チェックし、必要に応じて軌道修正する。
  • その他（メリット・比較）：
    • メリット：
      • ユーザーフィードバックを早期に獲得（ジョハリの窓的にユーザーの盲点を可視化）。
      • プログラマの舞台を早期整備（エンドツーエンドが見えると全員が生産的に）。
      • デバッグ/テストの早期・正確化（単体完了→即統合、影響範囲の限定）。
      • 常時デモ可能なソフトウェアを確保。
      • 進捗の見える化（ユースケース単位で報告が容易）。
    • プロトタイプとの違い：
      • プロトタイプ：理解を検証するための試作。使い捨てが前提（得た知見で作り直す）。
      • 曳光弾：本物の最小コードで全体連携を示し、以後も使い続ける骨格を提供。

6.2 契約による設計（Design by Contract）

  • 要旨：「呼び出し側」と「呼び出される側」が契約（前提条件・事後条件）を取り決め、それに即して実装する。
  • 理由：契約を明確にし遵守することで、正しさ保証（過不足なし）・コードの単純化・早期発見/早めのクラッシュが可能になるため。
  • 結論：関数仕様はコメントで明示し、アサーションで契約履行をチェック（呼び出し前：前提条件／終了時：事後条件）。
  • その他（指針・注意・拡張・運用）：
    • 指針：
      • 前提条件を満たしてから呼び出す（入力検証は呼び出し側）。
      • 関数側は引数の調整を行わない（契約違反は即検出）。
      • 想定は厳格に / 確約は寛容に（受け口を増やし過ぎず、返却条件は過度に縛らない）。
    • オブジェクト指向の拡張：
      • クラス不変表明：常に成り立つ条件を保証する契約を併用。
    • アサーション運用：
      • 開発/保守専用。エンドユーザー向けメッセージではない→リリース版には含めない。
    • エラーハンドリング方針：
      • ありえない事態は早めにクラッシュし、処理を中断してけたたましく通知（被害拡大を防ぐ）。

6.3 防御的プログラミング（Defensive Programming）

  • 要旨：「だろう」ではなく「かもしれない」で考え、入力と境界を徹底的に守る。
  • 理由：不正値・想定外入力を早期に検出し対処することで、開発中のデバッグ効率と、運用中の安全性/セキュリティを高められるため。
  • 結論：バリケード戦略で汚染の侵入を防ぎ、エラー処理ポリシーを場面に応じて選択（正当性/堅牢性の優先度を明確化）。
  • その他（観点・戦略・手当）：
    • 観点：
      • 外部入力の確認（ファイル/ユーザー/ネットワーク）…許容範囲チェックとサニタイズで「想定内エラー」を検出・処理。
      • 関数引数の確認…想定外はバグ。アサーションで検出し必要なら停止（「想定外エラー」）。
    • バリケード戦略：
      • ダーティルーム（外部からの入口）→バリケード（検証/消毒）→クリーンルーム（内部モジュール）の三層で役割分担。
    • 想定内エラーの処理例：
      • 無害な値を返す（数値0/空文字/NULL）。
      • 次のデータで代用（無効レコードはスキップ）。
      • 前回値を返す（センサー読み取り失敗時など）。
      • 近い有効値に丸める（0～100の範囲外を端で代用）。
      • ログ記録のみで継続（軽微な場合）。
      • エラーを返す（状態/戻り値/例外で上位へ委譲）。
      • 共通エラー処理に委譲（集中管理、ログは露出させない）。
      • メッセージ表示（必要最小限、認証系は詳細非表示）。
      • 処理を中止（誤処理継続より停止が安全な場合）。
      • 各所で最適な方法を選択（ただし全体の一貫性に注意）。
    • 正当性 と 堅牢性：
      • 安全最優先（例：医療）は正当性＞堅牢性（誤結果により停止）。
      • ユーザー体験最優先（例：文書）は堅牢性＞正当性（落とさない）。
    • 「言語の中へ」：
      • 言語に機能がなくても、ライブラリ/マクロ等で契約や防御の考えを取り込み、表明可能な形で実装する。
    • セキュリティ補足：
      • エラー処理の不備はセキュリティホールになりやすい。入力検証・例外処理・ログ露出に注意。

6.4 ドッグフーディング（Dogfooding）

  • 要旨：自分で作ったソフトウェアを自分でユーザーとして使う。
  • 理由：開発者は無意識に障害を避けた操作（正常系偏重）をしがちで、別視点（ユーザー視点）でのみ見つかる不具合があるため。
  • 結論：ユーザーになり切って使用し、見え方の違い（ジョハリの窓）を意識してギャップを埋める。
  • その他（効果・実践）：
    • 効果：潜在バグの早期発見／本当に必要な体験価値の把握／優先順位の明確化。
    • 実践：実環境・実データ・実端末での操作／正常系だけでなく異常系・境界値の操作も行う。

6.5 ラバーダッキング（Rubber Duck Debugging）

  • 要旨：問題を誰か（ラバーダックでも可）に説明することで頭が整理され、自己発見で解決に近づく手法。
  • 理由：説明の過程で状況を理路整然と再構成するため、矛盾点や「説明できない箇所」に気づきやすい。
  • 結論：行き詰まり時は声に出して順序立てて説明する。相手は人でも物でもよい（重要なのは説明行為）。
  • その他（コツ）：
    • 再現手順→期待値→現状→差分→仮説の順に話す。
    • コード断片を読み上げ、意図と実装のズレを都度確認する。
    • 説明しながら最小再現を縮めていく。

6.6 コンテキスト（Context）

  • 要旨：周囲の状況・背景（文脈）を設計・実装・コミュニケーションに組み込み、判断の質を高める。
  • 理由：コンテキストを考慮すると、断片情報が結びつき、迷子にならずに正しい解へ到達しやすい。
  • 結論：コンテキストをモデル化して共有（例：ドメインモデル）、思考法（システムシンキング等）で掘り下げ、チームでハイコンテキストを醸成する。
  • その他（活用・例・指針）：
    • コードの読み書きに利用：
      • 「階層原理」（セクション／章／段落／文）と「驚き最小の原則」で文脈を構成。
    • 思考のツールとして利用：
      • 物事は相互依存。背景を含めて考えることで問題を正確に解く。
    • コンテキストと依頼作業：
      • 達人には「目的」だけで十分／初心者には詳細指示が必要→経験が文脈を補う。
    • コンテキストの伝達能力：
      • 言葉（コンテンツ）は文脈とセットで意味を持つ（例：トイレに行ったこどもの「お母さん！」の声＝紙が欲しい）。
    • チームはハイコンテキスト志向で：
      • 共有文脈が増えるとオーバーヘッド減・品質向上。
      • 新メンバーには自明も言語化（5W1H、順序立てた説明）。
    • コード共通化はコンテキスト志向で：
      • 役割が異なる類似処理は安易に共通化しない（別変更が必要になりがち）。
      • 共通化は依存を増やす→全体構造と文脈を見極めて判断。
    • プログラマのコンテキストスイッチ：
      • フロー状態は中断に弱い→職場文化として中断を最小化（集中時間を尊重）。
    • 「システムシンキング」とドメイン駆動設計：
      • 全体を統一的に捉える思考を、ドメインモデル中心の開発（DDD）で具現化。
      • 専門家と共にモデルを反復深化し、言語・図・コードをモデルと一体化。
    • フロネシスと全体最適化：
      • 実践的な智慧（フロネシス）で文脈を捉え、ユーザー価値へ全体最適の判断を下す。
    • 「関係主義」と障害対応：
      • コードだけでなく、ライブラリ・環境・相互作用を含む関係性に原因を探る。

プログラミング基礎原則のまとめ⑦

7.1 ブルックスの法則

  • 要旨：炎上プロジェクトへの人員の逐次投入は、むしろさらなる遅延を招く（人月は可換ではない）。
  • 理由：
    • 依存関係によるオーバーヘッド：分割に伴う調整・確認・コミュニケーション経路の増加で遅くなる。
    • 教育コスト：新規メンバーの学習に既存メンバーの時間が割かれ、総合生産性が低下。
    • 人≠人の非交換性：能力差、領域知識、ハイコンテキスト未醸成などで置き換えが効かない。
  • 結論：遅延の解消を人員投入で図らない。早期にリスケし、優先順位付け→段階的リリースへ舵を切る。
  • その他（アンチパターン）：
    • アンチパターン＝陥りやすい罠の定義集。反面教師/転ばぬ先の杖として活用し、同じ失敗を避ける。

7.2 コンウェイの法則

  • 要旨：アーキテクチャは組織を反映する。情報伝達の構造がそのまま設計に現れやすい。
  • 理由：組織構造に沿ってコミュニケーションが形成され、その経路で設計判断が行われるため、自然放置で組織＝設計になる。
  • 結論：まず望ましいアーキテクチャを描き、組織をそれに従属させる（チーム境界＝プロダクト境界に合わせる）。
  • その他（組織×プロセスの相性）：
    • 技術縦割り組織（DB/メインフレーム/Web/テスト等）でアジャイルを行うと依存が過多になり、結局ウォーターフォール化しがち。
    • 機能横断（クロスファンクショナル）な編成で、ユースケース単位の完結を目指す。

7.3 割れた窓ガラスの法則

  • 要旨：小さな乱れ（悪い設計/意思決定/コード）の放置が、全体の腐敗を加速させる。
  • 理由：「割れた窓」があると、「他もガラクタだから適当に…」という心理が忍び込み、風紀が崩れ、劣化が連鎖するため。
  • 結論：発見即修復。時間がなければタグ付きコメントで可視化し、可能なときに速やかに直す。できれば来た時より美しく（ボーイスカウトの法則）。
  • その他（運用のコツ）：
    • 小さな改善を継続（命名の是正、重複排除、関数抽出、テスト追加）。
    • 放置しない文化を醸成し、品質の負債化を未然に防ぐ。

7.4 エントロピーの法則

  • 要旨：コードは放置すると無秩序（腐敗）へ向かう。エントロピー増大を前提とし、兆候を早期に捉えて対処する。
  • 理由：人が作る以上、時間と変更で秩序は崩れやすく、無秩序は加速度的に拡大するため。
  • 結論：腐敗の兆候を監視し、小さく継続的なリファクタリングとテストで秩序を回復・維持する（アジャイル的に設計を常にシンプル＆可変に）。
  • その他（兆候・対策）：
    • 腐敗の兆候（見逃さない）：
      • 硬さ：小変更でも依存連鎖で広範囲修正（高結合）。
      • 脆さ：一部の変更で無関係箇所が壊れる。
      • 移植性のなさ：環境依存が強く切り離せない。
      • 扱いにくさ：設計が硬直/開発環境が遅く非効率。
      • 複雑さ：不要要素の増殖（YAGNI違反）。
      • 繰り返し：重複コードの散在（DRY違反）。
      • 不透明さ：読み手にとって分かりにくい。
    • アジャイルで腐敗を許さない：初期設計に固執せず、シンプル維持＋頻繁なユニット/受け入れテストで柔軟性を保つ。
    • チーム文化で腐敗を止める：場当たり修正を放置しない（割れた窓の即修復）。率先リファクタリングを推奨。

7.5 80-10-10の法則

  • 要旨：要求の80％は短時間で実現、残り10％は大きな努力を要し、最後の10％は実現不能になりがち。
  • 理由：万能な単一ツールで全要求を満たす発想は、対象の広さに対して現実的でないため（銀の弾丸はない）。
  • 結論：100％充足に固執せず、優先度・適用分野を絞る。必要に応じてツール/ライブラリを導入して効率化する。
  • その他（パレートの法則／ホットスポット活用）：
    • パレートの法則（例）：
      • 売上の8割は2割の商品。
      • 交通量の8割は2割の道路。
      • 所得の8割は2割の富裕層。
      • 機能利用時間の8割は2割の機能に集中。
    • ソフトウェアへの適用：
      • 障害の8割は2割のコード（品質ホットスポット）。
      • 処理時間の8割は2割のコード（性能ホットスポット）。
      • → 計測でホットスポット特定、重点レビュー/テスト/チューニングを集中実施。

7.6 ジョシュアツリーの法則

  • 要旨：名前を知ると見えてくる。逆に名づけなければ見えない。
  • 理由：概念に名前が付くと認知・共有・再利用が可能になる（デザインパターンの最大成果は命名にあり）。
  • 結論：物事に名前を与え、チームで共有語彙（ユビキタス言語）を育てる。
  • その他（実践・効果）：
    • 実践：
      • ドメイン概念に一貫した用語を付与し、コード/設計/会話/文書で統一。
      • レビューで命名の整合を確認、用語集を更新。
      • 新しい発見に対しても積極的に名づけ、チームに展開。
    • 効果：見えなかった問題が可視化され、意思疎通と設計の質が向上。学習・再利用が加速。

7.7 セカンドシステム症候群

  • 要旨：v1の作者がv2を作ると多機能・低品質・使い勝手悪化に陥りやすい。
  • 理由：v1で保留した機能や新機能を盛り込みたくなる欲求、見た目を変えて「進化」を示したい衝動が働くため。
  • 結論：自制し「多機能主義」を回避。次の問いでユーザー中心へ立ち返る。
    • ユーザーは誰か？
    • ユーザーは何をするのか？
    • ユーザーは何を必要としているのか？
    • ユーザーは何が必要だと考えるのか？
    • ユーザーは何を望んでいるのか？（多くは基本機能の安定と使い勝手改善）
  • その他（フィーチャークリープ対策）：
    • 定義：要望を無秩序に導入し機能過多に陥ること＝破滅の第一歩。
    • 方針：NOと言える勇気。どうしても入れる場合は
      • 本体をラップ/拡張で対応（アドオン、設定、外部統合）。
      • プラグインでコア非改変の拡張を許す。
      • コアはシンプルさを死守（KISS・YAGNI）。

7.8 車輪の再発明

  • 要旨：既存ライブラリで足りるのに同等機能を自作してしまうこと（多くは既存の方が高品質）。
  • 理由：
    • 車輪を知らない（情報・学習不足）。
    • 車輪を作りたい（確信犯的な自己実装＝エゴ）。
  • 結論：着手前に標準ライブラリ/OSSを必ず調査し、チームへ相談。本来やるべき作業に注力する。
  • その他（再発明が妥当な場合）：
    • ビジネス目的：
      • プロダクトの核/差別化領域は自作し、依存リスクを回避。
      • サプライヤ問題に備えコントロールを確保。
    • 学習目的：
      • ゼロから設計/実装/テスト/不具合修正まで経験し、知見と技能を獲得。

7.9 ヤクの毛刈り（Yak Shaving）

  • 要旨：本来の課題に着手したはずが、連鎖する前提タスクに追われ、目的から逸脱してしまう現象。
  • 理由：問題は芋づる式に現れ、依存の連鎖が解決資源を消費するため。
  • 結論：毛刈りだと気づいたら立ち止まり、目的を再確認。別ルート検討・他者に相談・情報共有で時間ロスを抑止。
  • その他（例・対策）：
    • 典型例：
      • WebサーバーDL→容量大→DLツール導入→動かない→前提モジュール→ユーザー登録→登録ページ不具合→ブラウザ更新→…本来目的を見失う。
    • 対策：
      • 目的・制約・タイムボックスを明文化し逸脱を検知。
      • 詰まったら相談/エスカレーション。
      • 経過をメモして思考ループ/脳内オーバーフローを防ぐ。
      • 再発防止のため、手順化/ナレッジ共有。
TOPへ

もちもちみかん.comとは


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

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