Joel on Software 読書ノート 2/2 ¶

著者:: Joel Spolsky
訳者:: 青木靖
出版社:: オーム社
発行年:: 2005 年
ISBN:: 978-4-274-06630-6

第 20 章 ¶

採用試験の流儀みたいなものを書いているようだ。

<ずさんな履歴書はずさんな作業習慣を反映している> (p. 172)
<もっと重要なのは、その人が選別されていることを示すものを探すということだ> (p. 172)

過去に厳しい選別プロセスを潜り抜けているということなので、優秀な人材である蓋然性が高いということだな。
<どっちつかずのものはすべて機械的に「ノー」に変換して差し支えない> (p. 174)
<自由回答式の質問と問題を与える> (p. 177)
いわゆるムチャぶりな質問を投げかけてみる。質のよくない志望者の反応は明らかにそれとわかるらしい。 <間抜けのように座って救いを待つばかりで、あなたは彼らをずっと引っ張っていかなければならないだろう。そういうのは問題解決ができる人ではない > (p. 181)
著者は <C のポインタを理解しているというのは、スキルではなく素質である> (p. 182) と言い切っている。これは同意できる。少なくともスキルではないという主張は正しい。
<違法な質問を避けること> (p. 185) で挙げられている例は、日本ではまずないケース。ちなみにこの本によくイスラエルの話題が出てくるのは、著者がイスラエル経験豊富だから。

第 21 章 ¶

インセンティブの話題。勤務評定はクソだという主張。

Ship It Award はとても嫌われている。
<実は、人間はポジティブな評価をされた場合でも、それが本人の思っていたほどにポジティブでなかった場合には士気にマイナスの影響があるのだ> (p. 189)
<プラスの評価は士気や生産性に何の影響も与えない> (p. 189)

第 22 章 ¶

テスターを積極的に活用するべしという議論。

procmail のインターフェイスはコテコテの Unix ファンでさえわかりにくい。(p. 191)
<プログラマ 2 人につき 1 人のテスタが必要になるだろう> (p. 192)
テスタを雇う金銭的な余裕がないという言い訳を次のように論破？している。

<あなたがテスタを雇わないなら、あなたはプログラマにテストをさせることになる。そして、あなたがテスタを量産するのがまずいと思うなら、その前に、10 万ドル/年のスタープログラマを入れ替えるのがいかに高くつくか考えてみることだ> (p. 197)

悲しいことにクズプログラマだけの職場では通じない。

第 23 章 ¶

人間マルチプロセッサ思考実験。

現実の CPU では、タスク切り替えには少し時間がかかるが、現実的にはほとんど無視できる。(p. 200)
シーケンシャル処理は平均での処理終了時間がより早いというだけ。
タスク切り替えの時間は短ければ短いほどよい。
<人々に同時に 1 つより多くの作業をさせるべきではない> (p. 202)

第 24 章 ¶

<新しいコードが古いコードよりも優れているというのは、明らかに不合理だ。古いコードは使われている。古いコードはテストされている。多くのバグが見つかり、修正されている。それについて悪いことは何もない> (pp. 204-205)

第 25 章 ¶

<「投機的」ソフトウェア> (p. 209)
<もし可能なら、まだ出来ていない部分の UI はまだ出来ていないように見えるように作ることだ> (p. 215)

この章のキモはこのフレーズに見事に集約されている。

第 26 章 ¶

コンピューターサイエンティストたちの言う 抽象化 とは、<中の方ではずっと複雑なことが行われている何かを単純化するということだ> (p. 218)
著者曰く、抽象化は必ず「漏れ」がある。その例をたくさん挙げていく。
- 二次元配列の要素の辿り方によってパフォーマンスが変わる。
- SQL の WHERE 句で a=b and b=c and a=c が a=c を省いたものよりも劇的に早い。
- 以前議論したように、リモートファイルとローカルファイルの差。
- C++ の string クラス。組み込み型にすればよかったのにと言い切っている。
- 自動車に装備するワイパー、ヘッドライト、屋根、ヒーター。雨と晴れの差を抽象化するためのものだが、カバーしきれていない。
高度化した開発環境が熟練プログラマになるのを難しくする。(p. 222)

第 27 章 ¶

<あなたが日常使うことの 90% は 1 週間で学習できるが、残りの 10% を知るためには 2, 3 年かかるかもしれない> (p. 226)
<私の Windows プログラミングのスキルは、基本的な技術だけでなく、それを支えるインフラ全体を知っていることから来ている> (p. 227)
<あなたは、基本的なプログラミング──たとえば高度な C++ のスキル──が 90% を占め、API は取るに足らない 10% の部分であり、 2, 3 週間あればキャッチアップできると思っているかもしれない。そういう人たちに恐れながら言わせていただくと、時代は変わってしまったのだ。今では比率は逆になっている> (p. 228)
<1 つの世界しか知らない人というのは、太鼓持ちみたい> (p. 229)
<お手軽に一般化された議論> (p. 230)

第 28 章 ¶

本書パート 2 の最後を締めくくる 2 ページからなる短い章。
測定機能障害

第 29 章 ¶

<Microsoft はリストの中で唯一、愚かで致命的な間違いを犯さなかった会社だということだ> (p. 239)

第 30 章 ¶

<「自分のドッグフードを食べる」というのは、私たちコンピュータ業界の人間が自分の製品を実際に使うというプロセスにつけている、奇妙な呼び名だ> (p. 245)
<ソフトウェアをダウンロードしてみると、信じられないくらい出来が悪かったり、そのソフトウェアの目的であるはずの単純なタスクを実行するのがひどく難しかったりすることがある。その理由はおそらく、開発者がそれを使っていないからだ> (p. 247)

第 31 章 ¶

この章は素晴らしいことがたくさん書いてあるのだが、なぜかノートにしづらい。

第 33 章 ¶

<くそルール> (p. 261)
<本当のスキルと才能がなければ即興というのはできない> (p. 263)
<ルールや手順が機能するのは、何もまずいことがない場合だけだ> (p. 265)
<ルールブックは新しい時代には適応できない> (p. 265)

第 34 章 ¶

Nothing is as simple as it seems.

<テスタの採用面接をする良い方法は、彼らに簡単な操作を示して、それが上手くいかなくなる可能性をすべて列挙させるというものだ> (p. 269)
<ソフトウェアエンジニアリングにおける原理がもう 1 つあって、それは、常にリスクを減らすべく努めよ、というものだ> (p. 269)

第 36 章 ¶

ネットワーク効果、ロックイン、ステルスロックイン。
著者はビジネスをゆっくりと拡大する企業の資本金リストに<マスターカードの標準的な限度額> (p. 280) を見る。
Amazon 型の企業は、急成長する必要があるため <時間を金で置き換える> (p. 280) ことを厭わない。<問題を即座に解決するためにいくらでも金を使う> (p. 281)
<山ほどのキャッシュがあればバカな誤りも簡単に取り繕えるのだ> (p. 282)
<Amazon 型の会社は、それができるときにはいつでも時間を金で置き換えなければならない> (p. 284)

「時間を金で置き換える」というフレーズが気に入ってしまった。

第 37 章 ¶

<後の半分は愛でも金でも手に入れることはできなかった> (p. 287)
著者はスティーブ・ジョブズ氏を <現実歪曲フィールド> (p. 289) を自由に操ることができる人物だとみなしている。
Windows 95 とシムシティのエピソード (pp. 292-293) は面白い。

第 38 章 ¶

参入障壁というか、ライバル製品ユーザーの奪い方指南みたいな記事。

第 39 章 ¶

<レジストリの使われていない部分のクリーンアップに気を使うというのは少し強迫神経症気味に違いない> (p. 303)

第 40 章 ¶

補完財とは <あなたが通常他の製品と一緒に買う製品のことだ> (p. 305)
補完財の値段が下がると、製品への需要が増える。よって、自分の企業の製品の補完財の値段は低いのが望ましい。日用品レベルまでに低ければ文句なし。
例えば OS 屋の Microsoft は PC がコモディティ化すれば OK だ。

第 41 章 ¶

ディスクのコピーの際、コピー先とオリジナルが同時に壊れることがある。

<バックアップだけでは不十分だ。これからは RAID でミラーリングするようにしたい> (p. 316)

第 42 章 ¶

OS の定義は <コンピュータのリソースを管理し、アプリケーションプログラムが実行できるようにするもの> (p. 322)
<最も有用なオペレーティングシステムというのは、最も有用なアプリケーションを持っているオペレーティングシステムだ> (p. 323)
従って OS 屋はソフトウェア開発者たちに自分のオペレーティングシステムのためのソフトウェアを開発したいと思わせることが最も重要なこととなる (p. 323)
<彼らは本当は開発ツールをタダで配ってしまいたいのだ> (p. 323)
<人々がコンピュータを買うのは、それを使って動かすアプリケーションのためだ> (p. 324)
<レジストリの AppConpatibility セクションをちょっと覗いてみるといい> (p. 326)

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\AppCompatibility のことか？バイナリデータが格納されていて、その中に色々な実行ファイルのパスが見える。

<Microsoft は後方互換性の信仰を捨てた> (p. 328) という見出しが目をひく。

<Visual Basic .NET を VB 6.0 に対して後方互換でなくしたことだ> (p. 328)
<IIS 6.0 でスレッドモデルが変更され、古いアプリケーションで動かなくなるものが出た> (p. 328)
<Microsoft は大きくなり過ぎて、あまりに多くの開発者がおり、そうしてあまりにアップグレード収入に味をしめてしまったため、すべてを再発明するのもそう大したことじゃないと、突然思いついたのだ> (p. 329)

「なぜメモリ管理なのか？」という囲み記事で、自動メモリ管理の利点を三つ列挙している。(1) の <関数 g の戻り値をどうやって解放するのか気にせずに f(g(x)) と書くことができる> (p. 331) とあるのが、実は一番うれしい。 VB でエクセルを操作するコードを書いたことのある人間ならば同意してくれるはず。
1. と (3) は自明。
<Visual Basic のほうがはるかに生産的だ。私はときどき同じプログラムを、一度は Windows API を呼び出す C++ で、一度は Visual Basic で書くことがあるが、C++ だといつも 3 倍か 4 倍も手間がかかる> (p. 331)

C++ 好きでもこれには同意。3, 4 倍どころではない気がする。
<VB の別の問題は、アプリケーションとともに VB ランタイムを配布する必要があったことで、（略）あなたのアプリケーションが（なんと恥ずかしいことに！） Visual Basic で開発されていると他のプログラマに知られてしまうのだ> (p. 332)

<2 つの対抗勢力を、第 3 の代替案を作って統一しようと試みても、単に 3 つの対抗勢力ができるだけの話だ> (p. 333)

<Web アプリケーションの配布が簡単なのは、インストールが必要ないからだ。Web アプリケーションをインストールするというのは、アドレスバーに URL をタイプすることを意味する> (p. 336)

一瞬びっくりしたが、ユーザーから見た場合の話ね。

<ベンチャーキャピタリストは、Microsoft と競合することになるのを恐れ、 Windows アプリケーションには投資したがらない> (p. 339)
<過去 8 年かそこらの間、わざわざ COM プログラミングを覚えようとする人がおらず、そのためかなり年かさの人を見つける必要がある> (p. 339) ため、マネージドコード言語を使う典型的なプログラマよりも、COM 開発経験者を雇うのにより多くのカネがかかる。

第 43 章 ¶

この章から .NET の議論になる。

<.NET というラベルは新しい「マネージドコード」のプログラミング環境を指すように限定された> (p. 349)

第 45 章 ¶

リンカ（スタティックリンク）を考える。

<.NET は代わりに「ランタイム」というアイデアを持っている> (p. 355)
<ランタイムは DLL と同じ問題を抱えている> (p. 356)

バージョンの異なるランタイムがアプリケーションに悪さをする。
<mscoree.dll か何かに関するバカみたいにユーザに不親切なエラーメッセージ> (p. 356)
<path 変数のダンプが意味もなく出るだけ> (p. 356)
<何かのマヌケなダイアログボックスの OK ボタンを押してやる必要があった> (p. 357)
<映画 1 本分の時間がかかるインストール作業> (p. 357)

付録 ¶

著者の Web サイトの Q & A コーナーの自選傑作選。今読むと隔世の感があるものと、今もなお通じるものと両方ある？