lasciva blog

開発して得た知見やwebビジネスのストック

「UNIXという考え方」の概要、感想

読書 CS

概要

  • 「UNIXという考え方」気になった点のメモ
  • 当然だと思ったことは一部省略

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

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

基本的な定理

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

1. スモール・イズ・ビューティフル

  • 小さなプログラムはシステムリソースにやさしい
    • わずかなメモリしか占有せず、OSもメモリを割り当てやすくなる
    • メモリをあまり必要としない一方で、CPUパワーを追加投入すると効果が得られる。
  • 他のツールと組み合わせやすい
    • 「あらゆる不足の事態に対応できるように」という誤った考えのもと、大きなプログラムを書きがち。
    • しかし、将来現れる新しい形式は予測できず、時代遅れになってしまうことも。
    • UNIXでは未来の予測は初めから諦めてる。

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

  • lsコマンドは、整列機能があるがこれは余分な機能
    • ウインドウの幅が変わった場合など、色々想定しないといけなくなって複雑になるので、切り出すべき
  • ディレクトリ内容を1行に1ファイルずつ書き出すことがなすべき機能

3. できるだけ早く試作する

  • 人間による3つのシステム
    1. 第一のシステム
      • 追い詰められた人間が創ったシステム
      • 無駄がなく、俊敏
      • 追い詰められているので「正しく」やる時間がなく、規則を破りながら、重要な部分だけに集中して進められる
      • 共通のビジョンとシステム完成の共通目的のため、高揚感のなか少人数で進められる
        • メンバーが増えると、生産性が下がり実現性が下がる
      • コンセプトが人間の想像力を刺激・想起させ、第二のシステムを生む
    2. 第二のシステム
      • 「専門家」が第一のシステムで証明されたアイデアを用いて第二のシステムをつくる
        • 正しく考え、つくる余裕のある人間が現れる
      • 委員会が設計する
        • 全員が同意にいたることはなく、参加者の承認欲求を満たす必要がある
      • 機能増加のために、遅くなる
      • 「柔軟性、豊富なオプション、拡張性」 が市場で称賛される
      • 皮肉なことに、最悪なのに一番市場で支持される
    3. 第三のシステム
      • 第二のシステムで「火傷」した人がつくる
      • 第一のシステムの性能の良さと、第二のシステムの機能性の特徴を組み合わせる
  • 第三のシステムをつくるには
    • UNIX開発者の進め方
      1. 短い機能仕様書を書く
      2. ソフトウェアを書く
      3. テストして書き直す。満足できるまで、これを繰り返す
      4. 詳細なドキュメントを（必要なら） 書く
    • このように進めることで、第一のシステムをユーザに見てもらい、フィードバックが得られる
    • 効率的に、第三のシステムに近づける
    • 詳細な文書化は反復的な修正が行われたあとに行うべき

4. 効率より移植性を優先する

  • ハードウェアに進化は凄まじいので、次のハードウェアでも動くことが重要に
  • C言語よりもシェルスクリプトの方が移植性が高い
  • 最も効率の良い方法は、ほとんどの場合移植性に欠ける
    • ハードウェア依存のコードになるため
  • 命令に関しては、保証されるがデータに関しては定理5で保証する

5. 数値データはASCIIフラットファイルに保存する

  • 動かせないデータは死んだデータ
  • あるバイナリ形式から別のバイナリ形式に変換する手間が省ける
  • 簡単に読めて編集できる

6. ソフトウェアを梃子として使う

  • 他人のモジュール等を効率よく切り貼りする
  • 不要な手作業を全部自動化する

7. シェルスクリプトによって梃子の効果と移植性を高める

  • 移植性が高い
  • 書くというよりかは、先人のスクリプトを再利用する

8. 過渡の対話的インターフェースを避ける

  • 対話的なインターフェースは他のコマンドを実行できなくなるという観点で、「拘束的」なため良くない。
  • 数多くの小さいモジュールから構築したい一方で、ソフトウェアを使いやすくするにはモジュールが多いと扱いにくくなるジレンマ
  • コンピュータの能力を最大限に引き出すには、拘束的なインターフェイスだと人間の操作がボトルネックとなる
  • ユーザのコマンドパーサの実装コストが高い
  • スケーラビリティに欠ける
  • 相手を人間だと仮定してるので、ソフトウェアの梃子の効果を利用できない

9. すべてのプログラムをフィルタとして設計する

  • ソフトウェアの本質は、データを処理することで、生成することではない。
    • その能力を最大限に発揮するには、プログラムをフィルタとして動作するように設計すべきだ。
  • プログラムはデータを作らない、人間がつくる
    • コンピュータは情報源を持たない
    • 収集とフィルタリングを効率よく行う道具にすぎない
  • フル活用するために、stdioに則る
    1. データ入力にはstdinを使用する
    2. データ出力にはstdoutを使用する
    3. 帯域外情報にはstderrを使用する

小定理

伝統的な立ち位置で、UNIXプログラマが賛同する程度のレベル感のもの。

  1. 好みに応じて自分で環境を調整できるようにする
  2. OSのカーネルを小さく軽くする
    • アプリケーションの効率性を図り、コアな部分にOSに関係のないコードを交えてファットなものにしてしまうと、バグが発生した際にOS全体に影響が及んでしまう
  3. 小文字を使い、短く
  4. 森林を守る
    • 紙のドキュメントを嫌う。
    • 紙はデータの死亡証明書
  5. 沈黙は金
    • パイプを利用するためにも、無駄な出力は避けるべき
  6. 並行して考える
    • 小さく分解した仕事を同時に実行することで、効率化を図る。
  7. 部分の総和は全体よりも大きい
    • 小さい部品を集めて大きなアプリケーションを作るほうが、大規模プログラムを単体で構成するよりも柔軟性に富み、したがってより役に立つ。
    • 先のことを考えても、小さい部品の集合によるアプローチの方が有利だ。
  8. 90%の解を目指す
    • 100%を目指すよりも、90%を目指す方が効率的で、費用対効果が高い。
  9. 劣るほうが優れてる
    • 生き残るのは「最大公約数」的なシステム。
  10. 階層的に考える

所感

  • 当然だが、アプリケーション開発に適用できるところも多かった。
    • 小さくモジュール化していくところなどは、オブジェクト指向と似ている。
    • 「90%の解を目指す」のコスト感覚も、サービス開発と同じだと思った。
  • 移植性は普段は全く気にかけることがなかったので、気付きが多かった。
  • 「人間による3つのシステム」は、ブロックチェーン界隈のコミュニティを見ていて通ずるものがあると思った。
  • 2001年に出版されたこともあって、やや古く感じるところも多少あった。
  • フィルタとして設計している部分や、対話的なインターフェースを避けているところは美しいと思った。
    • 過度なところもあるようにも感じたが、単純性を一貫させてるが故にこれだけ長年に渡ってスケーラビリティを持って存在しているのだと思う。

https://amzn.to/2KIwrDcamzn.to