プリンシプルオブプログラミングのバックアップ(No.2)

バックアップ一覧
差分を表示
現在との差分を表示
ソースを表示
プリンシプルオブプログラミングへ行く。
- 1 (2017-05-27 (土) 09:25:01)
- 2 (2017-05-27 (土) 11:58:23)
- 3 (2017-05-27 (土) 15:06:30)

書籍「プリンシプルオブプログラミング」の書いてある内容を思い出すためのメモ書き

原則 †

KISS（Keep It Simple, Stupid または Keep It Short and Simple）
DRY（Don't Repeat Yourself）
- One Fact in One Place
- Once and Only Once
YAGNI（You Aren't Going to Need It）
PIE（Program Intently and Expressively）
SLAP（Single Level of Abstraction Principle）
OCP（Open-Closed Principle）
名前重要

↑

思想 †

プログラミングセオリー
- 3つの価値と6つの原則に支えられる

↑

3つの価値 †

コミュニケーション ... コードを読んだ人が、コードを理解し、コードを修正し、コードを使用することができる
シンプル ... コードの複雑性を排除する
柔軟性 ... コードの変更が容易である

↑

6つの原則 †

結果の局所化 ... 変更の影響を抑える => 修正と確認が容易になる <= 関係が濃密なコードをまとめる
繰り返しの最小化 ... 重複を排除する => 修正の影響を局所化する <= コードを分割して管理
ロジックとデータの一体化 ... データとその操作は近くに => データと操作は修正タイミングが同じ <= データと操作を同じ場所に
対称性 ... コードに一貫性を持たせる => 他の部分も類推できる <= 同じことは同じ表現で
宣言型の表現 ... 宣言型でプログラミング => フローがないと読みやすい <= 宣言型を取り入れる
変更頻度 ... 変更理由でグルーピング => 変更範囲が狭くなる <= 変更理由で所属を決める

↑

アーキテクチャ根底技法 †

良いコードには以下の技法が使われている

抽象 ... 概念的な「線引き」=> 複雑さへの対抗手段 <= 「捨像」と「一般化」を駆使
カプセル化 ... データとロジックをグルーピング => 抽象概念が混ざらない <= 仲間の要素をカプセルに込める
情報隠蔽 ... 必要にないものは見せない => 関連を整理してシンプルに <= 内側は隠蔽する
パッケージ化 ... モジュールをグルーピング’ => モジュール群の複雑度を下げる <= ボトムアップでパッケージを設計
関心の分離 ... 関心ごとにコードを分離 => 関心単位で変更が行えるように <= 関心単位でモジュール化
充足性、完全性、プリミティブ性 ... 表現が十分かつ完璧かつ純粋 => 表現している抽象を正確に伝える <= モジュールの抽象を隙なく表現
- 充足性 ... モジュールが表現しようとしている抽象が、それを伝えるために十分であるか
- 完全性 ... モジュールが表現しようとしている抽象が、全ての特徴を備えているか
- プリミティブ性 ... モジュールが表現しようとしている抽象が、全て純粋であるかどうか
ポリシーと実装の分離 ... 「ポリシー」と「実装」は混ぜない <= 「実装」は安定だが「ポリシー」は不安定 => 「ポリシー」と「実装」は別モジュール
インタフェースと実装の分離 ... 構成は「インタフェース」と「実装」から <= 使用者はインタフェースだけ知ればよい => インタフェースを用いて設計する
参照の一点性 ... 定義は一度きり => 副作用のないプログラミング <= 「単一代入」とする
分割統治 ... 大きな問題を小さく割る <= 大きなままでは制御不能 => 小さくして各個撃破

↑

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

「機能以外の機能」の観点 <= 非機能はリリース後に影響大 => 非機能観点で設計

ソフトウェアが高品質であり、ユーザの役に立つためには、機能だけでなく「非機能」的な要件を満たさなければならない
非機能的な特性は、開発や保守、運用、コンピュータリソースの効率活用に大きな影響を及ぼす
リリース後の運用の「大きな」トラブルのほとんどが、パフォーマンスやシステムダウンなど、非機能的な特性に起因している

非機能要件の観点は以下の6つ

変更容易性 ... コードを容易に変更する能力 <= ソフトウェアの寿命は存外長い <= 保守性、拡張性、再構築、移植性
- 保守性 ... 障害が発生したコードの修正のしやすさ <= 変更の局所化、他のモジュールへの副作用を最小にするアーキテクチャの採用
- 拡張性 ... 新しい機能の追加、モジュールの新しいバージョンへの置き換え、不要な機能やモジュールの除去などのしやすさ <= モジュール間が疎結合
- 再構築 ... モジュール間の関係の再組織化 <= モジュールの配置が柔軟にできること
- 移植性 ... 様々なハードウェア、OS、プログラミング言語などに適合させる際のやりやすさ

相互運用性 ... 他のソフトウェアと会話する能力 <= ソフトウェアは連携する => 標準規格を選択する

効率性 ... リソースをうまく使う能力 <= リソースは限られている => リソースを適切に利用
- 時間効率性 ... スループット、レスポンスタイム、ターンアラウンドタイムなどで評価
- 資源効率性 ... CPU使用時間、メモリ使用量、ストレージ消費量、ネットワーク伝送量などで評価

信頼性 ... 機能を維持する能力 => 求められる機能維持レベルは様々 => 冗長化、フェールソフト、フェールセーフ、フールプルーフ
- フォールトトレランス ... ソフトウェアに障害が発生したときに、正常な動作を保ち続ける能力
- ロバストネス ... 不正な使用方法や入力ミスからソフトウェアを保護する能力

テスト容易性 ... 「効果的」かつ「効率的」ににテストする能力 <= テストの品質が本体の品質 => テストも考慮した本体設計

再利用性 ... 再利用「する」「される」能力 => できるだけ「作らない」で開発効率化 <= 「プラグイン」アーキテクチャ
- 再利用の「3の法則」
  - 難易度3倍の法則 ... 再利用可能なモジュールを作るのは、単一のソフトウェアで使うモジュールを開発する場合に比べて3倍難しい
  - テスト3種類の法則 ... 再利用可能なモジュールは、共有化する前に、3つの異なるソフトウェアでテストする必要がある

↑