mrasu’s blog

読んだ物の内容など

UNIXという考え方(1章 ~ 5章)

時間が出来たので、今まで読みたかった本を読んで、内容をまとめます。
今回は「UNIXという考え方 - その設計思想と哲学」です。
新卒ソフトウェアエンジニアのための技術書100冊 - クックパッド開発者ブログといった「プログラミング系のお勧め本」として紹介されているので買いました。

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

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

UNIXの根底に流れる考え方を書いた本で、特定の技術を書いたものではなく考え方を書いた本。


1章

導入
UNIX哲学の一覧を紹介している

  1. small is beautiful
  2. 一つのプログラムには一つのことをうまくやらせる
  3. 出来るだけ早く試作する
  4. 効率より移植性を優先する
  5. 数値データはASCIIフラットファイルに保存する
  6. ソフトウェアを梃子として使う
  7. シェルスクリプトによって梃子の効果と移植性を高める
  8. 過度の対話的インタフェースを避ける
  9. 全てのプログラムをフィルタとして設計する

2章

small is beautiful

大抵のプログラムはやっていることが多すぎる。
ファイルをコピーするためのチェック処理や対話はコピー自体の機能とは関係がないのだから、コピーに集中すべきだ。

小さなプログラムのメリット

  1. 理解のしやすさ
  2. 保守(機能拡張)のしやすさ
  3. 要求リソースの小ささ
  4. 連携の良さ→ 組み合わせによる拡張の容易性

1つのプログラムは1つのことをうまくやらせる。

プログラマはついつい、「多機能性」をめざしてしまう。(オプションが増えるのが良い例)
個別プログラムのために存在する多機能性は、別プログラムに移植できないために同じ機能を作るときに車輪の再発明を強制してしまう。

例えば、lsコマンド。
1行1ファイルで出せばよいものを、1行に複数ファイルを表示し、オプションとして1行1ファイルをサポートしている。
別プログラムで1行複数ファイルに成形するプログラムを書けばよいものを・・・

3章

達人であっても、必要なものはわからない。わかっているのは「変化するだろう」ということ。
変化の範囲は膨大で、学習もまた終わらない。
仕様(要求)は常に変化するのだから「終わりはない。リリースがあるだけだ」

できるだけ早く試作を作成する

試作から学び、試作からヒアリングする
システムには成熟度によって3様態がある

  1. 「できる」ことを重視し、機能性を捨てて最小限のものを「完成」させた状態。
    少数の者により作成される。
    作成した物が他者に評価されることで次のステップに進むことが出来る。
    熱狂を伴い作成され、他者を熱狂させる
    「夢と希望が詰まった」が作られる
  2. 機能性を拡張させ、性能を犠牲にする
    専門家が集合し、必要に思える機能を追加する。(完成を優先させたことによる欠点を除外する)
    追加された機能には、使われない機能も存在するし、使いづらくなるところもある。
    「夢から目が覚め、熱狂が覚める」システムが出来上がる。
  3. 常識となったものを完成させる
    第二段階で多くの人が使うことにより「やけど」した体験から真の完成を目指す。
    必要なもの、躓いたところを学習しているので洗練されたものが出来る。
    この時期にはオリジナルのコンセプトが「常識」となっている。

プログラム作成の流れは多くのシステムに存在するが、UNIXとそれまでの到達フローには違いがある。
伝統的フローでは

  1. 仕様を決める
  2. 詳細な設計書を書く
  3. コードを書く
  4. テストする
  5. 修正し、設計書を書きなおす

UNIXでは

  1. 仕様を決める
  2. 簡単な仕様をKラック
  3. ソフトウェアを書く
  4. テストする
  5. (必要であれば)詳細なドキュメントを書く

のように、ウォーターフォールアジャイルな関係。
UNIXでは「とにかく、使ってもらって粗を出す」

4章

効率より移植性

  1. 効率と移植性は対立関係にある
  2. 現在の最先端を行こうとすると、効率を重視するべきだが、現在は短い
  3. 移植性があれば、移植に使用する時間を他のことに注げる

バイナリではなく、文字列で保存する

バイナリにすると移植性が悪くなる。
共通フォーマットではなく、独自フォーマットであり、別システムはそのフォーマットをサポートしていないから。
文字列を使えば、パイプを通して、既存のライブラリに直結でき、移植プログラムを書く必要はない。
UNIXを使っている限り。

5章

梃子を使う

ソフトウェアを一人で作るのではなく、協力者を使おう
独自技術で再実装するのではなく既存にあるものを利用することで、進歩のスピードに合わせることが出来、標準にも合わせることが出来る。
他人にコードを公開する事、他人の変更を取り入れることによって、自分の時間を節約できる。
自動化して機械にやらせれば、他のことに費やせる時間が増える。

シェルスクリプトを使う

シェルスクリプトはcで実装するよりも早いし、cで実装されたものを簡易に実行しつなげることが出来る。
コンパイル時間もかからない。
時間がかかるのは、ロードタイムだが、速度を求める場合にロードの時間を短縮するのではなく、他の場所に短縮できる場所があるはずだ。
cより遅くとも移植性と車輪の再発明を回避することを優先すべきだ。