UNIX哲学 ”フィルタ化”と”小定理”について
UNIXの核心的な理念の一つである「フィルタ化」「小定理」について、噛み砕いてみる。
UNIXを支えている９つの定理
補足程度にUNIXを支えている9つの定理についておさらい
- 小は美なり
- 1つ1仕事
- 即行プロトタイプ
- 効率性より移植性
- データはテキスト
- レバレッジ・ソフトウェア
- シェルスクリプト活用
- 対話インターフェース回避
- フィルタ化
フィルタ化について
ソフトウェア設計における重要な考え方の一つとして、「フィルタ化」があり
主にデータの「処理」に集中し、データの「生成」よりもその変換や操作を主眼に置くという考え方。
データ入力には、標準入力を使用し、データ出力には標準出力を使用しましょう。
…
このように設計すると、ソフトウェア同士が接続可能(コネクタブル)になります。
プリンシプルオブプログラミング 思想 ~ フィルタ化 ~ より
コマンドでよく使うパイプラインなどが当てはまりそう。
UNIX哲学のフィルタ化の素晴らしい実例な気がする。
UNIX哲学・10個の小定理
フィルタ化の章で紹介されている、厳密には定理とは言えないまでも、
UNIX哲学を支える10個の小定理について触れてみる。
10個の小定理
- 環境カスタマイズ
- 軽薄短小カーネル
- 小文字使用
- 森林保護
- 沈黙は金
- 並行思考
- 部品コラボレーション
- 90パーセント解
- 劣るが優る
- 階層指向
環境カスタマイズ
自分で調整した環境に馴染めば馴染むほど、調整できないような環境には移りたがりません。
プリンシプルオブプログラミング 思想 ~ フィルタ化 ~ より
ユーザーが自分のニーズに合わせてソフトウェアの動作を変更できるように開発する。
確かにターミナルなどはカスタマイズに富んでおり、この小定理を表しているように思う。
軽薄短小カーネル
ソフトウェアの中心部をシンプルに保つことを推奨し
ソフトウェアは効率的に動作し、トラブルシューティングとメンテナンスが容易にしようという考え。
UNIXがカーネルの肥大化を拒絶し、小さく軽くする選択をした２つの理由
- カーネルのプログラマのみしか保守できないこと
- アプリケーションに障害があると、カーネルも影響を受ける可能性があること
小さく作り、1つ1仕事に納めることを徹底していたのだと思う。
今のアーキテクチャに繋がるような考え方にも思える。
小文字使用
命名には、小文字を使い、かつ短くします。
プリンシプルオブプログラミング 思想 ~ フィルタ化 ~ より
名前に小文字を使う理由はいくつかあり
まず、目に優しいこと → 長時間見れる
そして、見た目の変化に富んでいると言うこと → 識別しやすく、読みやすい
さらに、大文字を効率的に使用できる → READMEなどすぐに見つけることができる
また、名前を短くする理由として、コマンドを一行に収めたいという思いがある。
今まで小文字をあえて使うような考え方はしたことがなかったため目から鱗
森林保護
すべてのテキストファイルをコンピュータに保存するようにして、強力なツールでそれらを操作します。
プリンシプルオブプログラミング 思想 ~ フィルタ化 ~ より
テキストファイルとして保存することで、情報の組織化、検索、操作が容易になり、作業効率が向上することを示していると理解。
データを処理すると言うフィルタの原則が見える考え方だと思う。
沈黙は金
沈黙を守れば、画面上に意味のあるデータだけが表示され、無意味な情報が並ばずに済みます。
プリンシプルオブプログラミング 思想 ~ フィルタ化 ~ より
他のソフトウェアとの組み合わせを容易にするためには、UNIXのパイプ機構を用いることが非常に効果的。
これは、ソフトウェア間のスムーズな連携を可能にし、我々の作業を大いに助けてくれる。
しかし、コマンドのエラーメッセージさえも、ソフトウェア間の連携を阻害する可能性があると言うこと
ソフトウェアを設計する際に、常に念頭に置いておくべき。
並行思考
CPUは驚異的な速度で動作します。そのポテンシャルを最大限に引き出すためには、我々開発者はその性能を意識する必要があると言うこと。
効率的な作業分担の方法として、タスクを小さなパートに分割し、それらを並行して実行することを推奨しており
全体としての作業のスループットが向上させ、CPUの能力を最大限に活かしきるように頑張る。
部品コラボレーション
小さい部品を集めて大きなソフトウェアを作る方が、大規模ソフトウェアを単体で構成するよりも、価値の高いソフトウェアになります。
プリンシプルオブプログラミング 思想 ~ フィルタ化 ~ より
コードが大きくなると、保守が困難になり、さらには実行時のリソースも多く必要とするため、パフォーマンスが低下する。
これらの課題を解決するための一つのアプローチとして、ソフトウェアを小さな部品に分割し、それらを組み合わせて大きなソフトウェアを構築するという選択をしようと言う話。
この考え方も、モジュール化やマイクロサービスといった、今では主流な開発スタイルに繋がる定理だと思う。
90パーセント解
90パーセントのことをうまくやれるようにする方が、はるかに効率的であり、費用対効果が高くなります。
プリンシプルオブプログラミング 思想 ~ フィルタ化 ~ より
一部の難解な問題については、それらがコストを増大させたり、時間を浪費させたり、プログラミングの難易度を上げる場合、意図的にスキップすることで、全体としての問題解決の効率を上げようという考え。
つまり、全ての問題を解決しようとするのではなく、重要な問題に焦点を当て、それを解決することに注力することが重要。
劣るが優る
この記事で取り上げている"劣るが優る"という考え方は、私の解釈では、必ずしも最高品質を求めるのではなく、適度な価格設定と効率性を優先させるシステムが、最終的には優れているということ。
これは、ある意味で、最大公約数的なシステムが優勢となる考え方とも言える。
階層指向
ファイスシステムに適用されたディレクトリ構造は、最初の階層構造アーキテクチャです。
プリンシプルオブプログラミング 思想 ~ フィルタ化 ~ より
構造を階層として考える。
自然界の秩序のように、UNIXの構造が自然をモデルとしており
「単純なこと」に大きな意味を見出したUNIXならではの指向。
最後に
UNIXのフィルタ化の概念やそれを支える小定理たちは、ソフトウェア開発の基礎となるような話で
今も引き継がれているような定理も多くあるのだろうなと感じる。
今回は、UNIXの哲学の中でも特にフィルタ化に焦点を当ててきたが
他にも「効率性より移植性」や「小は美なり」といった、他の重要な定理もある。
これらの原則を組み合わせ、より効率的かつ洗練されたソフトウェアを設計・開発に繋げていきたい。
Discussion