スキマ時間が出来たので30分ばかり本でも読もうかと。
ジェラルド・M・ワインバーグ
日経BP社
売り上げランキング: 58374
ソフトウェアの人類学
この本は25年前に出版された書籍の新装版らしい。
25年前にベストセラーになり、「この本はソフトウェアの人類学である」という評価を得ていたようだ。
コードを読め
優れた小説家が過去の遺産を読みまくるように、プログラマはもっと他人のコードを読め！とのこと。
制約を当たり前と思い込んでしまっている
過去のコードを読むと、10000個の数字を足すだけでも処理を分割している
->メモリやら処理能力の限界
->ハードに左右されていたことが分かる
->よく考えていれば、実数ではなく有理数を扱うしか無いということもハードウェアの制約だということを思い出す
プログラマー自身による制約
機能を知らない、アルゴリズムを知らないことによって生み出される無駄、かつ酷いコード群
歴史上の足跡
意味のわからないコードを発見したプログラマーは調査を行う
結果、遙か昔に存在したハード的制約を乗り切るための応急的処置であったことが分かる
まるで考古学だ！
プログラマーの心理を分析する必要性
上述したような問題などを見つけるためにはプログラマーの心理について研究・理解する必要がある。
また、コードを読む必要は絶対的である。
「質問」という項目より
◯マネージャ向け
◯プログラマ向け
- 最後に他の人が書いたプログラムを読んだのはいつですか？
- 他人のプログラムを分析してみてください。そこからどんなことを学びましたか？
効率より大事なこと
それは「動くこと」
スケジュールについて
6ヶ月と見積もって9ヶ月かかるより、12ヶ月と見積もって12ヶ月かかるほうがいい。
予想される所要時間の平均よりも、実際の所要時間の標準偏差の方がイラつきの原因になることはプログラミング以外の分野でも知られている。
適応性
素晴らしい速度の出るプログラムが書けても、プログラムの修正にそれ以上の時間・コストが掛かるのであれば
初めから愚直なコーディングをすべき。
「2章のまとめ」より
- プログラムは仕様を満たしているか。あるいは、プログラムはどれくらい仕様を満たしているか。
- プログラムはスケジュールどおりに生産されているか。特定のアプローチを取った場合、どれくらいスケジュールのばらつきが予想されるか
- 状況が変わったときにプログラムを変更することは可能か。変更にどれくらいコストが掛かるか。
- プログラムの効率はどの程度か。その場合の「効率」とは何か。ある分野の効率と引き換えに、他の分野が非効率的になっていないか。
マネージャについて
出来る範囲で最高の製品を作るために懸命な妥協を求めることが重要。
全打者全打席ホームランを打て！と指示するのが仕事ではない。
今日はここまで
時間が来た＆第2章までは読みきったので今日はここまで、ということで。
思っていたよりも面白い内容なので、また近いうちに続きを読み解くことにしましょう。
