その手の平は尻もつかめるさ

ギジュツ的な事をメーンで書く予定です

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

「UNIXという考え方」をAmazonのwish listに入れていたらid:kenjiskywalkerさんが贈ってくださったので読みました．お陰でUNIXという考え方を学べました．ありがとうございます！


本書では一貫して「プログラムを小さく作る」という事と「1つのプログラムには単一のことだけを上手くやらせる」という事について言及されています．
プログラムを小さく作るということによって，そのプログラムはコンピュータのリソースに対して優しくなり，なおかつ巨大なプログラムと比較して人間が理解するのが簡単になるので保守がしやすくなり，かつ他の部品と組み合わせやすくなるという論旨です．
プログラムを小さく作ると，必然的にそのプログラムは多くの責務を負えなくなる為，自然とプログラムは単一の機能のみを持つようになります．従ってこれら2つの考え方は対になっていると言えるでしょう．
本書で言われている「プログラム」と言うのは，恐らくexecutableな1つの実行ファイル (例えば1つのシェルスクリプトやコマンド) を指しているものと思われますが，この考え方は例えば「1つのメソッドには1つの仕事だけをさせる」というふうにメソッド (あるいは関数) に負わせる責務の範囲を限定する事や，「全知全能の神クラスを作らない」のようにクラスに負わせるべき責務の範囲を狭める，などといったプログラムの設計に対しても応用できると思いました．
このようなことは確か「リーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック (Theory in practice)」にも書いていた気がします．


データは全てASCIIで保存するべきで，デバイス依存のバイナリファイルで保存するな，という話も参考になりました．これは，データは持ち運べなくなった時点で価値が無くなり死ぬので，データの価値を殺さない為にも可搬性を維持するのは重要であるという意味で，恐らく現在だとASCIIではなくUTF-8で保存するのがベターなのでしょうが重要な知見だと思いました．確かにコンピュータ間でデータコンバートが必要になるのは地獄でしかありません．


UNIXという考え方において重要なポジションを占める「ソフトウェアの梃子を使う」という考え方は，どことなくオブジェクト指向の考え方に似ているように感じました．ソフトウェアの梃子とは，複数の小さなプログラムを組み合わせて1つの機能を実現するという手法の比喩表現で，これは小さなオブジェクトと小さなオブジェクトがメッセージを送り合う事で協調して動作し，1つの機能を提供するというオブジェクト指向の概念に通じるところがあるように思いました．双方とも小さいパーツを再利用して開発効率を高めるというアプローチで，なるほどという感じです．


また，「できるだけ早く試作する」という事に関しても書かれていて，これは最近話題になった「Team Geek ―Googleのギークたちはいかにしてチームを作るのか」にも書かれていたという記憶があります．最初から完全に正しいソフトウェアを書くことは不可能で，更に状況に応じて仕様は変更されるとした上で，誤った前提のままプロジェクトを推し進めるのではなく，早い段階で試作品を出してそれをテストし，批判を受けることによって方向を修正し，成果物を洗練していくという一連の流れが書かれていました．

わけてもその文脈で

1. 短い機能仕様書を書く
2. ソフトウェアを書く
3. テストをして書き直し，これを繰り返す
4. 必要なら詳細なドキュメントを書く

という開発フローが紹介されており，「それってつまりシンプルなアジャイルじゃん！」と思わず膝を打ちました．


あと参考になったのは「100%の完成度よりも90%の解を探す」という思考です．
僕はいわゆる「異常な努力」というやつをよくやってしまうんですが，なぜその「異常な努力」が必要となってしまうか*1 と言うと「あまり頻度は高くないけれどこういうユースケースに対応したい」だとか「ここをpluggableにすればもっと汎用的に使えるのではないか」だとか，そういった100%の完成度を執拗に狙ってしまうからなのです．
しかしそういう異常な努力によって生み出された機能はやはり実際にはあまり使われなくて，実装のコストと吊り合わない結果になることが大半です．本来は90%の完成度で充分満足しているのに残りの10%に多大な労力を割くのは無駄だと言えるでしょう．
100%の完成度よりも90%の解を探すというのは，「異常な努力」をしそうになった時に一旦待ったをかける良い考え方だと思いました．


さて驚くべきはこれが1990年代前半に書かれた書籍ということで *2，こうした考え方や哲学はこの時点で既に存在した訳です．
近頃巷で話題になっている「アジャイル」や「リーン・スタートアップ」，或いは「リーダブルコード」などといった考え方の源流は当時から既に形成されていた訳で，これらは過激に (あくまで過激に) 言うなれば元々あった考え方にone more thingを加えた上で，耳障りの良い言葉にパッケージングし直したに過ぎないという印象を受けました．

根源的な思考を学ぶ事に対する重要性を再認識した次第です．

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

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

*1:本来は大抵必要無いのだけれど

*2:勘違いされている方がいるので書きますけど，初出は1994年です．ref: http://www.amazon.com/The-UNIX-Philosophy-Mike-Gancarz/dp/1555581234