書籍「ジョエル・オン・ソフトウェア」

Joel on Software

ありがちなソフトウェア・マネージメント本かと思っていたら、プログラミング経験に裏打ちされた本です。面白い話題がたくさん散りばめられています。Webの記事がベースになって書籍化されており、Webの記事の方は日本語訳もあります。以下、面白いと思ったトピックとWebの記事（日本語）へのリンクを記します。

mallocは遅く予期できない

Web記事にはなさそうなので引用

mallocの本質はフリーチェーンと呼ばれる使用可能メモリブロックの長い連結リストだ。･･･mallocのパフォーマンスは決して速くなく、しかも、クリーンアップのためにときどき予期できないタイミングで非常に遅くなる

Javaはガベージコレクションがあるから・・・なんてしたり顔で話すC++プログラマが、デフォルトのメモリアロケータを平然と使っているなんてことがあります。

頭のいいプログラマは、mallocによる処理の中断の可能性を最小化するために、いつも2の累乗のサイズでメモリブロックを割り当てる。･･･この方法はフリーチェーンの中のヘンな断片化の量を最小化するのだ。

うーん、そうなのか。そこまでしたことはなかった。

ジョエルテスト

http://japanese.joelonsoftware.com/Articles/TheJoelTest.html

デイリービルドに関するExcelチームのルール、「ビルドを壊した人は罰として他の誰かがビルドを壊すまでの間ビルド作成のお守りをしなきゃいけない」というのはおもしろい。

ソフトウェア開発の5つの世界

http://japanese.joelonsoftware.com/Articles/FiveWorlds.html

どの世界について議論しているのかを常に明確にしよう、自分の世界が全てではないと刻みました。

ペーパープロトタイピング

私は基本的に、ソフトウェアプロトタイプというものには見切りをつけている。もしプロトタイプに製品にできることがすべてできるのなら、それは製品と一緒であり、もしできないなら、あまり役には立たない。

経験的にとっても納得できます。そんなものに力を入れて開発するくらいなら、紙上にGUIのスケッチを書いて見せた方が効果が高いというのも納得。

クラフトマンシップ

ソフトウェアを作るのは工業製品の製造プロセスとは違う。･･･
コードを書くことは製造ではなく、必ずしもクラフトマンシップでもなく、それはデザインなのだ。デザインというのは、コストを増やすよりも早く価値を追加することができる、漠然とした領域のことを指す。

ソースコードは設計のアウトプットです。至極同意。サブシステムでもパッケージでも何でもよいのですが、ソフトウェアを分割したある塊について厳密にインタフェースを規定しようとすると、ソースコードを書くかあるいは等価な記述（ソースコードを自動生成するための入力：例えばCORBAのIDLとかWSDLとか）をしなくてはなりません。UMLではせいぜいインタフェースの概要どまりです。

念のため、コードを書くことはデザインだけど、コードを書くだけがデザインではありません。

氷山の秘密、明らかに

http://japanese.joelonsoftware.com/Articles/TheIcebergSecretRevealed.html

顧客は自分が何が欲しいか分かっていない
顧客が自分で何が欲しいか分かっていると期待するのはやめることだ

これも経験的に同意です。

何ごとも見た目ほど簡単ではない

何ごとも見た目ほど簡単ではない。
常にリスクを減らすべく努めよ、
実装する前にデザインする必要がある。
デザインを過度に形式的にやるのは時間の無駄だ
1000万コード行の巨大なシステムは進化していくべきもの･･･そのようなスケールのソフトウェアをデザインする方法を、実のところ人類は知らない

「ここで発明されたものじゃない」症候群を擁護する

それがビジネスで核となる機能なら−−−何が何でも自分でやることだ