プリンシプル オブ プログラミング
をテンプレートにして作成
[
トップ
] [
新規
|
一覧
|
単語検索
|
最終更新
|
ヘルプ
|
ログイン
]
開始行:
書籍「プリンシプル オブ プログラミング」の書いてある内容...
*原則 [#e3bc7a7c]
-KISS（Keep It Simple, Stupid または Keep It Short and Si...
-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）
-名前重要
*思想 [#i733017b]
-プログラミングセオリー
--3つの価値と6つの原則に支えられる
**3つの価値 [#y5caf4ff]
--コミュニケーション ... コードを読んだ人が、コードを理解...
--シンプル ... コードの複雑性を排除する
--柔軟性 ... コードの変更が容易である
**6つの原則 [#b3d122e0]
--結果の局所化 ... 変更の影響を抑える => 修正と確認が容易...
--繰り返しの最小化 ... 重複を排除する => 修正の影響を局所...
--ロジックとデータの一体化 ... データとその操作は近くに =...
--対称性 ... コードに一貫性を持たせる => 他の部分も類推で...
--宣言型の表現 ... 宣言型でプログラミング => フローがない...
--変更頻度 ... 変更理由でグルーピング => 変更範囲が狭くな...
**アーキテクチャ根底技法 [#y06a6c84]
-良いコードには以下の技法が使われている
-抽象 ... 概念的な「線引き」=> 複雑さへの対抗手段 <= 「捨...
-カプセル化 ... データとロジックをグルーピング => 抽象概...
-情報隠蔽 ... 必要にないものは見せない => 関連を整理して...
-パッケージ化 ... モジュールをグルーピング’ => モジュール...
-関心の分離 ... 関心ごとにコードを分離 => 関心単位で変更...
-充足性、完全性、プリミティブ性 ... 表現が十分かつ完璧か...
--充足性 ... モジュールが表現しようとしている抽象が、それ...
--完全性 ... モジュールが表現しようとしている抽象が、全て...
--プリミティブ性 ... モジュールが表現しようとしている抽象...
-ポリシーと実装の分離 ... 「ポリシー」と「実装」は混ぜな...
-インタフェースと実装の分離 ... 構成は「インタフェース」...
-参照の一点性 ... 定義は一度きり => 副作用のないプログラ...
-分割統治 ... 大きな問題を小さく割る <= 大きなままでは制...
**アーキテクチャ非機能要件 [#k910c408]
-「機能以外の機能」の観点 <= 非機能はリリース後に影響大 =...
-ソフトウェアが高品質であり、ユーザの役に立つためには、機...
-非機能的な特性は、開発や保守、運用、コンピュータリソース...
-リリース後の運用の「大きな」トラブルのほとんどが、パフォ...
-非機能要件の観点は以下の6つ
-変更容易性 ... コードを容易に変更する能力 <= ソフトウェ...
--保守性 ... 障害が発生したコードの修正のしやすさ <= 変更...
--拡張性 ... 新しい機能の追加、モジュールの新しいバージョ...
--再構築 ... モジュール間の関係の再組織化 <= モジュールの...
--移植性 ... 様々なハードウェア、OS、プログラミング言語な...
-相互運用性 ... 他のソフトウェアと会話する能力 <= ソフト...
-効率性 ... リソースをうまく使う能力 <= リソースは限られ...
--時間効率性 ... スループット、レスポンスタイム、ターンア...
--資源効率性 ... CPU使用時間、メモリ使用量、ストレージ消...
-信頼性 ... 機能を維持する能力 => 求められる機能維持レベ...
--フォールトトレランス ... ソフトウェアに障害が発生したと...
--ロバストネス ... 不正な使用方法や入力ミスからソフトウェ...
-テスト容易性 ... 「効果的」かつ「効率的」ににテストする...
-再利用性 ... 再利用「する」「される」能力 => できるだけ...
--再利用の「3の法則」
---難易度3倍の法則 ... 再利用可能なモジュールを作るのは、...
---テスト3種類の法則 ... 再利用可能なモジュールは、共有化...
**7つの設計原理 [#f35cf12a]
-コード妥当性レビュー観点 => コード価値観が「漏れない」「...
-単純原理 ... シンプルにこだわる <= 複雑なところにバグが...
-同型原理 ... 同じことは同じように扱う <= 「異物’」は目立...
-対象原理 ... 形の対称性にこだわる <= 読むときに予測が付...
-階層原理 ... 階層にこだわる <= 階層構造は読みやすい => ...
-線形原理 ... 処理の流れは直線にこだわる <= 一直線の処理...
-明証原理 ... ロジックの明証性にこだわる <= 不確実性を取...
-安全原理 ... 安全性にこだわる <= 大事故への発展を防ぐ =>...
**UNIX思想 [#t37c09ca]
-UNIXの底流にある暗黙知 <= UNIXの設計判断の正しさ => UNIX...
-モジュール化の原則 ... 控えめなモジュールを作る <= モジ...
-明確性の原則 ... コードを明確にする <= コードを読むのは...
-組立部品の原則 ... フィルタにして組み立てる <= 相互接続...
-分離の原則 ... メカニズムからポリシーを離す <= メカニズ...
--メカニズム ... X Window System など、エンジン的な役割を...
--ポリシー ... ビジネスロジックやユーザインタフェース
-単純性の原則 ... コードはシンプルにする <= コードは自然...
-倹約の原則 ... 大きなコードは書かない <= 大きなコードは...
-透明性の原則 ... ソフトウェア動作の「見える化」<= デバッ...
--透明性 ... ソフトウェアの動作について、一目見てすぐに「...
--開示性 ... ソフトウェアの内部状態について、監視ないし表...
-安定性の原則 ... ソフトウェアを安定させる <= ソフトウェ...
--透明性 ... コードを見通すことができて、何が起きているの...
--単純性 ... コードで行われていることが複雑でなく、全ての...
-表現性の原則 ... 情報はデータに寄せて表現 <= データはロ...
-驚き最小の原則 ... 予想通りのインタフェース <= 学習コス...
-沈黙の原則 ... ソフトウェアは寡黙であれ => 大事なことが...
-修復の原則 ... 修復失敗時は処理停止 <= エラー時の継続実...
-経済性の原則 ... プログラマの時間を大切に <= プログラマ...
-生成の原則 ... 「コードを書く」コードを書く <= 生成コー...
-最適化の原則 ... 速いコードより正しいコード <= 早い段階...
-多様性の原則 ... 選択の多様性を受容する <= 人の想像力に...
-拡張性の原則 ... 拡張できる設計にしておく <= ソフトウェ...
**UNIX哲学 [#n4e60f85]
-UNIXを支え続けている哲学 <= UNIXの哲学は普遍である => UN...
-小は美なり ... 小さいソフトウェアは美しい <= 小さいソフ...
-1つ1仕事 ... 1つのソフトウェアは1つの仕事 => ソフトウェ...
-即行プロトタイプ ... できるだけ早くプロトタイプ着手 <= ...
-効率性より移植性 ... 効率性より移植性を優先 <= ソフトウ...
-データはテキスト ... バイナリよりテキストファイル <= テ...
-レバレッジ・ソフトウェア ... ソフトウェアの梃子で力増幅 ...
-シェルスクリプト活用 ... シェルスクリプトで接着する <= ...
-対話インタフェース ... 対話的ユーザインタフェースは避け...
-フィルタ化 ... ソフトウェアはフィルタとして設計 <= ソフ...
*視点 [#g4d0f8bd]
-凝集度 ... モジュールは「純粋」に <= 雑じり気のあるモジ...
--Lv.1：暗号的強度 ... モジュール内の要素間に特別の関係が...
--Lv.2：論理的強度 ... ある機能を抽象的に捉えてまとめたもの
--Lv.3：時間的強度 ... 特定の時点（時間）に連続して実行す...
--Lv.4：手順的強度 ... 問題を処理するために関係している複...
--Lv.5：連絡的強度 ... 手順的強度の特性を持ちつつ、モジュ...
--Lv.6：情報的強度 ... 特定のデータ構造を扱う複数の機能を...
--Lv.7：機能的強度 ... モジュール内の全ての命令が1つの役...
-結合度 ... モジュール間は「疎遠」に <= 相互依存モジュー...
--Lv.1：内容結合 ... あるモジュールと他のモジュールが一部...
--Lv.2：共通結合 ... 共通域に定義したデータを、いくつかの...
--Lv.3：外部結合 ... 外部宣言したデータを共有したモジュー...
--Lv.4：制御結合 ... 呼び出し側のモジュールが、呼び出され...
--Lv.5：スタンプ結合 ... 共通域にないデータ構造を、2つの...
--Lv.6：データ結合 ... モジュール間のインタフェースとして...
--べき等性 ... ある操作を何回行っても結果が同じこと
--安全性 ... 操作対象の状態を変化させないこと
-直交性 ... コードは独立させよ <= 直交コードは堅牢 => コ...
-可逆性 ... 「UNDO」可能な選択をせよ <= 最終決定などない ...
-コードの臭い ... コードの凶兆を見逃すな <= 臭覚はリファ...
-技術的負債 ... 問題コードは「借金」である <= 問題コード...
*習慣 [#q993126e]
-プログラマの3大美徳 ... プログラマは「怠慢」「短気」「傲...
--怠慢 ... 全体の労力を減らすために手間を惜しまない気質
--短気 ... コンピュータが効率的に処理していない、意図通り...
--傲慢 ... 高いプライドを持ち、人様に対して恥ずかしくない...
-ボーイスカウトの法則 ... コードを掃除して帰る <= コード...
-パフォーマンスチューニング’ ... 「速い」コードより「よい...
-エゴレスプログラミング ... エゴを捨てよ <= エゴレスで品...
--自分自身も間違いを犯すということを理解し、受け入れます
--書いたコードは自分自身ではありません
--どれほど極めたと思っていても、上には上がいます
--相談なしにコードを書き直しません
--自分よりもスキルが劣る人にも、尊敬と敬意と忍耐を持って...
--世界で唯一変わらないことは、変わるということだけです
--本当の権威は、地位ではなく、知識から生じます
--信じるもののために戦います。ただし、負けは潔く受け入れ...
--部屋に篭りきりはいけません
--「人に優しく、コードに厳しく」して、人ではなくコードを...
-1歩ずつ少しずつ ... ステップ・バイ・ステップ <= 「手堅い...
-TMTOWTDI（There's more than one way to do it.）... ツー...
*手法 [#t738aff1]
-曳光弾 ... 最終形にも残る「骨格コード」<= 暗闇の中で道筋...
-契約による設計 ... 「呼び出し側」と「呼び出される側」の...
-防御的プログラミング’ ...「かもしれない」プログラミング ...
-ドッグフィーディング ... ソフトウェアの「味見」<= ユーザ...
-ラバーダッギング ...「説明する」というデバッグ <= 自己解...
-コンテキスト ...「文脈会話」「文脈思考」<= 会話や思考を...
*法則 [#s3a34021]
-ブルックスの法則 ... 要員追加は「火に油」<=「人」と「月...
-コンウェイの法則 ... アーキテクチャは組織に従う <= アー...
-割れた窓の法則 ... 悪いコードは「蟻の一穴」<= 悪いコード...
-エントロピーの法則 ... コードは自然と腐っていく <= コー...
-80-10-10の法則 ... プログラミングに万能薬はない <= プロ...
-ジョシュアツリーの法則 ... 名前がないものは見えない <= ...
-セカンドシステム症候群 ... 2番目のリリースは機能過多 <= ...
-車輪の再発明 ... 既にあるのに作る <=「車輪を知らない」「...
-ヤクの毛狩り ... 本当の問題にたどり着かない <= トラブル...
終了行:
書籍「プリンシプル オブ プログラミング」の書いてある内容...
*原則 [#e3bc7a7c]
-KISS（Keep It Simple, Stupid または Keep It Short and Si...
-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）
-名前重要
*思想 [#i733017b]
-プログラミングセオリー
--3つの価値と6つの原則に支えられる
**3つの価値 [#y5caf4ff]
--コミュニケーション ... コードを読んだ人が、コードを理解...
--シンプル ... コードの複雑性を排除する
--柔軟性 ... コードの変更が容易である
**6つの原則 [#b3d122e0]
--結果の局所化 ... 変更の影響を抑える => 修正と確認が容易...
--繰り返しの最小化 ... 重複を排除する => 修正の影響を局所...
--ロジックとデータの一体化 ... データとその操作は近くに =...
--対称性 ... コードに一貫性を持たせる => 他の部分も類推で...
--宣言型の表現 ... 宣言型でプログラミング => フローがない...
--変更頻度 ... 変更理由でグルーピング => 変更範囲が狭くな...
**アーキテクチャ根底技法 [#y06a6c84]
-良いコードには以下の技法が使われている
-抽象 ... 概念的な「線引き」=> 複雑さへの対抗手段 <= 「捨...
-カプセル化 ... データとロジックをグルーピング => 抽象概...
-情報隠蔽 ... 必要にないものは見せない => 関連を整理して...
-パッケージ化 ... モジュールをグルーピング’ => モジュール...
-関心の分離 ... 関心ごとにコードを分離 => 関心単位で変更...
-充足性、完全性、プリミティブ性 ... 表現が十分かつ完璧か...
--充足性 ... モジュールが表現しようとしている抽象が、それ...
--完全性 ... モジュールが表現しようとしている抽象が、全て...
--プリミティブ性 ... モジュールが表現しようとしている抽象...
-ポリシーと実装の分離 ... 「ポリシー」と「実装」は混ぜな...
-インタフェースと実装の分離 ... 構成は「インタフェース」...
-参照の一点性 ... 定義は一度きり => 副作用のないプログラ...
-分割統治 ... 大きな問題を小さく割る <= 大きなままでは制...
**アーキテクチャ非機能要件 [#k910c408]
-「機能以外の機能」の観点 <= 非機能はリリース後に影響大 =...
-ソフトウェアが高品質であり、ユーザの役に立つためには、機...
-非機能的な特性は、開発や保守、運用、コンピュータリソース...
-リリース後の運用の「大きな」トラブルのほとんどが、パフォ...
-非機能要件の観点は以下の6つ
-変更容易性 ... コードを容易に変更する能力 <= ソフトウェ...
--保守性 ... 障害が発生したコードの修正のしやすさ <= 変更...
--拡張性 ... 新しい機能の追加、モジュールの新しいバージョ...
--再構築 ... モジュール間の関係の再組織化 <= モジュールの...
--移植性 ... 様々なハードウェア、OS、プログラミング言語な...
-相互運用性 ... 他のソフトウェアと会話する能力 <= ソフト...
-効率性 ... リソースをうまく使う能力 <= リソースは限られ...
--時間効率性 ... スループット、レスポンスタイム、ターンア...
--資源効率性 ... CPU使用時間、メモリ使用量、ストレージ消...
-信頼性 ... 機能を維持する能力 => 求められる機能維持レベ...
--フォールトトレランス ... ソフトウェアに障害が発生したと...
--ロバストネス ... 不正な使用方法や入力ミスからソフトウェ...
-テスト容易性 ... 「効果的」かつ「効率的」ににテストする...
-再利用性 ... 再利用「する」「される」能力 => できるだけ...
--再利用の「3の法則」
---難易度3倍の法則 ... 再利用可能なモジュールを作るのは、...
---テスト3種類の法則 ... 再利用可能なモジュールは、共有化...
**7つの設計原理 [#f35cf12a]
-コード妥当性レビュー観点 => コード価値観が「漏れない」「...
-単純原理 ... シンプルにこだわる <= 複雑なところにバグが...
-同型原理 ... 同じことは同じように扱う <= 「異物’」は目立...
-対象原理 ... 形の対称性にこだわる <= 読むときに予測が付...
-階層原理 ... 階層にこだわる <= 階層構造は読みやすい => ...
-線形原理 ... 処理の流れは直線にこだわる <= 一直線の処理...
-明証原理 ... ロジックの明証性にこだわる <= 不確実性を取...
-安全原理 ... 安全性にこだわる <= 大事故への発展を防ぐ =>...
**UNIX思想 [#t37c09ca]
-UNIXの底流にある暗黙知 <= UNIXの設計判断の正しさ => UNIX...
-モジュール化の原則 ... 控えめなモジュールを作る <= モジ...
-明確性の原則 ... コードを明確にする <= コードを読むのは...
-組立部品の原則 ... フィルタにして組み立てる <= 相互接続...
-分離の原則 ... メカニズムからポリシーを離す <= メカニズ...
--メカニズム ... X Window System など、エンジン的な役割を...
--ポリシー ... ビジネスロジックやユーザインタフェース
-単純性の原則 ... コードはシンプルにする <= コードは自然...
-倹約の原則 ... 大きなコードは書かない <= 大きなコードは...
-透明性の原則 ... ソフトウェア動作の「見える化」<= デバッ...
--透明性 ... ソフトウェアの動作について、一目見てすぐに「...
--開示性 ... ソフトウェアの内部状態について、監視ないし表...
-安定性の原則 ... ソフトウェアを安定させる <= ソフトウェ...
--透明性 ... コードを見通すことができて、何が起きているの...
--単純性 ... コードで行われていることが複雑でなく、全ての...
-表現性の原則 ... 情報はデータに寄せて表現 <= データはロ...
-驚き最小の原則 ... 予想通りのインタフェース <= 学習コス...
-沈黙の原則 ... ソフトウェアは寡黙であれ => 大事なことが...
-修復の原則 ... 修復失敗時は処理停止 <= エラー時の継続実...
-経済性の原則 ... プログラマの時間を大切に <= プログラマ...
-生成の原則 ... 「コードを書く」コードを書く <= 生成コー...
-最適化の原則 ... 速いコードより正しいコード <= 早い段階...
-多様性の原則 ... 選択の多様性を受容する <= 人の想像力に...
-拡張性の原則 ... 拡張できる設計にしておく <= ソフトウェ...
**UNIX哲学 [#n4e60f85]
-UNIXを支え続けている哲学 <= UNIXの哲学は普遍である => UN...
-小は美なり ... 小さいソフトウェアは美しい <= 小さいソフ...
-1つ1仕事 ... 1つのソフトウェアは1つの仕事 => ソフトウェ...
-即行プロトタイプ ... できるだけ早くプロトタイプ着手 <= ...
-効率性より移植性 ... 効率性より移植性を優先 <= ソフトウ...
-データはテキスト ... バイナリよりテキストファイル <= テ...
-レバレッジ・ソフトウェア ... ソフトウェアの梃子で力増幅 ...
-シェルスクリプト活用 ... シェルスクリプトで接着する <= ...
-対話インタフェース ... 対話的ユーザインタフェースは避け...
-フィルタ化 ... ソフトウェアはフィルタとして設計 <= ソフ...
*視点 [#g4d0f8bd]
-凝集度 ... モジュールは「純粋」に <= 雑じり気のあるモジ...
--Lv.1：暗号的強度 ... モジュール内の要素間に特別の関係が...
--Lv.2：論理的強度 ... ある機能を抽象的に捉えてまとめたもの
--Lv.3：時間的強度 ... 特定の時点（時間）に連続して実行す...
--Lv.4：手順的強度 ... 問題を処理するために関係している複...
--Lv.5：連絡的強度 ... 手順的強度の特性を持ちつつ、モジュ...
--Lv.6：情報的強度 ... 特定のデータ構造を扱う複数の機能を...
--Lv.7：機能的強度 ... モジュール内の全ての命令が1つの役...
-結合度 ... モジュール間は「疎遠」に <= 相互依存モジュー...
--Lv.1：内容結合 ... あるモジュールと他のモジュールが一部...
--Lv.2：共通結合 ... 共通域に定義したデータを、いくつかの...
--Lv.3：外部結合 ... 外部宣言したデータを共有したモジュー...
--Lv.4：制御結合 ... 呼び出し側のモジュールが、呼び出され...
--Lv.5：スタンプ結合 ... 共通域にないデータ構造を、2つの...
--Lv.6：データ結合 ... モジュール間のインタフェースとして...
--べき等性 ... ある操作を何回行っても結果が同じこと
--安全性 ... 操作対象の状態を変化させないこと
-直交性 ... コードは独立させよ <= 直交コードは堅牢 => コ...
-可逆性 ... 「UNDO」可能な選択をせよ <= 最終決定などない ...
-コードの臭い ... コードの凶兆を見逃すな <= 臭覚はリファ...
-技術的負債 ... 問題コードは「借金」である <= 問題コード...
*習慣 [#q993126e]
-プログラマの3大美徳 ... プログラマは「怠慢」「短気」「傲...
--怠慢 ... 全体の労力を減らすために手間を惜しまない気質
--短気 ... コンピュータが効率的に処理していない、意図通り...
--傲慢 ... 高いプライドを持ち、人様に対して恥ずかしくない...
-ボーイスカウトの法則 ... コードを掃除して帰る <= コード...
-パフォーマンスチューニング’ ... 「速い」コードより「よい...
-エゴレスプログラミング ... エゴを捨てよ <= エゴレスで品...
--自分自身も間違いを犯すということを理解し、受け入れます
--書いたコードは自分自身ではありません
--どれほど極めたと思っていても、上には上がいます
--相談なしにコードを書き直しません
--自分よりもスキルが劣る人にも、尊敬と敬意と忍耐を持って...
--世界で唯一変わらないことは、変わるということだけです
--本当の権威は、地位ではなく、知識から生じます
--信じるもののために戦います。ただし、負けは潔く受け入れ...
--部屋に篭りきりはいけません
--「人に優しく、コードに厳しく」して、人ではなくコードを...
-1歩ずつ少しずつ ... ステップ・バイ・ステップ <= 「手堅い...
-TMTOWTDI（There's more than one way to do it.）... ツー...
*手法 [#t738aff1]
-曳光弾 ... 最終形にも残る「骨格コード」<= 暗闇の中で道筋...
-契約による設計 ... 「呼び出し側」と「呼び出される側」の...
-防御的プログラミング’ ...「かもしれない」プログラミング ...
-ドッグフィーディング ... ソフトウェアの「味見」<= ユーザ...
-ラバーダッギング ...「説明する」というデバッグ <= 自己解...
-コンテキスト ...「文脈会話」「文脈思考」<= 会話や思考を...
*法則 [#s3a34021]
-ブルックスの法則 ... 要員追加は「火に油」<=「人」と「月...
-コンウェイの法則 ... アーキテクチャは組織に従う <= アー...
-割れた窓の法則 ... 悪いコードは「蟻の一穴」<= 悪いコード...
-エントロピーの法則 ... コードは自然と腐っていく <= コー...
-80-10-10の法則 ... プログラミングに万能薬はない <= プロ...
-ジョシュアツリーの法則 ... 名前がないものは見えない <= ...
-セカンドシステム症候群 ... 2番目のリリースは機能過多 <= ...
-車輪の再発明 ... 既にあるのに作る <=「車輪を知らない」「...
-ヤクの毛狩り ... 本当の問題にたどり着かない <= トラブル...
ページ名:
![[PukiWiki]](image/pukiwiki.png "[PukiWiki]")
