本書におけるプリンシプル（原理/原則）とは

1. 前提 - プログラミングの真実 -
2. 原則 - プログラミングのガイドライン -
3. 思想 - プログラミングのイデオロギー -
4. 視点 - プログラマの観る角度 -
5. 習慣 - プログラマのルーティーン -
6. 手法 - プログラマの道具箱 -
7. 法則 - プログラミングのアンチパターン -

https://www.shuwasystem.co.jp/book/9784798046143.html

1. 前提 - プログラミングの真実 -

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

• ソフトウェアは本質的に困難である
  • 複雑性
    • ソフトウェア構成要素間の依存関係も、規模が大きくなるほど非線形に増大する
  • 同調性
    • ソフトウェアは、実世界に同調し続けなければならないため困難は避けられない
  • 可変性
    • 計画通りにソフトウェアができても、それを使ったユーザーの要求は日々変化していく
  • 不可視性
    • ソフトウェアは、概念の集積であり、それらは目に見えない

1. 前提 - プログラミングの真実 -

コードは設計書である

• コードこそが設計書
  • 設計書等はあるものの、最終的なアウトプットは、コードなのでコードこそが設計書だとも言える
  • プログラミングは設計行為である

1. 前提 - プログラミングの真実 -

コードは必ず変更される

• コードは修正されるもの
• 変更に強いコードを書く

2. 原則 - プログラミングのガイドライン -

KISS(Keep It Simple Stupid)

• コードをシンプルに保つ

DRY(Don't Repeat Yourself.)

• コードの改善がしづらくなる
  • 重複する箇所が多いので、変更に漏れ等が発生する
• コードを抽象化する

YAGNI(You Aren't Going to Need It.)

• コードは必要最低限
• コードが「今」必要なものだけ

PIE(Program Intently and Expressively.)

• コードの意図を伝える
• コードが読みやすさが最優先
• コメントは「書く」（なぜそれをしているのか）
• 文芸的プログラミング（コードそのものをドキュメンテーションにするという考え）

SLAP(Single Level of Abstraction Princple)

• コードの抽象レベルを合わせる
• 順序も上から抽象から具体に流れるようにする

OCP(Open-Closed Principle)

名前重要

• 名前はコードを読む人への「UI」
• 命名規則を明確にする

3. 思想 - プログラミングのイデオロギー -

プログラミングセオリー

セオリーを支える3つも価値

• コミュニケーション
  • コードも「文書（ドキュメント）」である
  • コードを読む側の視点に立つ
• シンプル
  • コードの複雑性を排除する
• 柔軟性
  • コードの変更が容易である
  • コードの拡張性を上げる

セオリーを実現する6つの原則

• 結果の局所化
  • 変更の影響を抑える
  • 関係が濃密なコードをまとめる
• 繰り返しの最小化
  • 重複を排除する
  • コードを分割して管理する
• ロジックとデータの一体化
  • データと操作を同じ場所に置く
• 対称性
  • コードに一貫性を持たせる
  • グルーピングする
• 宣言型の表現
  • 宣言型を取り入れる

https://zenn.dev/wooootack/scraps/18f19f9c549bf4

• 変更頻度
  • 変更理由でグルーピングする
  • 単一責任の原則的に扱える

3. 思想 - プログラミングのイデオロギー -

アーキテクチャ根底技法

良いコードの基礎原則

• 抽象
  • 一般化 → 抽象化する
• カプセル化
  • 関連のあるデータとロジックをグルーピングする
  • 関連の深いデータと関数を1箇所にまとめる
• 情報隠蔽
  • シンプルな情報のみを公開し、内部機能等は隠蔽する（モジュール化）
  • 外部からの直接アクセスを遮断する
• パッケージ化
  • ソフトウェア全体が、パッケージという小さい単位に分割されるので、複雑度が下がる
  • 依存関係が整理されるので、パッケージを単位とした再利用をしやすくなる
• 関心の分離
  • 関心単位でモジュール化を行う
  • アスペクト指向プログラミング

• 充足性、完全性、プリミティブ性
  • 充足性：モジュールが表現しようとしている抽象が、それを伝えるために十分であるかどうか
  • 完全性：モジュールが表現しようとしている抽象が、全ての特徴を備えているか
  • プリミティブ性：モジュールが表現しようとしている抽象が、全て純粋かどうか

• ポリシーと実装の分離
  • ポリシーモジュール：ソフトウェアの前提に依存するもの、ビジネスロジックや、その他のモジュールに対する引数の選択を行う部分
  • 実装モジュール：そのソフトウェアの前提に依存しないもの、独立したロジック部分
• インターフェースと実装の分離
  • 「インターフェース」パート：モジュールが持つ機能を定義し、モジュールの使用方法を定める部分
  • 「実装」パート：モジュールが持つ機能を実現しているコード部分
• 参照の一点性
  • 「単一代入」しないこと（後から書き換えを行わない）
  • 参照透明性
    • 呼び出しの結果が、引数のみに依存する
    • 呼び出しが、他の機能の動作に影響を与えない
• 分割統治
  • 大きな問題を小さく割る

3. 思想 - プログラミングのイデオロギー -

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

• 変更容易性
  • 文字通り、コードを容易に変更する能力

  以下のような前提があるとよりしやすい。

• 相互運用性
  • ソフトウェア同士の標準規格を選択する
• 効率性
  • 時間効率性：レスポンスタイム等の時間という観点のリソース
  • 資源効率性：CPU使用率、メモリ使用率等のコンピュータ資源という観点のリソース
• 信頼性

• テスト容易性
  • TDDを実装時に意識してみる
• 再利用性
  • 「プラグイン」アーキテクチャ：モジュール化、コンポーネント化してそれらを読み込みような形。疎結合に設計できる。依存関係を分散できる。

https://gihyo.jp/book/2016/978-4-7741-8361-9