プログラミングの技法

Not

アーキテクチャではない

Worse Is Better

ダメなソフトウェアの言い訳ではない

設計の複雑さとインターフェースの複雑さのトレードオフ

設計の正しさ/美しさと実装の単純さが両立できないときは、実装の単純さを選択したほうが、それが漏れのある抽象になったとしても現実の問題を解決し、実装の単純さによって開発参加のハードルが下がり、進化的な強さを獲得できる

MIT/Stanfordアプローチ

コードがいくら複雑になろうとも正しいことをせよ

NewJerseyアプローチ

ユーザの負担が増えたとしても、コードを単純に保て

無理に抽象化しないほうがうまくいく

Worse is betterはキャッチー過ぎる

Simplicity、Correctness、Consistency、Completenessの中でどれを一番に優先するか

データは引力を持っている

データはコードを引きつけるのでコードが集まってくる

コードがあるので更にデータも集まってくる

書き味より読み味

書くのは1回だが、読むのは無限回だし、人の数も圧倒的に違うので優先すべきは読み味

自分一人しか読まないし絶対触らないなら書き味でもよさそう

ポエム

関数を呼び出すときに、その関数の中を見なければ使い方がわからない、というのはよろしくない

単純に難しいときもある

そのときはコメントをよく書くと良い

引数に内部の動作を変更するためのフラグがあり、それが中身を見ないとよくわからない、というのはよくない

fopen関数のフラグのようなのはどうなのかと考えてみると、あれは悪くない気がする

フラグを使わずに、fopen_rwとか関数を増やすよりは簡素

これは内部の動作を変えるのではなく、返り値で受け取るオブジェクトの設定なので、フラグとは違う気がしてきた