「UNIXという考え方」

「UNIXという考え方―その設計思想と哲学」の気になったところの抜粋。

UNIXという考え方―その設計思想と哲学

0. イントロダクション

• UNIXの設計者たちは「何をしているか分からないのなら、ここにいるべきでない」という不親切きわまりないアプローチを選んだ

1. UNIXの考え方：たくさんの登場人物たち

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

2. 人類にとっての小さな一歩

• この世には、大きなプログラムを書くことを生きがいにしているソフトウェア技術者がいる。自分以外の誰にも理解できない大きなプログラムを書くことが「職の安定」につながると考え、書いたアプリケーションプログラムの大きさが、プログラマとして器の大きさを決めると信じているのだ
• 巨大で複雑なプログラムの開発者は、「将来が予測可能で、そして現在と大きく変わらない」という勝手な思い込みを前提としている
• 一方、小さなプログラムの開発者は、未来の予測などは最初から諦めている。彼らの予期することは、明日作られるものは今日作っているものとは違うということでしかない
• 最良のプログラムは生涯において一つのことをうまくやるプログラムだ。プログラムはメモリにロードされて、所定の働きをし、次の単一機能のプログラムの実行のために道を譲る
• 最初からうまくやろうとするより、「最初はうまくいかない」と考えて対処した方がより賢明といえるだろう。後で大幅な変更に取りかかるよりは、開発の初期段階で変更を行う方がはるかに安上がりだ

3. 楽しみと実益をかねた早めの試作

• UNIXの開発者は、詳細な機能仕様書や設計仕様書についての見方が異なる。目的は伝統的な方法論と同じだが、物事を進める順序が違う
• 短い機能仕様書を書く
• ソフトウェアを書く
• テストして書き直す。満足できるまでこれを繰り返す
• 詳細なドキュメントを（必要なら）書く
• 伝統的な方法では、膨大で退屈な文書をユーザーに示し、システムの完成図を読み取ってもらおうとするのに対し、UNIXプログラマは実際に機能するアプリケーションを示す
• 十分な設計をせずに大規模システムのコーディングに取りかかれと言っているのではない。適切な目標を見極めるためにも、ある程度の熟練は必要だ。ただ、設計の細部はいろいろと変わるものであって、取りかかる前にすべての詳細を文書化しておいても役に立たないということが言いたいのだ

4. 移植性の優先順位

• 移植可能なソフトウェアは、書かれたその日から大きな価値を持っている
• よいプログラムは死なず、ただ新しいハードウェアに移植されるのみ
• 移植性が重要であることは明らかだ。プログラムを移植しやすく、データを持ち運びやすくしておくことで、ソフトウェアに長期的で具体的な価値が生まれる
• 新しいプラットフォームが続々と現れてくる現状では、移植できないと生き残ることはできない。業界の新発表によってソフトウェアの価値がゼロになってしまうのを見守る代わりに、最初に計画しておくことだ。移植性を最優先に設計するのだ

5. これこそ梃子の効果！

• すべてのコードを自分で書くことが職の安定につながると考えるプログラマもいる。「良いコードを書くから、必ず仕事がある」というわけだ。しかし、ここで問題は、良いコードを書くには時間がかかることだ。アプリケーションで使用するコードの一行一行を全部自分で書いているのでは、仕事が遅く効率の悪いプログラマをみなされかねない
• あるグループが他グループのアプリケーションの価値を認めない、市販品を使うよりゼロからの開発を好む、他人が書いたソフトウェアは、他人が書いたものだから使わない・・・このような症状が見られたら独自技術症候群を疑ったほうがいい
• 最も成功する会社は、他からソフトウェアを「借用」し、独自拡張を行う会社だ。このことを業界用語で「付加価値をつける」という
• 最も成功するソフトウェアはどれかと言えば、最も多くのコンピュータで使われているソフトウェアということになる。この点で秘密主義の企業は大きな不利を背負うことになる

6. 対話的プログラムの危険性

• アプリケーションは、相互にうまく意思疎通ができる小さな部品の集まりとして作った方が高い価値を持つ。人間と対話がうまくいくかどうかは問題ではない
• 自分のソフトウェアがどう使われるのか。予測できる人などいない。プログラマにできる最善のことは、インタフェースをできるだけ柔軟にし、現在分かっている範囲内でできるだけ多くの事態に備えておくことだ。明日のことは、明日に任せるより仕方がない
• 「そういうことをするためのソフトウェアじゃありません」と何度電話口で言ったことだろうか。ユーザーがソフトウェアをどう使うかは、決して予測できない。設計者である自分の意図に全員が従ってくれるはずだ、などと絶対に考えてはならない

7. さらなる10のUNIXの考え方

• ほとんどのソフトウェアは妥協の産物だ。完成することはなく、ただリリースがあるだけだ。ソフトウェアが名前の通り、いつまでも「ソフト」ウェアにとどまり、ハードウェアになれない以上、100パーセントの解を実装するソフトウェアはありえない

8. 一つのことをうまくやろう

• 一つのことをうまくやるプログラムは、他のアプリケーションの中でも比較的簡単に再利用できる。できることとできないことが明確で、大きなプログラムにありがちな曖昧さがない
• 世界のソフトウェアは絶えず進化し続けており、誰も学習曲線から逃れられない
• 人間にできることは、せいぜい明日のニーズは変化しうるという前提に立って、今日のニーズを満たすソフトウェアを作ることくらいだろう