最近、基礎的なもの（考え方、原則、作法等）に興味がありこの本を手に取りました。 少し古い本ですが読んでみてとても面白かったので感想を書きたいと思います。
- 作者:Mike Gancarz
- 出版社/メーカー: オーム社
- 発売日: 2001/02/01
- メディア: 単行本
感想
UNIXの考え方に「偉大なプログラマは、その素晴らしいプログラムを盗む（借りてくる）」というものがあります。
要はすでに良いものがあるんだったらそれを使わせてもらおうということです。
UNIXはパクリ推奨なのか。。と思いましたが読んでいくとなんだかそうではないことに気が付きました。
どういうことかというと、先人のソフトウェアはより多くのアプリケーションに活かされて、より価値のある存在となるし、それを取り込んだソフトウェアも投資が少なくて済む分、相対的に大きな収益を生み出すことになり、どちらにとっても好ましい状況になるということです。
先人のソフトウェアはより多くのアプリケーションに活かされてより価値のある存在になるという考え方はとても良いなと思います。
自分が作成した最高のプログラムは誰にも真似されたくないし、絶対に公開しないという方ももちろんいらっしゃると思います。
しかしUNIX的にはそれを公開して、多くのアプリケーションから使われることでこそ価値が認められると言っています。
UNIXは小さいプログラムをたくさん作りそれらを互いに連携させて、大きなアプリケーションを作り上げます。
世界中のプログラマーが小さいプログラムを公開していけば、日々使用されていく中で価値のある小さいプログラムが選別され、自分のアプリケーションに安全に取り込むことができます。
この思想が現代でも脈々と受け継がれた結果、今日のGithubで続々と新しいリポジトリが公開されているのかなーと思いました。
個人的に面白かった章
第2章 人類にとっての小さな一歩
2.1 定理:1 スモール・イズ・ビューティフル
- プログラムを書くときは小さなものから初めて、それを小さなままに保っておく。簡単なフィルタプログラムでもグラフィックスパッケージでも、巨大なデータベースを構築するときでも、同じく小さな実用的なプログラムにする
- 小さなプログラムは単独では大したことができない。しかし、それらを様々に組み合わせることで真のパワーを発揮する
2.3 定理:2 一つのプログラムには一つのことをうまくやらせる
- 最良のプログラムは障害において一つのことをうまくやるプログラム
- 現在の仕事に集中することによって、やろうとしていくことの本質をつかめる
- 一つのことをうまくやるようにプログラムが作れないのであれば、おそらく問題をまだ完全には理解していないのだろう
第3章 楽しみと実益をかねた早めの試作
- 最初からうまくやろうとするより、「最初はうまくいかない」と考えて対処したほうがより懸命といえる。後で大幅な変更に取り掛かるよりは開発の初期段階で変更を行うほうが遥かに安上がりだ
3.1 定理:3 出来だけ早く試作を作成する
- 端末が熱いうちにキーボードを打つ
- あるアイデアがものになりそうかどうか、目に見える現実的な場面でテストするには試作が一番だ
- 試作によって学ぶ
- 試作によってなにがうまくいくかがわかり、さらに重要なことに何がうまくいかないかがわかる
- 早い試作はリスクをへらす
- 早いうちから誤りを除く作業を始めておけば、それだけ早く高品質の最終製品にたどりつく
3.2 人間による三つのシステム
- 人間の作るシステムは人間に似る
- すべてのシステムは若年期から始まり、成熟期を経て、老年期に達して一生を終える
- 「これを人間による三つのシステムと呼ぶ」
3.3 人間による第一のシステム
- 第一のシステムを創る人間は、締切やその他の時間に追われている
- この状況が彼の想像力に火をつける
- 正しくやる時間がない人間は、重要な箇所だけに集中して枝はを無視する
- 第一のシステムは一人か、またはせいぜい数人からなる小さなグループで創られる
- これは彼がやっていることを主流派の多くがほとんど理解できないことによる
- 第一のシステムを小規模で開発するとき、それは高い情熱によって推進され、開発は急速に進む
- 第一のシステムは無駄がなくて俊敏な計算機だ
- プログラムの単純さと速度を最優先し、多くの機能性と柔軟性が犠牲になる
- 与えられた仕事だけはやりおおせるもの、それ以外にはほとんど何もできないソフトウェア、それが第一のシステムだ
- 第一のシステムは実に性能がいい
- 第一のシステムのコンセプトは人間の想像力を刺激する
- 人間の想像力を刺激する面白いコンセプトが、第一のシステムに含まれているときに、第二のシステムが生まれる
3.4 人間による第二のシステム
- 「専門家」が第一のシステムで証明されたアイデアを用いて第二のシステムを創る
- 第二のシステムは委員会が設計する
- この方式には是正しようのない欠点がある。グループのメンバがあらゆる重要問題で意見の一致を見ることなど、ほとんど不可能だということだ
- 第二のシステムは贅肉がつき、遅い
- 第二のシステムはおびただしい「利点」を提供するためにゆっくりと動作することになる
- 世界は第二のシステムを鳴り物入りで歓迎する
- その「柔軟性、豊富なオプション、拡張性」には、各方面からたちまち称賛の声が沸き起こる
3.5 人間による第三のシステム
- 第三のシステムは第二のシステムで「火傷」した人が創る
- 第三のシステムは、第二のシステムへの反抗から生まれる
- 第三のシステムは際にのシステムから大きく名前が変わる
- オリジナルのコンセプトはそのまま残り常識となる
- インクも鳥の羽から万年筆に取って代わったが、紙が残り続ける限りインクも残り続けるだろう
- 第三のシステムは、第一のシステムと第二のシステムの最良の特徴を組み合わせる
- 意欲と本物の才能を持った誠実な人々で、システムの実質的な発展に力を尽くす専門家の貢献が必要
- 第三のシステムの設計者には、ようやく「正しく」やることができる時間が与えられる
- システムの目的はしっかり把握され、使用する技術も捨てに証明済みであるため、リスクは小さい
3.6 第三のシステムの構築
- 第三のシステムはユーザーが実際に使用する機能しか含まれず、機能とリソース消費量と性能の最適なバランスが実現されている
- 第三のシステムを創るには最初に他の二つのシステムを創るしか無い
- 近道は第一のシステムから第三のシステムへとできるだけ早く進むこと
- UNIX開発者のソフトウェアの書き方
- 短い機能仕様書を書く
- ソフトウェアを書く
- テストして書き直す。満足するまでこれを繰り返す
- 詳細なドキュメントを（必要なら）書く
- UNIXプログラマは実際に機能するアプリケーションを示す
- ユーザーと開発者は反復的な設計プロセスの全体を通じて、アプリケーションの検討を繰り返しているのでこの時点では仕様書はもうあまり意味はない。サードパーティ業者のために作成する
第4章 移植性の優先順位
4.1 定理4:効率より移植性
- 何千時間もの開発努力から生み出されるソフトウェアが長寿を全うするか短命で終わるのかは、この定理を守るかどうかによって決まる
- いくつものマシンアーキテクチャ上で動作することの価値を考えると、移植性重視となる
- 今までのソフトウェアが、最新の早いマシンでも動くかということが重要になる。なので現在の効率性より将来の移植性が大切
第5章 これこそ梃子の効果！
- ある努力目標に対して、「梃子でいう支点をいかに自分の方に近づけることができるか」が秘訣
- 自分が1インチ動かすだけで、反対側が月への真ん中ほどまでに跳ね上がるのを目指すこと
- UNIXは梃子を使ったように個人の努力を増幅するのを助ける
5.1 定理:6 ソフトウェアの梃子を有効に活用する
- よいプログラマは良いコードを書く。偉大なプログラマはよいコードを借りてくる
- ソフトウェアを大量に書く一番良い方法は借りてくることだ
- パクリ？
- 先人のソフトウェアはより多くのアプリケーションに活かされてより価値のある存在となるし、取り込んだソフトウェアも投資が少なくてすむ分だけ相対的に大きな収益を生み出すことになり、どちらにとっても好ましい状況となる
- 他人のコードを梃子に使うことは、プログラマ個人にとっても強力な武器になる
- 勝者となる条件は、車輪を発明しなおすことではなく、既存の車輪を光らせることにある
- 最も成功するソフトウェアは、最も多くのコンピュータで使われているソフトウェア
- この点で秘密主義の企業は大きなフリを背負うこととなる
5.2 定理:7 シェルスクリプトをつかうことで梃子の効果と移植性を高める
- シェルスクリプトは単なる受益者であり、梃子の効果を享受するだけの存在だ
- 自分では比較的わずかな労力しか費やさなくとも、百万行以上ものコードの実行結果を自分のものにできる
- これこそ梃子の効果
第6章 対話的プログラムの危険性
- 小さなものは人間にはあまりよく馴染まない
- なんらかの道具を使い、通常の感覚を拡大する必要がある
- 小さなものは、人間とは良く馴染まなくても、互いにはよく馴染む
- サイズが小さいことから、素晴らしい柔軟性が生じる。小さなもの同士は、さまざまな状況で用意に結合し統合される
- 小さなプログラムやモジュールを数多く持つことで環境への適応能力は最大となる
- しかし、モジュールが小さくなればなるほど、ユーザーとのインターフェイスという問題が大きくなってくる
- モジュールの数が増えれば増えるほど、取扱も複雑になる
- ここにソフトウェア設計者にとってのジレンマがある
6.2 定理9:すべてのプログラムをフィルタする
- コンピュータの出現以来、書かれてきたすべてのプログラムはフィルタだ
- プログラムはデータをつくらない。人間がつくる
- コンピュータは、データを一つの形式から別の形式に変換する
- 作者:Mike Gancarz
- 出版社/メーカー: オーム社
- 発売日: 2001/02/01
- メディア: 単行本
