Subscribed unsubscribe Subscribe Subscribe

SE Can't Code

A Tokyo based Software Engineer. Not System Engineer :(

UNIXとシェルスクリプト.

life Engneering

UNIXという考え方という本を久しぶりに読んだ。著名なソフトウェアには一つ一つに哲学がある。それは長いソフトウェアの歴史の中で進化し続けたエンジニア達の考え方そのものだが、僕はそういう作り手の哲学や背景というものを知るのがとても好きだ。たとえばDRY(Don't Repeat Yourself)の考え方はプログラミングの技術書には必ずといっていいほど登場するし、Railsの「設定よりも規約」という設計思想や、LinusによりGitが作られた背景などを知っていくととても面白い。そういう意味で好きなソフトウェアというのはいくつかあるが、特にUNIXの哲学というのはソフトウェアを開発する上でかなり意識している。UNIXの代表的な哲学として下記のようなものがある。

  • スモール・イズ・ビューティフル(小さいものは美しい)
  • 一つのプログラムには一つのことをうまくさせる
  • できるだけ早く試作する
  • 効率より移植性を優先する
  • 数値データはASCIIフラットファイルに保存する
  • ソフトウェアを梃子として使う
  • シェルスクリプトによって梃子の効果と移植性を高める
  • 過度の対話的インターフェースは避ける
  • すべてのプログラムをフィルタとして設計する

「スモール・イズ・ビューティフル」「一つのプログラムには一つのことをうまくさせる」はエンジニアならうなづける言葉だろう。昨今だとMicroServiceでアーキテクチャレベルでも意識されている考え方だが、特にプログラミングではサブルーチンをこの考えに基づいて書くことが多いと思う。それは簡潔性や効率性、保守性を考えた時に大きな効果を発揮する。エンジニアがよく使うUNIXコマンドでも元々はこの思想を基にして設計がされている(現在のlsコマンドとかは整理機能やらなんやら盛り込まれていて思想に反しているが)。

コードを書いている時、誰が読んでも理解出来るか、という観点が重要であったりする。一つのサブルーチンが何百行にも渡り、ずっと下までスクロールしないと読めやしない、といったコードはUNIXの哲学に反する。おそらく、そのサブルーチンのテストも凄く複雑なものとなっているだろう。これは非常に可読性と保守性を犠牲にし、バグを入り易くする。少なくともそのサブルーチンのデバッグをやさらた人はたまったもんじゃない。一つのサブルーチンに一つのことをさせている限り、テストは比較的簡単に書けるだろうし、第三者から読んでも理解がし易い。

またこうした一つのことを行うプログラム群が存在することで、シェルスクリプトというものが大きく機能する。シェルスクリプトは、Cプログラムや他のシェルスクリプトの実行を命じる一つ以上のステートメントから成っており、それら個々のコマンドをメモリにロードし、間接的に実行する。実行されるコマンドは、数百行、数千行、ときには数万行にもなるC言語のプログラムであるが、それらは他の誰かが書いたプログラムであり、他の誰かがデバッグしたものである。シェルスクリプトは単なる受益者であり、それらは単一の目的を持ったプログラム群を組み合わせることで新しい価値を享受することができる。

たとえば下記のような例では、いくつものコマンドが組み合わされたシェルスクリプトになっている。

echo `who | awk'{print $1}' | sort | uniq`'|'sed's/ /, /g'


これはユーザ名の一つ一つをコンマで区切ることとし、また同一ユーザがシステム上で複数のセッションを開いている場合でも、その名前を一回だけ表示する、ということをBourneシェルのシェルスクリプトで行っている。このシェルスクリプトはたった1行だが、6つコマンド、echo, who, awk, sort, uniq, sed が一種の並列連作の中で同時に実行されている。これら一つ一つを車輪の再発明しようものなら大変なことだ。なぜなら普段からよく使うだろうこうした基本的なUNIXコマンドであれ、それらを構成するコード量は数百から数千行にまで及ぶからだ。僕らはこうした大規模なコードを読むことなく使うことが出来る。シェルスクリプトを使えばそれらを組み合わせて自分のやりたいことを実現することが出来るのは凄いことじゃないか。

ここでこれから先に自分のコードに対して意識したいところとしては、誰にでも使えるような形でコードのインターフェースを設計しよう、というところだ。これは割と意識しながら普段から仕事でも書いてはいるが、なかなか思うようにいかなかったりする。そのたびにリファクタリングとテストをしているわけだが、過去の自分がここを蔑ろにしていた時の負債は大きい。まだまだいろんなコードを読んで設計を学んでいかないといけないと思わされる。


仕事の関連と言えばそうだが、最近アーキテクチャ周りの書籍を読み漁っている。MicroServiceに始まり、APIについていろんな文献を当たったりしている。最適なソフトウェア、アーキテクチャとはなんだろうと休日の昼間から考えていたりもしたが、なかなか雲を掴むような話で、まだまだわからないことが多い。でもそうした設計時に大事にしたいと思ったことは、こうしたUNIXというプロジェクトにも見られる、思想や哲学というものだった。ここが地に足をついていれば、おそらく良いものが出来るスタートを切れるだろうと思う。それはたぶん、小さなスクリプトコードを書く時も同じなのだろう。また明日から仕事が始まり、コードを書く日々が続いていくわけだが、哲学を持ってモノを作っていきたい、と、そう思った。

Remove all ads