UNIXという考え方

書かれたのがが1995年というから、今から14年も前になる。まだWIndows95すらない。この本にはまだWindowsという単語は出てこない。MS-DOSがでてくるのみだ。しかし、この本の内容は古くない部分も多い。
たとえば、「定理3　できるだけ早く試作を作成する」では、完璧な設計や機能設計書は無理であり、最初の仕様から変化することも普通に起きることを指摘している。そして、試作によってめちゃくちゃにたたかれるかもしれないけれども、設計情報を得て学ぶ方がよい、という。そこで、UNIX開発者が提案する開発する手順が以下の通りだ。（P44)

1. 短い機能仕様書を書く
2. ソフトウエアを書く
3. テストして書き直す。満足できるまで、これを繰り返す。
4. 詳細なドキュメントを（必要なら）書く

これは、アジャイルディベロップメントそのものではないだろうか？。
「定理7　シェルスクリプトを使うことでてこの効果と移植性を高める」はシェルスクリプトが発展したPerlなどのスクリプト言語の隆盛を予言していたともいえる。
もちろん、UNIXらしい考え方もある。たとえば、
「定理5　数値データはASCIIフラットファイルに保存する」では、UNIXコマンドとの親和性からASCIIフラットファイルの有利な点を述べている。UNIXに限らず、一般的にも効率は悪いがASCIIフラットファイルの方が扱いやすい。XMLやHTMLもASCIIフラットファイルだし、バイナリデータでファイルを保存することはいわゆる旧Officeツール*1やデータベースの内部的なファイル、画像などのマルチメディア系データ以外では、私はあまり使わない。ちなみに私が一番使いたくない理由は、DIFFがとりにくいことだが。
「定理8　過度の対話的インターフェースを避ける」は、とてもユニークだし、極めて合理的だ。コマンドインタープリタを利用した際に、そのコマンドインタープリタからコマンドを起動し、さらにそのコマンドの中でコマンドインタープリタ的なものが存在するのはよくないという。なぜなら、大きく醜いコマンドができあがり、対話を要求することから、自動化という側面からも障害が起きる。というものだ。
さて、GUIによるアプリケーションが主流となった今では、どうか？対話的な要素が多くなり、アプリケーションは肥大化している。GUIの部分のテストが非常にやっかいなものになりつつあるが、マウスを用いた豊富な操作が一見、可能になっている。
しかし、実はGUIは自由に操作ができているようで、コマンドインタープリタの処理ができる範囲には追いついていない。それは、コマンドインタープリタがもつ、組み合わせの自由さによる合わせ技だ。GUIがコマンドインタープリタよりも優れているわけではないということを暗にこの定理は示していると思う。
GUIは何も知らない人にとって、情報が目の前にたくさん現れてくるため、非常にフレンドリーに感じる。ただし、そのフレンドリーさは対応する問題を簡単にしているわけではない。たとえば、フォーマットする際にファイルフォーマットの種類がわかっていなければ、GUIでもコマンドインタープリタからでも、結局何ら変わるわけではない。
また、業務アプリケーションのように同じことを繰り返すのであれば、GUIの構成方法はもっと考え直すべきだろう。コマンドラインほどの自動化をGUIに求めることはできないが、毎日使う人がうっとうしくないようにすむためにはどうすればいいのかをよく考えておかなければならない。ファンクションキーなどを使用したショートカットを備え、マウスレスで使用できるようにすることや、前回入力値を覚えていることなどは実は（プログラマが考えるよりも）とても重要であり、画面の切り替わりがアニメーションするかどうかなどはどうでもいいことなのだ（ただし、営業段階では重要かもしれないが）。

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

*1:xlsxなどのOfficeツールの現在の形式はXMLをZIPで圧縮したもの