『UNIXという考え方～その設計思想と哲学』を読んだ。奥付を見ると、初版が発行されたのは平成13年。西暦に直すと2001年。もう14年も前だ。でも、この本の内容は今でも通用する。書かれているのが、TIPSなどではなく、設計思想だから。設計に迷った時、従うべき原則は長期間そんなに変わらない。
その内容は、9つの定理としてまとめられている。
- スモール・イズ・ビューティフル
- 一つのプログラムには一つのことをうまくやらせる
- できるだけ早く試作を作成する
- 効率より移植性
- 数値データはASCIIフラットファイルに保存する
- ソフトウェアの梃子を有効に活用する
- シェルスクリプトを使うことで梃子の効果と移植性を高める
- 過度の対話的インタフェースを避ける
- すべてのプログラムをフィルタにする
デプロイメントパイプラインでは多くのタスクを取り扱うから、一つのプログラムで幾つかのことをやらせようとすると、あっと言う間にスパゲッティが出来上がる。でも、各タスクは既に実装されているから、それらをシェルスクリプトなどのグルー言語から活用すれば、梃子を効かせられる。そのシェルスクリプトなどを作る際は、対話的インタフェースを避けてフィルタに徹しないと、パイプラインを止めてしまう。
もっと早くこの本を読んでいればもっとうまく作れたのに!！（と思う一方で、作る前に読んだとしたら、字面を追っただけで終わっていたんじゃないか、とも思う）
もう一つ面白かったのは、「3. できるだけ早く試作を作成する」に続けて紹介されていた「人間による三つのシステム」の話。追い詰められた人間が第一のシステムを創り、「専門家」が、第一のシステムで証明されたアイデアを用いて第二のシステムを作り、第二のシステムで「火傷」した人が作るらしい。この第三のシステムが、もっともバランスがよく目標となる。
優れたインタフェースをデザインするには少なくとも3回の挑戦が必要という話を思いだす（『誰のためのデザイン？』か『未来のモノのデザイン』で読んだんだと思う）。それから、『イノベーションのジレンマ』ともおおむね整合しているように見える。あと、先日読んだ『スプライトシュピーゲルIV』の次の一節を思い出した。この本でも第三のシステムを作るには、第一・第二のシステムを作る他にないと言っている。
悪法の中には、通過儀礼のように必ず経験せざるをえないものがある他の定理も今でも示唆に富んでいて、150ページ足らずの薄さだけれど、汲み取れる知恵が多い。しばらくしたらまた読もう。