アットウィキロゴ

作成日 : 2007/11/06 H.Naito
更新日 : 2007/11/06 H.Naito


勉強の成果!? ( メモ ) を残します。 by 内藤

この本の目的とするところ


感想

( まだ読みかけだけど・・・ )
論点が明確で主張しているポイントが感覚に合う。
しかし、ほとんどが同じ事柄への説明を言葉を変えて説明しているので、冗長な部分が多分にある。
また、一方で、文章の展開に論理的な飛躍があったり、今語られている内容とは関係のない内容が突然まぎれることがある。
翻訳の問題というよりは、著者の論理展開の問題だと思う。

Unix の設計思想の部分を分解して説明している。Unix の設計思想は、他のソフトウェアの設計思想にも適応することで、より柔軟なシステムが
構築できるのではないかと思う。

Java などのマルチプラットフォーム思想や Write once, run anywhere という発想と反する部分があるように感じるが、上手く組み合わせることで
汎用性の高い、柔軟なシステムの構築が可能になるかもしれない。

この辺については、さらに研究を深めたい。
2007/11/06 内藤

イントロダクション

  • UNIX の創造者たちは、「ユーザははじめからコンピュータを使える」という前提をたて、「何をしているかわからないのなら、ここにいるべきではない」というアプローチを選んだ。
    • その結果として、初期の Unix は、広汎な支持を得ることに失敗した。
    • しかし、1980年初頭あたりから、「どのオペレーティングシステムよりも柔軟で移植性に富み、性能の高いオペレーティングシステムができる」という噂のもと、コンピュータ業界に浸透していった。

第1章 : UNIX の考え方 : たくさんの登場人物たち

  • Unix は、初期バージョンに MIT で開発された Multics から多くの特徴を取り入れた。( ex. タイムシェアリングシステム )
  • Unix の発明者、ケン=トンプソンが採用した方法( 後の Unix システム開発者たちの先例となる )
    • よいプログラマは素晴らしいソフトウェアを書く。
    • 偉大なプログラマは、その素晴らしいプログラムを「盗む」( 独自技術症候群にならない。アイディアをみなで分かち合う )
    • 偉大なプログラムは、追い詰められた人間が書く。
    • あるアプリが「実用的」で「実現方法を知るエキスパートが回りにいない」で、それを「『正しく』やる時間がない」場合に、すばらしいソフトウェアが書かれる可能性が高くなる。

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

  • 第2章以降の簡単な解説。

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

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

  • プログラムを書くときは、小さなものから始めて、それを小さなままに保っておく。シンプルさを追求する。
  • 小さなプログラムを組み合わせることで、大きくて複雑な作業を簡単に処理する。

2.2 : やさしいソフトウェア工学

  • 小さなプログラム = 一つのことを上手くこなすことを目的としたプログラム( 目的の作業に直結したプログラム )
  • 小さなプログラムは可読性が高い。
    • 書かれているアルゴリズムが簡潔なので、わかりやすい。
  • 小さなプログラムは保守がしやすい。
    • そのプログラムで実行する処理が明確なので、保守しやすい。
  • 小さなシステムはシステムリソースにやさしい
    • 実行イメージがわずかなメモリしか占有しない( 軽いプロセスとして実行される )
    • スワップやページングが劇的に減り、性能が大幅に向上する
  • ちいさなプログラムは消費するディスク容量も小さい

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

  • 一つのことをうまくやるようにアプリを書けば、それは必然的に、小さなプログラムになる。
  • 現在の仕事に集中することによって、やろうとしていることの本質をつかめる。
  • 一つのことをうまくやるようにプログラムを作れないのであれば、おそらく問題をまだ完全には理解していない。

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

  • エンジニアという職業は、たいていの人間が学び続けているという良い例だ。
  • エンジニアたちが自分たちの専門分野について完璧な知識をもっていたら、品質保証部門は必要ない。
  • ソフトウェア技術者たちは、特に急激な学習曲線を求められる。しかし、ソフトウェア技術者が何かを習得するには、長い時間がかかる。
  • 仕様変更はよくあることだ。最初は上手くいかないと考えて、開発の初期段階で変更を行う方が安上がりだ。
  • ソフトウェア開発は、他の開発業種に比べてより多くの改訂と修正を必要とする。それはソフトウェアが抽象的な考えを扱うからだ。

3.1 【定理3】できるだけ早く試作を作成する

  • 試作の目的は、「第三のシステム」に早く到達することだ。 ※ 第三のシステムに関しては後述。
  • 試作の利点
    • ある方針の適否を早期に発見できる
      • 何がうまくいくかがわかる
      • 何がうまくいかないかがわかる
    • 動くはずだという憶測ではなく、具体的な目標をプロジェクトのメンバーに伝えることができる
    • ユーザにプレゼンすることで、設計上のミスを発見できる
  • 試作の欠点・懸念点
    • 設計を完全にしてからコーディングをしろ!!という一般論と対立している。

3.2 人間による三つのシステム

  • 3.3、3.4、3.5 への導入部。人間の活動時期を3つの時期に分けられるように、システムの成熟も3つの時期に分けられる。

3.3 人間による第一のシステム

  • 時間的に追い詰められた人間が第一のシステムを創る。
  • 追い詰められた開発者は、当然、「正しく」やれる時間がない。そこで型破りな即興を講じ、細かい点は次期リリースの時に機能追加しようとする。
  • 第一のシステムは、一人か、またはせいぜい数人からなる小さなグループで創られる
    • [理由] まわりの人間に理解ができないから
    • [理由] 第一のシステムは失敗する確立が極めて高いから
    • チームが大きくなりすぎると、意思疎通がとりにくくなり、生産性が低下する。個性の衝突も起きる。メンバーそれぞれの思惑を実行に移す。縄張りができる。
  • 第一のシステムの特徴
    • プログラムの単純さと速度を最優先にしているので、性能がいい。
    • プログラムの移植性を無視している。
    • 実装された機能に対する仕事だけはできるが、それ以外の仕事はほとんど何もできないソフトウェア。
    • 第一のシステムのコンセプトは人間の想像力を刺激する

3.4 人間による第二のシステム

  • 「専門家」が、第一のシステムで証明されたアイデアを用いて第二のシステムを作る
  • 専門家たちの委員会による設計が行われる。( 公開の場で進められる ) が、重要な問題で意見の一致が見られることはない。
    • その結果、様々な人たちの様々な思惑がつまった、機能は多いし、柔軟性もあるが、「重い」ソフトウェアが作成される。

3.5 人間による第三のシステム

  • 第三のシステムは第二のシステムへの反抗から生まれる
  • 第一のシステムのコンセプトは、第三のシステムが登場するころには、万人に受け入れられ、「それは普通の方法だ」と認められている。
  • 第三のシステムでは、本当に必要な機能だけが残され、そこそこのリソースで多くを達成できるようになる。

3.6 第三のシステムの構築

  • Unix 的な開発プロセスは以下のようなもの
    • 短い( 長くて3~4ページ )機能仕様書を書く
    • コーディングする
    • 目的を達成できるまで、テストして書きなおす。
    • 詳細なドキュメントを( 必要なら )書く
  • 従来型の開発プロセスは以下のようなもの
    • システム設計を考える
    • 試作を作成して、仮説をテストする
    • 詳しい機能仕様書と設計仕様書を書く
    • コーディングする
    • テストする
    • バグと設計ミスを修正し、その度に仕様書を更新する
  • 設計は重要だが、設計の細部は都度かわるものなので、取り掛かる前に、詳細を文章化していても意味がない。

第4章 : 移植性の優先順位

4.1 【定理4】効率より移植性

4.2 事例研究 - Atari 2600

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

4.4 事例研究 - あるUNIXプログラマの道具袋


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

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

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


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

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

6.2 【定理9】すべてのプログラムをフィルタする

6.3 UNIX環境 : プログラムをフィルタとして使う


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

7.1 (1) 好みに応じて自分で環境を調整できるようにする

7.2 (2) オペレーティングシステムのカーネルを小さく軽くする

7.3 (3) 小文字を使い、短く

7.4 (4) 木を守る

7.5 (5) 沈黙は金

7.6 (6) 並行して考える

7.7 (7) 部分の総和は全体よりも大きい

7.8 (8) 90パーセントの解を目指す

7.9 (9) 劣るほうが優れている

7.10 (10) 階層的に考える


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

8.1 UNIXの考え方 : 総括


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

9.1 Atariホームコンピュータ - 芸術としての人間工学

9.2 MS-DOS - 7000万人以上のユーザが間違っているはずがない

9.3 OpenVMS - UNIX へのアンチテーゼ?



最終更新:2007年11月06日 15:08