UNIXという考え方最終更新:2009.05.02
書籍情報
書籍目次
- イントロダクション
- 第1章 UNIXの考え方:たくさんの登場人物たち
- 1.1 UNIXの考え方:簡単なまとめ
- 第2章 人類にとっての小さな一歩
- 2.1 定理1:スモール・イズ・ビューティフル
- 2.2 やさしいソフトウェア工学
- 2.3 定理2:一つのプログラムは一つのことをうまくやらせる
- 第3章 楽しみと実益をかねた早めの試作
- 3.1 定理3:できるだけ早く試作を作成する
- 3.2 人間による三つのシステム
- 3.3 人間による第一のシステム
- 3.4 人間による第二のシステム
- 3.5 人間による第三のシステム
- 3.6 第三のシステムの構築
- 第4章 移植性の優先順位
- 4.1 定理4:効率より移植性
- 4.2 事例研究----Atari2600
- 4.3 定理5:数値データはASCIIフラットファイルに保存する
- 4.4 事例研究----あるUNIXプログラマの道具袋
- 第5章 これこそ挺子の効果!
- 5.1 定理6:ソフトウェアの梃子を有効に活用する
- 5.2 定理7:シェルスクリプトを使うことで梃子の効果と移植性を高める
- 第6章 対話的プログラムの危険性
- 6.1 定理8:過度の対話的インターフェイスを避ける
- 6.2 定理9:すべてのプログラムをフィルタにする
- 6.3 UNIX環境:プログラムをフィルタとして使う
- 第7章 さらなる10の小定理
- 7.1 (1)好みに応じて自分で環境を調整できるようにする
- 7.2 (2)オペレーションシステムのカーネルを小さく軽くする
- 7.3 (3)小文字を使い、短く
- 7.4 (4)木を守る
- 7.5 (5)沈黙は金
- 7.6 (6)平行して考える
- 7.7 (7)部分の総和は全体よりも大きい
- 7.8 (8)90パーセントの解を目指す
- 7.9 (9)劣るほうが優れている
- 7.10 (10)階層的に考える
- 第8章 一つのことをうまくやろう
- 8.1 UNIXの考え方:総括
- 第9章 UNIXと他のオペレーティングシステムの考え方
- 9.1 Atariホームコンピュータ----芸術としての人間工学
- 9.2 MS-DOS----7000万人以上のユーザーが間違っているはずがない
- 9.3 OenVMS----UNIXへのアンチテーゼ?
- 索引
UNIXの考え方:簡単なまとめ
- スモール・イズ・ビューティフル
- 一つのプログラムには一つのことをうまくやらせる
- できるだけ早く試作を作成する
- 効率より移植性
- 数値データはASCIIフラットファイルに保存する
- ソフトウェアの梃子を有効に活用する
- シェルスクリプトを使うことで梃子の効果と移植性を高める
- 過度の対話的インタフェースを避ける
- すべてのプログラムをフィルタにする
定理1:スモール・イズ・ビューティフル
要約
- 小さなプログラムは分かりやすい
- 小さなプログラムは保守しやすい
- 小さなプログラムはシステムリソースにやさしい
- 小さなプログラムは他のツールと組み合わせやすい
NOTE
ここで言われる小さなプログラムとは、「機能セットの小さなプログラム」を指す。別にCode Golfのようなプログラムを推奨しているわけではない。
「小さなプログラムは他のツールと組み合わせやすい」はインターフェースが統一されたコマンドラインアプリケーション故のことだろうか?
定理2:一つのプログラムには一つのことをうまくやらせる
要約
- プログラムが本来提供する機能と本質的に関係無い機能は実装すべきではない
- 定理1:スモール・イズ・ビューティフルに反する為である
- プログラム(サブシステム)が機能的に独立していることで、システムを疎結合に保つことが出来る
NOTE
本文ではlsコマンドのレイアウト機能について言及している。lsコマンドの本質的な機能は、ディレクトリの内容を一覧表示する事でありレイアウトに関する機能は本質的なものではないので、別のプログラムとして実装すべきであるとしている。
定理3:できるだけ早く試作を作成する
要約
- 試作から学ぶ
- 早い試作はリスクを減らす
NOTE
試作以前の段階(設計書や要求定義書上にしかプログラムが存在しない状態)では、全ては憶測に過ぎず、しかも人によって解釈が異なることさえ起こり得る。早い段階の試作(プロトタイプ)作成によって、プロジェクト関係者の合意(解釈の一致)が期待される。
この項はアジャイル開発プロセスやXPの概念と一致している。まずは試作品を作成し、そこから得られたフィードバックを反映していく手法を推奨している。
人間による三つのシステム - システムの生誕から熟成まで
定理4:効率より移植性
要約
- 来年のマシンはもっと速いのだから、今無理をして効率を求めなくても良い
- 来年のマシンのアーキテクチャが変わると、今時点のハードウェアに依存したプログラムは動かなくなる
- 使われないプログラム程無価値なものはない
- 良いプログラムは死なず、ただ移植されるのみ。移植し易いコーディングを心掛ける。
NOTE
アーキテクチャの収斂やマルチプラットフォームなコンパイラや仮想マシン上で動作するプログラミング言語の登場で、移植性は今日ではそれなりに満足できる水準を得ていると思う。この本が書かれた当時は特定のアーキテクチャに依存したプログラムがゴロゴロしていた(リソース的な制約もあった)ので、殊更移植性を強調しているのだと思う。
定理5:数値データはASCIIフラットファイルに保存する
要約
- 数値データは全てASCIIフラットファイル(プレインテキスト)に格納されるべきである。
- バイナリファイルは禁止。特にベンダ固有形式の利用は厳に慎む。
- ベンダ固有のバイナリファイルの読み書きは特別なプログラムが必要だが、テキストファイルの読み書きに特別なプログラムは必要ない。或いは常に複数の選択肢が存在する。
- ベンダ固有のバイナリファイルの寿命はプログラムを提供する企業の寿命とほぼ等価であり、特定のプラットフォームへのデータの移植もベンダの裁量次第となるが、テキストファイルであればそれらのリスクは無いか、またはとても低い。
NOTE
データの移植性にはプレインテキストが最適であるという思想は、今日ではXMLに見ることが出来る。マイクロソフトでさえ、OfficeシリーズのフォーマットをXMLベースに転換した。
余談だがプレインテキスト主義者はExcel原理主義者を常に苦々しく思っている。
定理6:ソフトウェアの梃子を有効に活用する
要約
- ソフトウェアの梃子とは、既存のソフトウェアを最大限利用すること。
- 自分の仕事に他人の成果を取り込むことで、先人の努力を活かし、コードの有用性を高めることが出来る。
- 先人のソフトウェアは、より多くのアプリケーションに活かされて、より価値のある存在になるし、取り込んだソフトウェアも、投資が少なくて済む分だけ相対的に大きな収入を生む。
- 独自技術症候群と車輪の再発明を避け、真に価値あるソフトウェアを創造することに全力を注ぐべし。
NOTE
現在でも十分に通用する概念。最近ではRSSやWEBサービスAPIを利用したマッシュアップアプリがそれにあたるだろうか。
定理7:シェルスクリプトを使うことで梃子の効果と移植性を高める
要約
- 「定理6:ソフトウェアの梃子を有効に活用する」の威力を最大限に高める方法は、シェルスクリプト・パイプ・リダイレクションを組合せたときである。
- シェルスクリプトは他の言語よりも移植性が高い。
- シェルスクリプトはシェルが移植された環境ならどこでも動作するが、他の言語で書かれたプログラムはその保障はない。
NOTE
個人的にはシェルが移植できる環境なら、その他のプログラムが動作するのに必要なコンパイラやライブラリも移植できるのでは? とも思う。多分、現在よりもコンピュータの環境が多様だった時代のことなのだろう。
定理8:過度の対話的インタフェースを避ける
要約
- 対話的インターフェイスとは、ユーザーの入力を待つタイプのインターフェイス(GUIアプリは大半がこれに当てはまるのでは?)。
- 対話的インターフェイスは人間がボトルネックとなって、プログラムの処理効率を低下させる。
- 対話的インターフェイスは他のプログラムとの連携が難しい(定理6、定理7に馴染まない)。
- 反対にUNIXコマンドは人間との対話を放棄することで、主目的のタスクの達成に全力を注いでいる。
NOTE
GUI全盛の今日ではこの定理を単純に当てはめるのは少し難しいかもしれない。しかし、ソフトウェア開発の現場に限って言えば、でこの定理は今でも受け継がれている(自動ビルドや自動テストなど)。
クライアントアプリではこの定理を適用するのは難しいかもしれないが、サーバ側で動作するアプリケーションには現在でも完全に適用が可能(むしろ自動化が必須)。
定理9:すべてのプログラムをフィルタにする
要約
- 全てのプログラムはフィルタであるということ。
- これまでに触れてきた定理の根幹にあたる概念。
NOTE
GUIアプリでさえ、ユーザーからの入力をフィルタするプログラムの結合によって成り立っているという概念。故にプログラムはシンプルで無くてはならない。