Skip to content

Instantly share code, notes, and snippets.

@su-kun1899
Last active September 22, 2021 02:45
Show Gist options
  • Star 1 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save su-kun1899/e6cea8e1fc7e9383e6524dece5e44c04 to your computer and use it in GitHub Desktop.
Save su-kun1899/e6cea8e1fc7e9383e6524dece5e44c04 to your computer and use it in GitHub Desktop.
「UNIXという考え方―その設計思想と哲学」読書メモ

UNIXの開発者たちは、正しい解決策を徐々に構築しようとする。最初の努力が無駄になりかねないことを思い悩んだりはしない。

イントロダクション

  • UNIXは「ユーザーは、自分が何をしているか分かっている」との前提に立っている

第1章 UNIXの考え方

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

小定理

  1. 好みに応じて自分で環境を調整できるようにする
  2. OSのカーネルを小さく軽くする
  3. 小文字を使い、短く
  4. 木を守る(紙のドキュメントを嫌う)
  5. 沈黙は金
  6. 同時に考える
  7. 部分の総和は全体よりも大きい
  8. 90%の解を目指す
  9. 劣る方が優れている
  10. 階層的に考える

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

  • スモール・イズ・ビューティフル
  • 小さいプログラムは分かりやすい
    • 保守しやすい
    • システムリソースにやさしい
    • 他のツールと組み合わせやすい
  • 明日作られるものは今日作るものとは違う
  • ひとつのプログラムにはひとつのことをうまくやらせる
  • ひとつのことをうまくやれないのは問題の本質を理解していない

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

  • 学習曲線からは降りられない
  • 達人でさえ、変化が避けられないことを知っている
  • 「ソフトウェア開発に終わりはない、あるのはリリースだけだ」
  • 誰もが常に学び続けている
    • できるだけ早く試作を作成する
    • 試作によって学ぶ
    • 早い試作はリスクを減らす
  • 人間による三つのシステム
    • 若年期(若い設計)
      • 締め切りなど、追い詰められた人間が第一のシステムを創る
      • 正しくやっている時間などない
      • 役に立つが、枝葉が無視される
      • 一人か、せいぜい数人までの小さなグループで作られる
    • 成熟期(成熟した設計)
      • 三つの中で最悪
      • 第一のシステムの成功に多くの人が群がる
      • ほとんど使われない機能が追加され、膨れ上がる
    • 老年期(枯れた設計)
      • 第二のシステムで「火傷」した人が創る
      • オリジナルのコンセプトはそのまま残る
      • 第一のシステムと第二のシステムの最良の特徴を組み合わせる
      • 「正しく」やるための時間が与えられる
  • 第3のシステムの構築
    • 一般的なソフトウェアのアプローチ
      • システム設計を考える
      • 試作を完成して、仮説をテストする
      • 詳しい機能仕様書と設計仕様書を書く
      • コードを書く
      • ソフトウェアをテストする
      • 実地試験で見つかったバグと設計ミスを修正し、その都度仕様書を更新する
    • Unixのアプローチ
      • 短い機能仕様書を書く
      • ソフトウェアを書く
      • テストして書き直す。満足するまで繰り返す
      • 詳細なドキュメントを(必要なら)書く

第4章 移植性の優先順位

  • もっともパワフルなコンピューターはもっともよく使われるコンピューター
    • いつでもどこでも使える(スペックで劣ったとしても)ノートパソコンが最高かもしれない
  • 効率より移植性を選ぶ
    • ハードウェアの進化はめざましい
  • 良いプログラムは死なず、新しいハードウェアに移植されるのみ
  • ソフトウェア技術者にとっての柔軟性は、移植性といってもよい
  • 🤔 Webの隆盛を思い起こすなど

第5章 これこそ梃子の効果

  • 一人の力には限界がある
  • よいプログラマはよいコードを書く。偉大なプログラマはよいコードを借りてくる
  • 独自技術症候群を避ける
  • 標準に価値を付加する(付加価値)
  • コードを他者が梃子として使うことを認める
    • クローンの登場は止められない
    • 秘密主義は利用者の増加で不利
  • すべてを自動化する

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

  • 小さいものは扱いやすくて便利
  • 小さすぎると人間には馴染まない
  • 小さいものは多すぎると管理が大変
  • 対話的インターフェースは拘束的
  • 拘束的なプログラムはユーザーを人間と想定している
  • 最も早い人間でさえ標準的なコンピュータより遅い
  • すべてのプログラムはフィルタである
    • データは人間が作るもの
    • コンピュータはデータをある形式から別の形式に変換する
  • 入出力をハードワイアしない
    • stdin
    • stdout
    • stderr

第7章 さらなる10のUNIXの考え方

  • 好みに応じて自分で環境を調整できるようにする
    • ☹柔軟性が高すぎて学習コストが上がるような感じは苦手だなあ
  • ある人が解読できないことは、別の人にとっては効率的である場合がある
    • どんな職業でも省略が行われ近道が作られる
  • 動かせないデータは死んだも同然
    • 紙に印刷されたデータはもう操作できない
  • 沈黙は金
    • フィルタとして機能させる
  • 90%の解を目指す
    • ソフトウェアは妥協の産物
    • 完成することはなく、ただリリースがあるだけ

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

  • 小さなプログラムの利点
    • 分かりやすい
    • 保守が容易
    • 費用対効果が高い
    • システムリソースを効率的に使用できる
    • 他ツールと結合しやすい
  • 目的を絞る
    • ひとつのプログラムでひとつの問題を解決する
  • できるだけ早く試作する
  • ソフトウェアは作るものではなく成長していくもの
  • 効率より移植性を重視する
    • 移植できるものは生き残る
    • データも移植可能にする
  • 独自技術症候群を絶対に避ける
  • すべてのプログラムをフィルタと考える
    • 拘束的インターフェースにしない
    • プログラムはデータを作らない。変更するだけ

第9章 UNIXとその他のオペレーティングシステムの考え方

  • UNIXの理念の本質は柔軟であり続けること
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment