UNIXという考え方

2020-09-25 読了

Mike Gancarz

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

  • 目的は最小限のものに抑える

    • それを組み合わせる
  • 気づいたら、色々なことに注意をして、巨大のプログラムをつくってしまっている。
  • 巨大で複雑なプログラムは「将来が予測可能で、そして現在とそうおおきかわらない」と思ってる。

    • 小さなプログラムの開発者は未来の予測などは最初から諦めてる

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

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

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

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

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

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

定理 4 効率より移植性

  • 今ままで、効率より移植性の高いものが生き残ってきた。
  • 高い移植性を持ちながら、同時に最適な性能をだすには、高度の技術的な洗練が必要とする。

    • 消して、非効率な時代遅れのソフトウェアを作るわけではない。
  • プログラムを早くすることには時間をかけない。

    • 将来新しいハードウェアが解決する

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

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

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

  • 独自技術症候群を避ける

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

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

OSS の世界がまさにそう。

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

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

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

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

  • 人間と対話を想定しているから、ソフトウェアの梃子の効果を利用できなくなる。

    • 他のプログラムと結合しにくい
    • pipe が使えない

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

data input -> data output

その他

沈黙は金

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

90%の解を目指す

心臓の移植手術ではないから、100%目指すより、90%を目指すほうが遥かに楽。

2019 © Kazushi Kawamura.