https://www.amazon.co.jp/dp/4894712873/
- 前書きで胸が震えた
プログラムは１冊の書籍のように書かれるべきだ。プロットとリズム、そして小気味よいフレーズの展開がなければならない ― ドナルド・クヌース
ディレクトリの名称を環境変数から取得しているプログラムを見たことがある。一体なぜ、そんな複雑なことになっているのか。柔軟性のためだ。プログラムは柔軟であるべきだが、それはプログラムがその方向に変更される場合だけだ。
実装ではなくインターフェースに対してコードを作成せよ
同じ接頭辞を共有する変数がいくつも存在することがあれば、何らかのヘルパーオブジェクトが役立つかもしれない。
メソッドすべての呼び出しにおいて、リテラル定数が渡されるインターフェースであれば、定数値ごとにメソッドを分けたほうが改善になるはずだ
名前は入力される回数の何倍も読まれるので、入力の容易さよりも、読みやすさのほうを優先すべきだ
生存期間やスコープ、型などの変数に関するその他の重要なことは、たいていコンテキストによって伝えられる
遅延初期化が伝えるのは、「ここではパフォーマンスが重要です」ということだ
対称性のように「美学的」要求を満たすため「だけ」にメソッドを追加するのは愚かに感じるときもある。しかし美学はもっと深いものだ。（中略）コードから受ける美学的な印象は、コードの品質に関する貴重なフィードバックとなるはずだ
ソフトウェア開発においては、意図と実装の区別がつねに重要となってきた
まず関係がある部分とない部分を把握し、次にどのように分割するのが最善かを判断するのに、時間と労力と独創性が必要である
推測ではなく事実に基づいて、メソッドは組み立てよう。コードを動作させてから、どのような構造であるべきかを決定しよう
クライアントが必要とするプロトコルをすべてオブジェクトに持たせるように最善を尽くすことが、そのような乱用を防ぐための最善の方針である
toString() のこと
間もなく、人はきまりの悪い事実に気づいた。プログラムは実行のためと同じくらい、変更のために書かれていることを。
「思いつく限りの柔軟性をすべて盛り込め」、あるいは「今日のためにコードを作成し、明日のことは忘れろ」という教条的な忠告は、どちらも同じくらい間違っている