UNIXという考え方

定理 1 スモール・イズ・ビューティフル

• 目的は最小限のものに抑える
  • それを組み合わせる
• 気づいたら、色々なことに注意をして、巨大のプログラムをつくってしまっている。
• 巨大で複雑なプログラムは「将来が予測可能で、そして現在とそうおおきかわらない」と思ってる。
  • 小さなプログラムの開発者は未来の予測などは最初から諦めてる

定理 2 一つのプログラムには一つのことをうまくやらせる

• ユーザーの対話は本当に必要なのか？
• 他のプログラムで似たような機能を持ったものはないのか

定理 3 できるだけ早く試作を作成する

ソフトウェア開発には終わりはない。あるのはリリースだけだ。

誰もが常に学び続けている。すべてを知り尽くしたと勝手に思い込んでいても、誰かが我々への要求仕様を変えてしまうのだ。

試作をつくって学ぶ。要件定義とかに時間を使っても、変更されるので、なるべく早く試作品を作る。１回ではうまく行かない。

定理 4 効率より移植性

• 今ままで、効率より移植性の高いものが生き残ってきた。
• 高い移植性を持ちながら、同時に最適な性能をだすには、高度の技術的な洗練が必要とする。
  • 消して、非効率な時代遅れのソフトウェアを作るわけではない。
• プログラムを早くすることには時間をかけない。
  • 将来新しいハードウェアが解決する

定理 5 数値データは ASCII フラットファイルに保存する

• データにも移植性をもたせることが大事。移動できないデータに関しては価値がない。
• UNIX では、ほとんどの管理者情報が ASCII フラットファイルに補完されている。バイナリと比べたら、効率が悪いが、次の年のマシンで克服できる。
• UNIX テキストツールも使える

定理 6 ソフトウェアの梃子を有効に活用する

• 独自技術症候群を避ける
  • 市販品を買うより、ゼロからの開発を好む
  • もっとも成功する会社は、他のソフトウェアをかりて、独自拡張を行う。付加価値をつける。

良いプログラマは良いコードをかく。偉大なプログラマはよいコードを借りてくる。

OSS の世界がまさにそう。

定理 7 シェルスクリプトを使うことで梃子の効果と移植性を高める

• 移植性が優れていていれば、人がつくったプログラムを利用できて、複利的なパワーが発揮する。

私は人生で 2 度しか奇跡を見たことはない。一つは核融合、もうひとつは複利だ。

定理 8 過度の対話型インターフェースを避ける

• 人間と対話を想定しているから、ソフトウェアの梃子の効果を利用できなくなる。
  • 他のプログラムと結合しにくい
  • pipe が使えない

定理 9 すべてのプログラムをフィルタにする

data input -> data output

その他

沈黙は金

たしかにlsとかは、なにもディレクトリが存在しないときに、何も表示しない。これになれてるが、UI 的には、なにかメッセージが表示されたほうが親切なんじゃないかなとは思ったが、移植性を考えると、沈黙が最適な解。

90%の解を目指す

心臓の移植手術ではないから、１００％目指すより、９０％を目指すほうが遥かに楽。