UNIXという考え方を読み直した

会社の輪読会でUNIXという考え方を読むグループがいたので参加させていただくことにした。
もう何年も前にこの本は読んではいて、良書だったことは覚えているが、細部はとんと忘れてしまっていたので読み直した結果、改めて良書だと思ったので中でも自分に響いた節の感想を残しておくことにした。

一つのプログラムには一つのことをうまくやらせる

lsコマンドの例を取って、多機能になることでプログラムが複雑化していくことへの懸念が書かれている。
lsはよく使うコマンドだが、尋常じゃないほどのオプションがある。manでみたらほぼAからZまであった（eとjだけなかった）。
元々はファイルだけをリスト表示させたいだけだったのだろうけど、本来的な目的とは異なったオプションまで追加されていることで、巨大で複雑なプログラムになってしまっていることを指摘しているようだが、確かにlsをそこまでうまく利用できている人は果たしてどれだけいるのだろうか？
人のペアオペを観ていても、インフラエンジニアならいざしらず、オプションを全く使わない人も多数見かける。
まるで、ウェブアプリケーション機能にどんどん追加されていった機能そのものを見ているかのような話だなと感じた。

できるだけ速く試作を作成する

設計書を作成してからコードを書くのに取り掛かるのではなく、簡易的なアプリケーションを作ってから改善していくように書かれていて、まさにアジャイル的思考だと思った。
ウォーターフォールが駄目だとかそういうことではなく、不確実性の高いアプリケーションを作る場合は、まずはとにかく動くものを出してみる。
そして、それが良い方向なのか、悪い方向なのか、修正すれば良いのか、機能を追加すればよいのか。
そういった試行をするのに試作を作成するというのは、とても良いのだろうと思う。

効率より移植性

ソフトウェアの動作の高速性を高める場合などに、アーキテクチャに依存することで、他のアーキテクチャで動かないことを危惧している。
今のコンパイラ言語然り、ありとあらゆるソフトウェアが複数のOS上で動いている昨今の流れを考えると、やはりこの移植性という考え方はそのプログラムの価値を高めていくのだろうと思う。
GoやRustを使うことで得られるメリットを正確には私は理解できていないし、その良さを100%説明することはできないが、そのうちの一つとしてバイナリ単体で複数のプラットフォーム上で動作することがあげられるだろう。

シェルスクリプトには恐ろしいほどの梃子の効果がある

パイプとBashシェルスクリプトによる梃子のような効果の凄さを説いた節。
数個のコマンドをパイプでつなげることで、かんたんに1万行あまりのソースコードの効果を得られるという。
私はこの本の中でもこの節が一番好きかもしれない。
当たり前のようにパイプやsed、awkをつなげることで、特にsedやawkなんかはそれ単体で、とてつもないプログラムであり、それをワンライナーで処理できる。
よほど何十万行ものテキスト等でない限り、コンパイルされたそれらのプログラムを組み合わせるだけで、計算量など考えなくてもものの数秒で処理してくれる。
自分で一からプログラムを書くことを鑑みれば、これらのコマンドを使うことはとてつもないほどの武器になると考えている。

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

どんな形式であれ、すべてのプログラムはフィルタとして作用するということが書かれている。
常にインプットとアウトプットの形式をどのように扱うかを正しく制御しないといけないのだろうと思う。
私が書いたプログラムでよくバグになるのはまさにこの部分。
考慮しきれていないインプットやアウトプットがあると、想定外の挙動を引き起こす。
私が思うに、優れたプログラム（または、優れたプログラマーが書くコード）はこのインプットとアウトプットが「綺麗」だと思っていて、私は「汚い」ことがあるので、そこが技術力の違いなのだろうと思う。

沈黙は金

UNIXコマンドは戻り値で判定できることを説明していて、エラーだとしてもエラーメッセージを出さないことを書いている。
echo $? を見れば良いということだろうと思う。
これに関しては、なるほどと思いつつ、UNIX全体として標準出力・標準エラー出力が統一されているからなせることだと思った。
なにかプログラムを書いていて、統一的なエラー判定処理をうまく抽象化できていないとこれは難しいとも感じた。
そうでない場合は、都度infoでも良いので出力したほうがわかりやすいし、エラーなのかメッセージを出したいのか、目的を持って出力をしていこうと改めて思った。

UNIXの考え方：総括

最初に取り上げた節と同様になるが、小さなプログラムを目的を絞って作ることのメリットが書いてある。
まるでマイクロサービスを推奨するかのような内容だ。
複雑怪奇に色々な機能が絡み合うとメンテナンス性が下がるし、インフラもアプリケーションも巨大になってくる。
もちろん、マイクロサービスがすべてとか、モノリスなアプリケーションが駄目とかそういう話ではなく、それぞれ適切な単位で適切に使っていくことが大事なんだろうと思う。

まとめ

総じて、2001年に出版されたとは思えないほど、2022年の今でも通ずる内容だと思った。
もちろん全ての内容が正しいとかそういうものでも無いとは思うが、少なくともインフラだけではなくアプリケーション開発そのものの基本的な哲学が書かれていると思う。
それらが自分達が立ち向かうアプリケーションや課題にマッチするかは自分で確かめなくてはならないが、突き合わせて考えるにはとても良い本だと改めて感じたのだった。
安価だし、ページ数も150ページあまりなので、まだ読まれていない方には是非オススメしたい。