プリンシプル オブ プログラミング
https://gyazo.com/373bb4cb1c55db9299b2d2c2c3dd41ef
第１章 前提 ～プログラミングの変わらぬ真実～
プリンシプルとは、プログラミングの指針となる「前提」「原則」「思想」「習慣」「視点」「手法」「法則」
ソフトウェアの本質には、その困難性を示す4つの性質があります。それは「複雑性」「同調性」「可変性」「不可視性」です。
ソフトウェアの本質は複雑性との戦いがほとんどである
複雑さとの戦いの歴史
偶有は偶然発生したという意味ではなく副次的、付随的という意味
ビルド環境、プログラミング言語、ライブラリ、フレームワークなどが偶有的
設計行為の成果物であるコード自体も設計書であると言える
また、「基本設計」「詳細設計」「プログラミング」「テスト」「デバッグ」は、不可分なひとかたまりのタスクです。どの作業も、お互い依存しあっています。基本設計だけ行っても、プログラミングまで行わないとわからないことが数多くあります。結局、一通りプログラミングが終わらないと上位の設計書が確定しないということは、それが1つのボックスである、ということを意味しています。
そうだよな。。。
結局設計書をFIXさせてからコード書くみたいなのはやっぱりアカンのである
第２章 原則 ～プログラミングのガイドライン～
コードが非常にきれいで、しっかりと構造化されていても、テストがなければレガシーコードです。
ただし、コードはどこまで行っても「What」と「How」、つまり「何をしているか」「どのようにやっているか」までしか表現できません。「Why」、つまり「なぜそれをしているか」を表現するには、コメントを使用する必要があります。
ソースコードにはWhyは残せないのでそれはコメントをつけること
第３章 思想 ～プログラミングのイデオロギー～
「単一責任の原則（SRP: the Single Responsibility Principle）」とは、モジュールを変更する理由は、1つより多く存在してはならないという原則です。 ポリシーと実装の分離
ポリシーモジュール
ソフトウェアの前提に依存するもの
ビジネスロジックやその他モジュールに対する引数の選択を行う部分など
実装モジュール
ソフトウェアに依存しないもの
独立したロジック部分
この2つは1つのモジュールで両方を扱ってはいけない
実装モジュールは純粋なモジュールのため再利用が可能
ポリシーモジュールはドメインに紐づくためあまり再利用できない
再利用のリスク
採用されている使用実績は全く当てにならないということ
流用元コードがたくさんのその他のコードと相互作用を行う文脈である
コード上の避けられない複雑さの部分は、データ側に寄せるようにしましょう。データ構造を複雑にするか、ロジックを複雑にするかを選ばなければならなくなったら、迷わずデータ構造が複雑になる方を選んでください。コードを改善していく時も、コードの複雑さをデータの複雑さに切り替えていくことを検討しましょう。
モジュールから値を取得する関数「 get」があるとします。その値を取得する方法がリモートからだった場合、「 get」という名前を使用すべきではありません。値を取得する、という意味では、誤りではありませんが、「 get」は、今モジュールにある値をそのまま取得するというイメージがあります。リモートから取得するなら、まったく別の関数「 fetch」を用意した方が、驚きが少なくなります。
第４章 視点 ～プログラマの観る角度～
結合度も重要
なるべく低結合なモジュールを目指す
データの受け渡しをできるだけ引数で行う
置き場所についてはグローバル変数に置かない
渡す値に応じて変わるようなコードを書かない
コードは独立させる
レイヤー化すること
コードの臭い（Bad smell in code）
コードの中で理解しにくい、拡張しにくいと感じる部分のこと
ボーイスカウトの規則
自分のいた場所はそこを出ていくとききた時よりもきれいにしなけえばならない
これに基づきコードも一度修正する箇所をそのままきれいにリファクタリングする方法
第５章 習慣 ～プログラマのルーティーン～
エゴなんて捨てろ！
コードを見せる側も優れているとかそういった自尊心は捨てること「より良いものを作る」ということに価値を置くこと
第６章 手法 ～プログラマの道具箱～
プロトタイプは、ソフトウェアのコンセプトや最終形態についての「理解を検証する」ためのものです。 これ勘違いされやすいよね。いつも
曳光弾は、ソフトウェア全体がどのように連携するのかを明らかにします。そうして、プログラマに対して、今後も使い続けるアーキテクチャ上の骨格を提供し、ユーザーに対して、どのような使い勝手になるのかを提示します。 説明しながらデバッグしていくこと
説明しながらやっていくと問題に気づくことがある
第７章 法則 ～プログラミングのアンチパターン～
プロジェクトの工数は、人月換算されます。「何人が、何ヶ月従事するか」なので、「人×月」のかけ算になります。 ここで重要なのは、単純数値のかけ算とは異なり、「人」と「月」は交換不可能である、という事実です。つまり、「人×月＝月×人」という式は成り立ちません。 例えば、12人月のプロジェクトで、「6ヶ月で開発してくれ」と言われたら、2名の人員を投入すればよいことになります。ここで、「人」と「月」とが交換可能ならば、「急ぐので、2ヶ月で開発してくれ」と言われても、6人投入すればよいことになります。 しかし、現実には、「6×2」と「2×6」は、同じにはなりません。2人で仕事をする能率と、6人で仕事をする能率は、大きく異なります。
ここ読み返したいわね