UNIX という考え方
スモール・イズ・ビューティフル
- 一つの巨大なプログラムにしようとする誘惑に負けない
- 書いたプログラムの大きさがプログラマの器の大きさを示すわけではない
- 「あらゆる不測の事態に対応できるように」という誤った考えは捨てろ。未来の予測は諦めろ。
- そもそも、小さ なプログラムならあらゆる変化に直ちに対応・修正できる。
- ほとんどの場合、問題を完全に理解していないから巨大な解決策を実装しようとするのだ
メリット
- 小さなプログラムは分かりやすい
- 小さなプログラムは保守しやすい
- 小さなプログラムはリソースを浪費しない
- 小さなプログラムは他のツールと組み合わせやすい
一つのことをうまくやる
- その機能が本当に必要なのか常に懐疑的に考えろ
- 「しのびよる多機能主義」を遠ざけろ
- ひとつのことをうまくやるように作れないのなら、問題を完全には理解していない証拠である
できるだけ早く試作をつくる
- 最初はうまくいかないと考えて対処するのが賢明
- 試作することで何ががうまくいき何がうまくいかないのかが分かる
最速のアプローチ
- 短い基本設計書を書く(詳細設計書はまだ書かない)
- コードを書く
- テストして書き直す。満足できるまで繰り返す。
- 詳細設計書を書く(必要なら)
従来の方法との違い
- 伝統的な方法 --- 膨大な文書をユーザに示して完成図を読み取ってもらいながら作る
- 最速の方法 --- 実際に機能するアプリケーションをユーザに示しながら作る
- 目標についてわかっていることをいくつか書きとめ、残った時間はシステムの構築に使う
- ある程度の熟慮は必要だが、取り掛かる前にすべての詳細を文書化しても役には立たない
効率より移植性
移植性を保つためのコストは後から十分に報われる。移植可能でないものは単にこの瞬間においてのみ効率が良いにすぎない。
- C 言語はシェルスクリプトよりもハード依存の要素が多く、移植性が低い。僅かなスピードのために移植性を犠牲にするな。
- ハードウェアは年々進化するので、新しいハードに移植さえできれば動作スピードは年々速くなる。
- 高効率の方法はほとんどの場合移植性に欠ける
- 移植性が高ければ移行費用を抑えられ、新機能の開発にリソースを向けられる。ライバルに勝てる。
データは ASCII フラットファイルに保存する
- もっとも移植性の高いデータ形式である
- もっとも広く使われ ている
- 簡単に読める、編集できる
- grep や awk などの UNIX ツールが使える
- 移植できないもの(バイナリファイル等)の一生は短い
ソフトウェアの梃子を有効に活用する
- コードは書くな、借りてこい
- NIH(Not Invented Here)症候群=独自技術症候群に陥るな
- 優れた組織で陥りがち
シェルスクリプトを使うことで梃子の効果と移植性を高める
数行のシェルスクリプト = 数万行の C 言語コード
シェルスクリプトを使えば「簡単なプログラムすら書けない」プログラマも含め、全員が勝者になれる