patorashのブログ

方向性はまだない

UNIXという考え方を読んだ

タイトルと本の見た目から、なんとなく難しそうだからと読んでなかったんじゃないかと思うんだけれど、お薦めの本として紹介されていたので読んでみた。感想としては、もっと若い時に読んでおくべき本だったなぁ~と思った。私、もうオッサンなので…。いや、オッサンだと学びが少ないとかではなくて、こういう考え方を若いうちから取り入れておけば、作ってきたアプリケーションやライブラリにもこの考え方を適用することができただろうから、柔軟なものを作ることができただろうになぁ…というやつです。

そして、この考え方を知っていれば、なぜこのライブラリはこんな作りになっているのか?とか、どうしてシェルだとパイプを使ってゴニョゴニョせにゃならんのか?という理由もわかる。わかると「便利だな」と思うんだけれど、わからないと「なんでこんなに組み合わせなければならないんだ!?」と思ってしまって苦手意識がついてしまうんじゃなかろうか?まぁ実際に苦手意識はかなりある。

効率よりも移植性を優先する

最も読んでよかったなと思ったところは「効率よりも移植性を優先する」というところだった。綺麗なコードや効率のよい処理のことはよく意識するけれど、移植性についてはあまり意識していなかったかもしれない。この章は示唆に富んでいて、耳が痛い。「プログラムを速くすることに時間をかけない」とか、「最も効率のよい方法は、ほとんどの場合移植性に欠ける」とか。

「来年になればもっと速いハードウェアが出てくるから、そこでもそのプログラムが実行できれば勝手に速くなる(意訳)」と書かれていた。本が書かれた当時はムーアの法則がめちゃくちゃ効いてた頃だから、それは納得なのだが、とはいえ現代においてもそれは言えるのかなと思う。クラウドにおいても、移植性が高ければ、スペックの高いインスタンスを立てればいいわけだ(いわゆる金の弾丸で解決するやつ)。

すべてのプログラムをフィルタにする

この章も、なるほどなと思った。もっと標準入出力(stdin, stdout)を使って、処理の結果をどうするかはユーザーに委ねたほうがいいなと思った。そうすれば、ユーザーの判断で様々な処理を組み合わせることができる。結果をファイルに出したいのであれば、 > hoge.txt とすればいいわけだし。

処理の成果物はなんとなくファイルにしたほうがいいよなぁ~と思っていた節がある。でもまぁそれをどうするかはユーザに委ねるべき。

pecoを使って処理をしたいときがあって、そのために標準出力に出す、ということはしていた。

フィルタにするためには、標準出力に出すことと、標準入力から受け取れるようにすること。こういうのが理解できると、gulpとかでstreamを使って処理を順々にしていくのはこの考え方なんやなってのがわかる。webpackのプラグインも同じ。だから、処理の流れの途中にやりたいことを差し込める。

他の学び

梃子の効果なども面白かった。他の考え方(移植性を重視とか)の部分と切り離せない部分はあるが、Cで書くよりもシェルスクリプトにすれば、大概の環境で動くし速度も速い。汎用的なものにしておけば、どこでも動くから再利用性が高まる。

90%の解を目指す、とか、部分の総和は全体よりも大きい、のところもウーンと唸りながら読んだ。疎結合のプログラムの組み合わせでアプリケーションを作るのと、単体のプログラムでアプリケーションを組んだ時の話では、マイクロサービスとモノリシックなサービスを連想した。マイクロサービスはUNIXの考え方に基づいたものなのだなと思った(マイクロサービスアーキテクチャに対する知識はほぼないけれど…)。

疎結合にしておけば、より効率のよいプログラム実装が組めれば、そこだけを差し替えることが可能になる。不要になれば外すこともできる。しかしでかいプログラムになっていると、外せない…。今も絶賛それで苦しんでいるところがある…。

感想

感想、この記事の最初に書いちゃってるんだけれど、この考え方を最初から知っていれば、なんでUNIXLinuxの環境はこういう書き方なんだろうか?とか、シェルわけわからん~みたいな苦手意識は薄まるのではないか?と思う。そして、UNIX的考え方を持っていれば、ライブラリを作るときにも汎用的に作ることができそう。この考え方はコンピュータで仕事をする上でベースとなっているし、普段利用しているものはこういう思想で作られているのだなとわかっておいたほうが絶対にいい。早い段階で知っておくべきもんだなと思うので、もっと布教していきたい。