orangain flavor

じっくりコトコト煮込んだみかん2。知らないことを知りたい。

UNIXという考え方を読んだ

もともとUNIXの考え方は理解しているつもりでしたが、ちゃんと言語化されているものを読んだことがなかったので読んでみました。新しい発見があった箇所や非常に頷ける箇所をピックアップします。

UNIXという考え方―その設計思想と哲学

UNIXという考え方―その設計思想と哲学

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

あらゆる試作の目的は、「第三のシステム」に早く到達することだ。

  • 第一のシステム:数人で作られ、尖っていて小さく軽い
  • 第二のシステム:委員会方式で作られ、多機能で大きくて重い
  • 第三のシステム:専門家に作られ、コンセプトは常識となり、正しく作られる

早く第三のシステムに到達するために、素早く試作して素早く失敗することが大事という話。

定理4:効率より移植性

シェルスクリプトの持つ思わぬ利点は、C言語で書かれたプログラムよりずっと移植性が高いことだ。

効率が良くても移植性のないソフトウェアの価値は、新しいハードウェアが出た途端に大暴落するので、シェルスクリプトを書くべきという話。

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

1時間働いたら、5時間分、100時間分、いや1000時間分の結果を生み出すようにしなさい
既存のアプリケーションをゼロから設計し直すことは模倣ではあっても創造とは言わない

独自技術症候群(Not Invented Here Syndrome)を避け、他人の成果を利用し、他人に成果を利用されるのを認めることで個人の力を増幅できるという話。

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

UNIXは、人間とマシンのどちらがボトルネックなのかを分かっている
最も重要なことに、拘束的ユーザーインタフェースはソフトウェアの梃子の効果を利用できない

 対話的インタフェースを使うプログラムは、大きく醜くく他のコマンドと連携しづらいものになるので、避けたほうが良いという話。

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

入出力をハードワイアするという裏には、プログラムの使い道が完全に分かっているという思い上がりがある。
ユーザーがソフトウェアをどう使うかは、決して予測できない。設計者である自分の意図に全員が従ってくれるはずだ、などとは絶対に考えてはならない。

プログラムをフィルタとして使えるようにしておくことで、開発者の想定を超える使い方にも対応できるという話。

まとめ

全体的に頷けるところが非常に多い書籍でした。書かれた年代が古いため、事例はピンと来ないものも多いですが、それほど気にならずに読めました。