UNIX哲学に学ぶシンプル
開発においてシンプルさを追求したいのであれば、UNIX哲学はいかがでしょうか？
WikiのUNIX哲学のページには深くうなづけるたくさんの格言があります。この記事ではそれらの格言をいくつか紹介します。
"Keep it Simple, Stupid" （KISS原則）
「シンプルでつまらないものに保て」という格言です。エリック・S・レイモンドは著書『The Art of UNIX Programming』でKISS原則がUNIX哲学を代表する哲学であると説明しています。
まずはKISS原則を覚えておきましょう。
後述する他の格言の解説を読むことで、この格言の理解を深めることができると思います。
一つのことを、うまくやれ
一つのことをうまくやるプログラムを書く、それにより可読性・テスト容易性が向上します。
一つのことをうまくやるプログラムが、よいものだと認識している人は多いと思います。
しかし新しいプログラムを書くときには実践できていても、後から機能を追加したい場合はどうでしょうか？
１つのことだけうまくやるはずだったプログラムに、もう１つの機能を足してしまうことはありませんか？
「一つのことを、うまくやれ」を実践するために、以下のアドバイスも紹介されています。
新しい仕事をするために、新しい「機能」を追加して古いプログラムを複雑にするのではなく、新しいプログラムを構築する。
古いプログラムに機能を足してしまう誘惑に駆られたら、思い出しましょう。
スモール・イズ・ビューティフル (小さいものは美しい)
Wikiではこの言葉のみが紹介されていますが、『Unixという考え方』という書籍ではもっと掘り下げて解説されています。
プログラムを書くときは小さなものから始めて、それを小さなままに保っておく。簡単なフィルタプログラムでも、グラフィックスパッケージでも巨大なデータベースを構築するときでも、同じく小さな実用的なプログラムにする。一つの巨大なプログラムにしようとする誘惑に負けないで、シンプルさを追求する。
以上が『Unixという考え方』で紹介されているスモール・イズ・ビューティフルの姿勢です。
それでは小さいプログラムにはどのようなメリットがあるのか整理してみましょう。
- 読みやすい
- 組み合わせやすい
- 移植性が高い
小さいプログラムは読みやすいですね。そして読んでどのように振る舞うのか理解しやすいからこそ、呼び出して使いやすいパーツとなります。短期的・近眼的な視点において、これらのメリットは大きいですね。
また小さいプログラムというのは実行するための前提が少ないものです。そのためいろいろな環境で動かすのに苦労しません。つまり小さいプログラムには環境が変化しても生き残りやすいという長期的なメリットがあります。
『Unixという考え方』ではもっと紹介されています。興味がある方は是非読んでみることをお勧めします。
より悪いことは、より良いことだ （Worse is better）
別の表現として「劣るほうが優れている」というものもあります。これらは「シンプルであることが、他のいかなる特性（正確さ、堅牢さ、完全さ）よりも重視である」という考え方です。
さらに説明を付け加えると、最小限のものから始めて必要に応じて成長させる方が良いという考え方です。これは段階的成長と呼ばれています。
シンプルなコードには必要な機能が備わっていないかもしれません。または十分なパフォーマンスを発揮できないケースもあるでしょう。しかしそれらのコードを悪いまま、劣ったままにしてシンプルにしておきなさい、ということです。そして後から、必要に応じて複雑さを加えなさいということを意味しています。
以下のリンクは、この言葉を作ったリチャード・P・ガブリエルによる解説です。
Worse Is Better | Richard P. Gabriel
スマートなデータを使うつまらないコードを書け
覚えやすい格言としては「スマートなデータを使うつまらないコードを書け」のみ紹介されていますが、他にも複数の表現が紹介されています。
代表のルール
知識をデータに織り込め。するとプログラムのロジックをつまらなくて頑丈なものにできる。開発者は選択に迫られたとき、プログラムの手続き的なロジックよりも、データをより複雑にすることを選択すべきだ。なぜなら、人間にとって複雑なデータは、複雑なロジックに比べて理解しやすいからだ。プロジェクトに携わるどの開発者にとってもプログラムを読みやすくすることで、プログラムの保守を可能にすることを目的とする。 （"The Art of UNIX Programming"より）
データはすべてを決定づける。もし、正しいデータ構造を選び、ものごとをうまく構成すれば、アルゴリズムはほとんどいつも自明のものになるだろう。プログラミングの中心は、アルゴリズムではなくデータ構造にある。 （"Notes on Programming in C"より）
テキストをパースして情報を抽出するようなプログラムを書いていたら、テキストよりも複雑なデータ構造を設計することでパースを不要にできないか、検討しましょう。
明瞭さのルール・透明性のルール
可読性と関連のあるルールを2つ紹介します。
明瞭さのルール
明瞭さは独創性よりも良い。開発者が最も意志疎通を図るべき相手はコンピュータではなく、プログラムを読み、保守を行う自分を含めた開発者であるかのようにプログラムを書くべきである。このルールは、将来そのコードを扱う人にとって、コードが読みやすく、理解しやすいものにすることを目的とする。 （"The Art of UNIX Programming"より）
透明性のルール
透明性を求めてデザインせよ。調査とデバッグが簡単になる。
開発者は将来そのプロジェクトに参加する開発者が、自分の思考プロセスを明瞭に理解できるように書き、有効な入力と正しい出力を容易に識別できる入出力形式を使用することによって、可視性と発見性を設計する必要がある。デバッグにかかる時間を短縮し、プログラムの寿命を延ばすことを目的としてる。 （"The Art of UNIX Programming"より）
まとめ
以上、私が紹介したいシンプルさについて学べるUNIXの格言でした。
少しでも興味を持っていただけたら、ぜひご自身でもUNIX哲学を探索してみてください。
おまけ: テキスト・ストリームを扱うプログラムを書け
シンプルさとは少し離れる格言ですが、どうしても紹介したいものを１つだけ。
UNIXは、コマンドの実行結果のテキストをパイプ(|)によって次のコマンドの入力として渡すことができます。「テキスト・ストリームを扱うプログラムを書け」という格言は、パイプによって組み合わせられるパーツとなるプログラムを書け、という意味です。
この格言と相性の良い格言があります。
すべてのプログラムの出力が、まだ見ぬ別のプログラムの入力になること。
「テキスト → 処理 → テキスト」のように入力と出力で同じ形式のデータを扱うことができるプログラムやツールは扱いやすく、開発者から長期的に支持される傾向があります。
例えばSQLはすべてのデータをテーブルとして扱います。他には、JavaScriptの様々な配列操作メソッド(Array.prototype.*)でプログラムを記述する方法はとても一般的です。
「テキスト・ストリームを扱うプログラムを書け」というのは、テキストだけではなく、データを扱うシンプルなパターンを推奨しているのだと私は理解しています。また、このような特徴を持つ技術に精通しておくことは、学習コストよりも大きなリターンを期待できるでしょう。
Discussion