はじめに
読んだ。
- 作者: Mike Gancarz,芳尾桂
- 出版社/メーカー: オーム社
- 発売日: 2001/02/01
- メディア: 単行本
- 購入: 40人 クリック: 498回
- この商品を含むブログ (145件) を見る
どの記事か忘れて恐縮なんだけど、あるブログで「UNIXという考え方」は本当にいい本だ、と紹介されていたのを見て、買った。本当に読んでよかった。エンジニアとして働き出して今や4年目だけど、これは1年目に読むべき本に違いない。
9つの哲学
Small is beautiful - 小さいものは美しい
この章では小さは何にもまして優れている説明がなされる。これは次の定理8哲学)にも関連するが、多くのことをしすぎないこと、余計なことをしすぎないこと。あれこれ親切に機能を加えてソースコードが大きくなってしまうと、保守はしづらいし、わかりづらいし、システムリソースに優しくない。
また、小さくて、かつ1つのことだけをやるプログラムであれば他のプログラムと組み合わせて使うことができる。これはUNIX哲学の中でももっとも特徴的な2つの定理だろう。
巨大なソースコードのプログラムよりは小さいほうがいいことは納得いくと思う。これはコードゴルフ(できるだけ短くプログラムを書く)ことではないと思う。
Make each program do one thing well - 一つのプログラムには一つのことをうまくやらせる
1つめのSmall is beautifulと合わせて、UNIX哲学の中で1番大切な定理ではないかと思う。1つ目の定理を補完関係にあり、1つのことだけをやるプログラムはプログラムが小さくなるし、他のことと組み合わせて使うことになる。
Build a prototype as soon as possible - できるだけ早く試作する
これはどちらかというとウォーターフォールとアジャイルの開発手法の比較でアジャイルが優れている点として感じたことではあったが、この場合の不確実性は予測できないから小さく早くしよう、という考え方とは少しレベル感が違うように思う。
やっぱり周囲の優秀なプログラマを見ていても、プロトタイプが早い。とにかく先に作っている。細かいことはあと。こういう仕事の進め方が非常にうまい。この定理も真実なんだろう。
学習曲線という観点を述べている。何かを学ぶとき、最初からうまくできるわけがない。少しずつゆっくりと学びながらやっていくしかない。そのためにはさっさと作ってしまうというのは理にかなっている。誰も学習していないときの不確実な部分を補うことはできない。
この章で語られている第一のシステム、第二のシステム、第三システムの話は面白かったなぁ、ぜひ本書を読んでみてください、あるある、と思いました。
本書8章で語られている言葉が印象深かった。
覚えておいてほしい。ソフトウェアは、実は作るものではなく、成長していくものなのだ。(p132)
これは移植性があれば新たなハードウェアに移し換えることができるということの他、小さいものを、はやく実現することで、今後くる様々な複雑な要求に最小限のエネルギーで対応できるということも意味しているように思う。
Choose portability over efficiency - 効率より移植性を優先する
言ってしまえば、プログラムレベルの効率(=性能)は、次の年のハードウェアの進化によって凌駕できる。プログラムの性能よりは、別のアーキテクチャに移植し続けることが可能なプログラムのほうが、結果的に長く使われ、結果的に性能がよくなるということだ。これはなるほどと思う。
Store numerical data in flat ASCII files - 数値データはASCIIフラットファイルに保存する
そのまんまだ。
動かせないデータは、死んだデータだ(p58)
Use software leverage to your advantage - ソフトウェアを梃子として使う
最初ちょっと掴みづらかったんですけど、1つのプログラマの結果をもらって、その力を使って別の問題を解決する、というニュアンスでしょうか。
具体的には、ある処理をパッケージして配布するようなことだと思う。別にシェルじゃなくても、いろんな言語の各ライブラリでもいい。めんどくさい処理を誰もが使えるようにして、自分の仕事であとの何億人のプログラマが同じ苦労をしないですむようにする、梃子のように莫大な省力化をもたらす。
これは1つのことをうまくやるようにできていないと、なかなか難しいでしょうね。
Use shell scripts to increase leverage and portability - シェルスクリプトによって梃子の効果と移植性を高める
シェルスクリプトすげーぞ!という話。自分はあんまり得意ではなく、別の言語で書いたりしてしまうので耳が痛い話。
まぁC言語は書けませんけど。(笑)
シェルスクリプトのこともっと好きになりたいな、と思いました。
Avoid captive user interfaces - 過度の対話的インタフェースを避ける
これは次の定理であるフィルタとして使うことができないからですね。自動化の妨げになります。expectを使う手もありますが、やってられないです。他のプログラムと組み合わせて使うことを妨げるので、これは感覚レベルで嫌だなと思っていました。
Make every program a filter - すべてのプログラムをフィルタとして設計する
これも他の定理とゆるく関連ついていますね。何かしらのデータを入力として受け入れて、何かしらをフィルタし、それを標準出力として出す。この慣習を守ることによって、プログラムを小さく保ち、プログラム同士の結合を可能にするんですね。
以下はあまり意識できていなかったので心がけます。
- データ入力にはstdinを使用する
- データ出力にはstdoutを使用する
- 帯域外情報にはstderrを使用する
10の小定理
全部はいいかなと思うので気になったものだけコメント残しておく。
- 好みに応じて自分で環境を調整できるようにする
- オペレーティングシステムのカーネルを小さく軽くする
- 小文字を使い、短く
- 森林を守る
- 沈黙は金
- 同時に考える
- 部分の総和は全体よりも沖井
- 90パーセントの解を目指す
- 劣る方が優れている
- 階層的に考える
森林を守る、はちょっと面白いなと思いました。
紙には気をつけることだ。それはデータの死亡証明書といってもいい (p112)
だいぶ社内もペーパレスが進んできました。
沈黙は金に関しては、うーーんわかるけど、やっぱり困るときはある、という印象です。(笑) これはエラー出力の親切さというより、標準出力で、フィルタした結果が何もないなら黙って何もない結果を出せばいいんだ、ってことだと思います。
90パーセントの解を目指すってのは、本当に素晴らしいですね。これは信頼性の話とも似てるなと思っていて、90%から99%を目指す、99%から99.9%を目指すにはかなり大きな労力がかかる。完璧を求めすぎないこと。やることを明らかにし、90%を満たすものを作ること。大事だなと思います。
おわりに
何度も述べているが、この9つの定理はゆるくつながっていてUNIX哲学を作っている。1つのことをうまくやる、小さいプログラムを作ろう。それはできるだけ移植可能であり、長く使われ続けるものであろう。さらに梃子の力を働かせるようなものを作り、車輪の再発明は避けよう。そしてそれぞれの小さいプログラムを組み合わせて、問題を解決しよう。
この哲学、本当大事ですね。仕事でちょっとしたシェルスクリプトを書いて社内のgitlabにあげてますが、(書かないよりはマシですが)そのプログラムは全然1つのことをうまくやるようにできていなくて恥ずかしい限りです。
みんなに梃子のようにうまく使って楽してもらえるようなプログラムをこれから書いていきたい、そう思える名著です。また読み直したいな。