Skip to main content

「UNIXという考え方」を読んだ

電子書籍がなかったので久々に物理で読んだ

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

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

  • 作者:Mike Gancarz
  • 発売日: 2001/02/01
  • メディア: 単行本

UNIXの定理への感想

小さいものは美しい

小さいとわかりやすく、保守しやすい、組み合わせやすい、計算機のリソースにも優しいということ。僕はプログラム単体でこれを意識していることはないけど、関数単位ではほとんどのプログラマがこの定理は大事だというだろう。

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

いわく関心の分離。やりたいことの本質のみを行うことが柔軟性につながる。lsコマンドも本来は複数の列に整理して出力すべきではないらしい。 これもプログラマならまず意識していることだと思う。一つの関数、一つのモジュールには一つの機能、わかりやすい変数名と共にコードの基本な気がする(かつ難しい)。

できるだけ早く試作をつくる

これもアジャイル的な言葉で最近のエンジニアは重視している考え方だと思う。ソフトウェアはつくるのではなく育てて行くものだという考え方。 この本ではUNIXの成長過程と共にこの考え方が紹介されていた。ソフトウェアには3つの段階しかなく、若年期、成熟期、老年期しかない。最近だとrailsは老年期にはいってきているのだろうか。
最近、自分の仕事でも早期の試作の利点を体感することがあった。新機能を開発で議論をする時に、チームメンバーがそれぞれの頭の中の機能で話しすぎてそれぞれの議論が噛み合わないという問題があった。けれど、デザイナーの方がモックを作ってくれるようになった途端議論がスムーズになったという体験だ。具体的な図面はチームで議論する上で強力な標識となることをこのとき認識した。
この定理でのドキュメントに関する考え方も面白かった。ドキュメントを詳細に書くことが正義だと思っていたが、ドキュメントも育てるものであり、ちょっとしたことでも芽を残すことを意識して「気楽に」ドキュメントを残したほうが結果的に良いのかなとも考えた。

効率より移植性

ハードウェアは日々移り変わるので移植しにくいソフトウェアは長生きしないというもの。Webで色々やっているとHTTPでソフトウェアを配るのが現実的になってきていると思う。それこそChromeBookが体現していて、HTTPとその解釈ができるブラウザさえあれば他のサービスは全てブラウザを通して使える。サーバー単体のハードウェアではなく通信規格にいかにのっかれるかという時代に突入している気がする。いつかHTTPを超えるなにかが出て人々はそれをつかって情報をやり取りするようになるのだろうか。

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

「効率より移植性」と同様の感想をもった。

ソフトウェアを梃子として扱う

車輪の再発明は良くないというもの。そして人類全体でソフトウェアを複利させていこうとい考え方だと思う。なにも開発にOSSを使っていくだけじゃなく日々の作業で人のソフトウェアを使っていこうという気にさせられた。

シェルスクリプトによって梃子の効果と移植性を高める

「ソフトウェアを梃子として扱う」と同じ

過度の対話的インターフェイスをさける

なるほど言われてみると確かに、という話には感じる。ユーザーを束縛するインターフェイスはソフトウェアを組み合わせにくくし、バックグラウンドで実行させたりもできない。コマンドをつくる側からするとこれも重要な観点の一つなんだろう。RESTがステートレスを基本に作られてなければこれほど世界でWebサービスは流行らなかった気がするし納得。

全てのプログラムをフィルタとして設計する

それはそう。フィルタとしての機能を単独にするべきということにつながる。

まとめ

特に前半の「小さいものは美しい」、「一つのプログラムには一つのことをうまくやらせる」、「できるだけ早く試作をつくる」、「効率より移植性」は全てのソフトウェア開発で役にたつ考え方だと感じた。
あとアジャイル開発で「ユーザーの価値を考える」をそのまま「ユーザーにとっての価値を増やす」にすると機能を増やしすぎてユーザーの価値がぼやけるという問題もこれから起きるのかなぁとか思ったりした。