UNIXという考え方

久しぶりに読んだので軽くメモ

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

やっぱりこの本は「スモール・イズ・ビューティフル」「一つのプログラムには一つのことをうまくやらせる」 に全てが詰まっていると言っても過言ではないと思う。

一つのことをうまくやるようにプログラムを作れないのであれば、おそらく問題をまだ完全には理解していないのだろう

なるほどなーと前も思った気がする。 機能実装する上で何を一番解決しなければならないか？の問題の切り分けから入るのは当然だけど、細かく実装して組み合わせて いくアプローチはテストも描きやすいし、何より見やすい。

UNIXという考え方

第一章

• unixの作者：ケン・トンプソン

  1.1 UNIXの考え方：簡単なまとめ

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

重要度の低い10の小定理 1. 好みに応じて自分で環境を調整できるようにする 2. オペレーティングシステムのカーネルを小さく保つ 3. 小文字を使い、短く 4. 森林を守る 5. 沈黙は金 6. 同時に考える 7. 部分の総和は全体よりも大きい 8. 90%の解を目指す 9. 劣る方が優れている 10. 階層的に考える

第二章

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

2.1 [定理1]: スモール・イズ・ビューティフル

• プログラムを描く時は小さなものから始めて、それを小さなままに保っておく。
• 現実には、その場限りの小さな解決策でも解決できない問題はそれほど多くない。ほとんどの場合、問題を完全に理解していないから巨大な解決策を実装しようとしてしまう。
• 例）ファイルAをファイルBにコピーするプログラム

2.3 [定理2]: 一つのプログラムには一つのことをうまくやらせる

• そのコードが本当に必要なのかを常に意識しておくべきだ
• 例）ls
  • 純粋なlsは、ディレクトリの中のファイル名を順不同で、以下のように並べる

$ ls /usr/home/gancarz
txt
doc
scripts
...

• しかし、大抵のバージョンは以下のように出力する

$ ls
txt doc scripts ..
...

• ファイル名を複数の列に整理させて表示することは、一見、気の利いたやり方に思えるが、ディレクトリの内容を表示するという本来の機能とはほとんど関係がない。それにもかかわらず、列整理のコードが追加されている。簡単に複雑になる。

• 一つのことをうまくやるようにアプリケーションを書けば、それは必然的に小さなプログラムになる

• その意味で、定理1と定理2は互いに補う関係にあると言える
• 一つのことをうまくやるようにプログラムを作れないのであれば、おそらく問題をまだ完全には理解していないのだろう。

第三章

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

3.1 [定理3]: できるだけ早く試作を作成する

• 多くの人が考える「正しい設計作法」と真っ向から対立している
• プロジェクトの前進には全員の合意が必要だ。試作は、具体的に目標を示すことで全員の合意を醸成する

早い試作はリスクを減らす

• 製品の完成後に100万のユーザから背中を向けられるよりも、少数から批判を受ける方がはるかにいい
• 試作は目的に向かう手段であり、目的そのものではない。

UNIX開発者は、詳細な機能仕様書や設計仕様書について見方が異なる 1. 短い機能仕様書をかく 2. ソフトウェアをかく 3. テストして書き直す。満足できるまで、これを繰り返す 4. 詳細なドキュメントをかく

目標についてわかっていることをいくつか書き留めるだけで、残った時間をシステムの構築に使う。 正しい方向に向かっているのかどうかをどのようにして判断するのだろうか？実はわかってない。伝統的な方法を取っている人々も同じくわかってない。であれば、設計から完成物を判断するより実際に動くものをレビューする方がよりいいものが作れる。

第四章

移植性の優先順位

4.1 [定理4]: 効率より移植性

• ハードウェアと切り離すことができないソフトウェアは、そのハードウェアが競争力を持ち続ける間しか価値を維持できない。ハードウェアの優位が失せるとソフトウェアの価値も劇的に下落する。

4.3 [定理5]: 数値データはASCIIフラットファイルに保存する

• データが価値を持ち続けるためには、必要な時には移動しなければならない

第五章

これこそ梃子の効果！

5.1 [定理6]: ソフトウェアの梃子を有効に活用する

• よいプログラマはよいコードを書く。偉大なプログラマはよいコードを借りてくる
• 自分の仕事に他人の成果を取り込む事で、先人の努力を生かし、コードの有用性を一段と高める事ができる。
• 独自技術症候群(車輪の再発明)を避ける

5.2 [定理7]: シェルスクリプトを使う事で梃子の効果と移植性を高める

• 省略

第六章

対話プログラムの危険性

6.1 [定理8]: 過度の対話的インターフェースを避ける

• UNIX環境では、どのコマンドも単独では存在できない。様々な時点で、コマンド同士が対話する。拘束的ユーザーインターフェースでは、この複数のコマンドによる能力が阻害されてしまう

6.2 [定理9]: 全てのプログラムをフィルタする

• 省略