スモール・イズ・ビューティフル小さなプログラムはシステムリソースにやさしいわずかなメモリしか占有せず、OSもメモリを割り当てやすくなるメモリをあまり必要としない一方で、CPUパワーを追加投入すると効果が得られる。他のツールと組み合わせやすい「あらゆる不足の事態に対応できるように」という誤った考えのもと、大きなプログラムを書きがち。将来現れる新しい形式は予測できず、時代遅れになってしまうことも。UNIXでは未来の予測は初めから諦めてる。短い機能仕様書を書くソフトウェアを書くテストして書き直す。過渡の対話的インターフェースを避ける対話的なインターフェースは他のコマンドを実行できなくなるという観点で、「拘束的」なため良くない。すべてのプログラムをフィルタとして設計するソフトウェアの本質は、データを処理することで、生成することではない。その能力を最大限に発揮するには、プログラムをフィルタとして動作するように設計すべきだ。伝統的な立ち位置で、UNIXプログラマが賛同する程度のレベル感のもの。好みに応じて自分で環境を調整できるようにするOSのカーネルを小さく軽くするアプリケーションの効率性を図り、コアな部分にOSに関係のないコードを交えてファットなものにしてしまうと、バグが発生した際にOS全体に影響が及んでしまう小文字を使い、短く森林を守る紙のドキュメントを嫌う。沈黙は金パイプを利用するためにも、無駄な出力は避けるべき並行して考える小さく分解した仕事を同時に実行することで、効率化を図る。部分の総和は全体よりも大きい小さい部品を集めて大きなアプリケーションを作るほうが、大規模プログラムを単体で構成するよりも柔軟性に富み、したがってより役に立つ。先のことを考えても、小さい部品の集合によるアプローチの方が有利だ。90%の解を目指す100%を目指すよりも、90%を目指す方が効率的で、費用対効果が高い。劣るほうが優れてる生き残るのは「最大公約数」的なシステム。階層的に考えるオブジェクト指向開発などにも影響を与えた。当然だが、アプリケーション開発に適用できるところも多かった。小さくモジュール化していくところなどは、オブジェクト指向と似ている。「90%の解を目指す」のコスト感覚も、サービス開発と同じだと思った。移植性は普段は全く気にかけることがなかったので、気付きが多かった。「人間による3つのシステム」は、ブロックチェーン界隈のコミュニティを見ていて通ずるものがあると思った。2001年に出版されたこともあって、やや古く感じるところも多少あった。シェルスクリプトみたいな構図フィルタとして設計している部分や、対話的なインターフェースを避けているところは美しいと思った。過度なところもあるようにも感じたが、単純性を一貫させてるが故にこれだけ長年に渡ってスケーラビリティを持って存在しているのだと思う。」を読んだ「ベゾス・レター:アマゾンに学ぶ14ヵ条の成長原則」を読んだ月別アーカイブはてなブログをはじめよう!hacking15dogさんは、はてなブログを使っています。ブログを報告するスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。