脳に収まるコードの書き方
dak23章
フレデリック・ブルックスによる分析
ソフトウェア製品開発に関する古典的問題の多くは、その本質的な複雑性と、ソフトウェアの大きさに従ってその複雑性が非線形に増大することに由来している。複雑性ゆえにプログラムのすべての状態を理解することはおろか、列挙することも難しくなる。
コードを追加することは複雑さを増大させるという側面もあるのは分かる
結局コード書かずに目的を達成できる方が良い
複雑性も下がるし運用コストも増えない
dak25章
ポステルの法則
「貴方が自分ですることに関しては厳密に、貴方が他人から受けることに関しては寛容に」(be conservative in what you do, be liberal in what you accept from others)というものである。これは「送信するものに関しては厳密に、受信するものに関しては寛容に」(be conservative in what you send, be liberal in what you accept)
カプセル化は隠蔽することではなく、オブジェクトが無効な状態にならない保証をすること
オブジェクトと呼び出し側のやり取りは契約に従わなければならない
事前条件は呼び出し側の責任、事後条件は呼び出されたオブジェクトによって与えられる保証
呼び出し側に求めることが少ないほど、呼び出し側はオブジェクトとのやりとりが簡単になる。
=> わかる、引数の数とか、複雑なオブジェクトを引数に取っていたりとか
良い保証ができればできるほど、呼び出し側は防御的なコードを書く必要性がなくなる
=> イミュータブルだと気にしなくてよくなるよね
この文書を見ていると、Smalltalk のメッセージ・パッシングのオブジェクト指向の話を思い出した
dak27章
後でかく
サイクロマティック複雑度(循環的複雑度)
ソフトウェア測定法の一つであり、コードがどれぐらい複雑であるかの指標
大まかに if文、for文、while文などの分岐 + 1で算出できる
dak28章
API によってカプセル化されたコードとやりとりする関係に対してアフォーダンスという用語を用いる
IReservationsRepository のようなインターフェースは、「特定の日付の予約の読み出しや新規予約の登録をアフォードします」
アフォーダンスという捉え方はなかったが確かに
つまり、それを見たら何ができるのか想起できる状態
厳密な型付けを持つコンパイル言語であれば型システムを用いてアフォーダンスを知らせることができる
型システムによって特定の型付けをしないといけないのが分かる
アフォーダンス
ギブソンの提唱した本来の意味でのアフォーダンスとは、動物と物の間に存在する行為についての関係性をあらわす言葉である。例えば人物Aとドアについて、Aにはそのドアを開けるという選択肢がある。この選択肢が存在するという関係を「このドアには ”開ける” というアフォーダンスがある」あるいは「このドアは ”開ける” という行為をアフォードしている」と表現する。
dak210章
ストラングラーパターンを使って、既存のコードを壊さずに処理を追加したり修正して徐々に移行するのはよくあるよなと
負債を消していく工数が残る可能性はあるので、できれば既存コードの修正を行えると良いのだろうなとは思うが、価値提供スピードを考えるとストラングラーパターンが良いというのはそう
dak212章
メソッドはクエリのように見えるのに辿ると副作用がある
コマンドクエリの原則に反している
結構あるよなーそういうふうに書いているコード
変更容易性がなくなるから避けていきたいよね