Joel on Software 読書ノート 1/2

著者:

Joel Spolsky

訳者:

青木靖

出版社:

オーム社

発行年:

2005 年

ISBN:

978-4-274-06630-6

イントロダクション

  • <この本はとても主観的だ。私は簡潔さのため、強いて「私の意見では」という言葉を文章の先頭に入れなかった。それというのも、読んでいけば分かることなのだが、この本の文章の一行一行がすべて私の意見だからだ。> (p. 4)

  • <私はこの本を三つのパートに分けた。最初のパートは小規模ソフトウェアに関すること。人を苦しめないソフトウェアを作るために、あなたのチームがすべきことがすべて、そこに書かれている。> (p. 5) 本書全体についてノートを取るのはキツいので、著者の言う「最初のパート」だけ挑戦してみる。

第 1 章

  • 著者は短期開発で GUI プログラムを製作する必要に迫られたならば、 VB を好んで選択するが、<配布ファイルのサイズが大きくなるのは避けられず、Windows にロックインされることになる> (p. 9) と考えている。前者はそれほど大したことないが、後者がイタイ。

  • VB. NET と C# .NET は事実上同じもの。

第 2 章

  • <人々が犯す大きな誤りの中には、略）最も低いレベルの単純な事柄に対する貧弱な理解や破綻した理解が原因で生まれているものがある> (p. 11)

  • C 言語でよく使うスタイルの文字列のことを ASCIZ と呼んでいる。この章では Pascal 式文字列と ASICZ との対比を議論している。これを読むと Pascal 式の方が利点が多いようだ。

  • <宿題として、なぜ（以下略）> (p. 20) は、著者が「最も低いレベルの単純な事柄」を軽視していないことが窺える。

第 3 章

著名な「ジョエルテスト」に関する記事。これをノートしないわけにはいかない。

  1. ソース管理してる？

  2. ワンステップでビルドできる？

  3. デイリービルドしてる？

  4. バグデータベースはある？

  5. 新しいコードを書く前にバグを直している？

  6. アップデートされているスケジュールがある？

  7. 仕様書はある？

  8. プログラマは静かな環境で仕事してる？

  9. 手に入る最高のツールを使っている？

  10. テスタはいる？

  11. 採用面接のときにコードを書かせている？

  12. ユーザビリティテストはしてる？ (p.23)

  • <ジョエルテストの欠点は、原子力発電所向けソフトウェアが安全かどうかのチェックには使えない> (p. 24)

  • <Miscrosoft のような会社は常に 12 ポイントで運営されている> (p. 24)

  • <他の全ての条件が同じなら、この 12 項目をちゃんとやることで、堅実に製品をリリースできる統率の取れたチームができるだろう> (p. 24)

  • 項目 2 の要点は、<最新のソースコードのスナップショットからリリース用のビルドを作るのに、どれくらいのステップが必要かということ> (p. 25) で、もっと突っ込むと、このステップ数が 1 であることを理想とする。

  • デイリービルドの目的は、ビルドが壊れているのに気づかないという事態がないようにするため。

  • <バグデータベースは複雑なものでもシンプルなものでもいい> (p. 26) エクセル一丁だろうが Trac だろうがいいということと解釈して構わないだろう。

  • 無限欠陥法 (return 12;) のエピソードは面白い。

  • 新コードを書く前にバグを修正することの重要性を、紙幅を裂いて説いている。一番の理由は時間が経ってから修正するのは通常困難だということのようだ。

  • 言われてみると、放っておくと仕様書を書かない。

  • 「ゾーン状態に入る」というのは「精神を集中して作業に没頭する」ことか。同僚の割り込みはその気になれば追い返せるが、客の電話問い合わせという割り込みがあるとキツイ。

  • いいツールを利用するというのは大前提。<もしコンパイルに数秒よりも長くかかっているようなら、一番新しくて性能のいいコンピュータを買えば時間を節約できる> (p. 32) というセンスが我々には必要。トイレットペーパーと HDD の値段比較の話もインパクトがあっていい。

  • <テスタの費用をケチるというのは非常に不経済> (p. 32)

  • 最後にジョエルテストの使い方を指南して、この章を終えている。

    • <あなたがプログラミングチームのマネージャなら、このチェックリストでチームが最大限にうまく機能しているかどうか確かめてほしい> (p. 35)

    • 新しい仕事を受注する場合、ジョエルテストをしてスコアが低かったとする。そのときには <あなたにそれを改善する権限が与えられることを確認しよう> (p. 35)

  • あとがきで、著者が受け取った世界中の開発者からのレポートを分析している。

    • スコアの分布は 2 と 3 の間に山がある。

    • <ジョエルテストのスコアが病的に低い> (p. 36) と思える会社からのオファーを蹴った開発者多数。

  • <Visual なんたらかんたら Enterprise Architect> (p. 36)

第 4 章

  • <キャラクタセット、エンコーディング、Unicode などの謎めいた世界について、多くのソフトウェア開発者がまったく理解していない> (p. 37)

  • ASCII: 32 より小さい文字は印字不能文字

    • <彼らは皆それぞれ、128～255 のスペースの使い方に独自の考えを持っていた> (p. 40)

    • <上位の 128 文字を独自の目的に使っていた> (p. 40)

    • <これらの異なるシステムは コードページ と呼ばれた> (p. 41)

  • DBCS: Double Byte Character Set

    • 1 バイト文字と 2 バイト文字が混在しているゆえ、<後ろから読んでいくことはほとんど不可能> (p. 41)

Unicode

  • <これまでは、文字はディスクやメモリに格納されるビット列にマップされるものだと想定していた。一方 Unicode では、文字は コードポイント と呼ばれるものにマップされる> (p. 42) コードポイントとは単なる整数と思っていたほうがいいようだ。A は U+0041 のように表現できる。

    • Unicode は集合で、自然数全体からなる集合と一対一対応がとれるものだと解釈して差し支えなさそう。

エンコーディング

  • FE FF (or FF FE): バイトマークオーダー

  • <UTF-8 は、Unicode コードポイント、つまりあの U+ マジックナンバーの文字列を、 8 ビットバイトを使ってメモリに格納する新しい仕組みだ> (p. 45)

    • コードポイントの範囲ごとに、消費するバイト数を変えている。特に 127 以下のコードポイントは 1 バイトで格納するようにしたので、<英語のテキストが UTF-8 と ASCII でまったく同じになるという具合のいい副作用がある> (p. 45)

  • 3 種類のエンコード方法

    • UCS-2 (UTF-16): エンディアンを見分ける方法が必要。

    • UTF-8

  • 英語のテキストで人気があるのは、Windows-1252 と ISO-8859-1 (Latin-1) だそうだ。

エンコーディングに関する最も重要な事実

  • 文字列がどのエンコーディングなのかを知る方法について議論している。

    • メールの場合は Content-Type: text/plain; charset="UTF-8" のような文字列を探す。

    • Web ページの場合は、meta タグの中にある同様の文字列を探す。ただし、見つけたらページの解析を途中で捨てて、そのエンコーディングで先頭から解析しなおす。

  • 著者の会社で開発している Web サイト管理ソフトでは、 <すべての内部的処理を Visual Basic, COM, Windows NT/2000/XP のネイティブな文字列型である UCS-2 で行うようにした> (p. 49) とある。C++ のコードならば wchar_t 系のデータ、API を利用するわけだ。UTF-8 に変換しやすい？

  • この章の締め括りの言葉がふるっている。<後はあなたにゆだねることにしよう> (p. 49)

第 5 章

  • <ジョエルテストを発表したとき、読者から寄せられた最大の不満の種は、仕様書を書かなければいけないということだった> (p. 51) みんな同じ感想を持つのだな。

  • 仕様書を書かないことは、<最大かつ不必要なリスク> (p. 51)

  • <仕様書の最も重要な役割は、 プログラムをデザインすること > (p. 51) で、 <あなたがプログラミング言語で製品をデザインしているなら、反復デザインには 何週間 もかかる> (p. 54)

  • 仕様書を書いておくことで、もうひとつの時間も節約できる。<あなたが仕様書を書いておけば、プログラムがどう動くと想定されているかを 一度だけ 説明すれば済む > (p. 54)

  • そもそも <詳細な仕様書がないと、スケジュールが立てられない> (p. 56)

  • 難しい決断を最後に残さないこと。プロジェクトは失敗する。

  • 著者自身は、<仕様書が書かれない理由は、多くの人々が書くことを嫌いなためだと思っている> (p. 57)

第 6 章

  • 冒頭で「技術仕様」と「機能仕様」の定義を行い、著者はここでは後者を議論すると宣言している。

    • <機能仕様書には、ユーザーの観点から製品がどのように動くかを記述する> (p. 59)

  • ここからたっぷり紙幅を裂いて、サンプル仕様書を紙上に再現している。何と言うか、情感豊かな表現になっている。役所の書類とかとは全然違う。

  • <仕様書は 1 人の人間 によって書かれ、所有されるべきだ> (p. 68)

  • <製品のターゲット層から、製品をまったく典型的な仕方で使うような、まったく想像上のまったく類型的なユーザをイメージしよう> (p. 68)

  • 対象外の項目をできる限り早く表明しておくことが重要。さもないと、開発に際限なく時間を費やすことになる。

  • 仕様書に概要を入れておくことで、読者に機能の全体像を把握させる。

  • <詳細 は、機能仕様書で最も重要な部分> (p. 70)

  • 未解決の問題も記入しておく。

  • 機能仕様書ではあるが、技術的なノートも入れておく。 <たとえば、実装上の技術的詳細について述べたプログラマ向けのメッセージを「テクニカルノート」として記す。マーケティングの人々はその部分を無視し、プログラマは食い入るように読む> (p. 70)

  • <仕様書は生きている必要がある> (p. 71)

    • 私（著者）の仕様書はいつもアップデートされている。

    • 通常は、アップデートした仕様書をサーバーのどこか、チームが参照できるところに置いておく。

    • 仕様書を凍結するのは、コードフリーズと同時。

第 7 章

「プログラムマネージャ」という役割について議論している。

第 8 章

  • <可笑しくするための最も簡単な方法は、必要もないのに話を 具体的 にすることだ> (p. 81) 本書を読む限り、著者はこの技法を仕様書以外にも多用していそうだ。

  • <人間に対しては、あなたは初めに全体像を示し、そのあとで 詳細を埋める必要がある。（略）一文ごとに、その文を読んでいる人が、すでに説明したことに基づいて深く 理解できるか を自問してみること> (pp. 83-84)

  • <たくさんのスクリーンショットを使うことほど仕様書を改善する方法はない> (p. 85) とし、具体的には、例えば Windows アプリを開発するのならば、VB で画面のモックアップを作ることを推奨している。なるほど。

  • 仕様書にテンプレートはいらない。<いったい誰が仕様書に 参考文献リスト を必要とするのだろう？> (p. 86) は至言ですな。

第 9 章

  • なぜ誰もスケジュールを作らない？

    • 苦痛だ。

    • 意味がない。

  • エクセルを使う。

  • <プログラマは交換可能でない> (p. 89)

  • <スケジュールを立てられるのは、それを書くプログラマだけ> (p. 90)

  • タスク粒度は、見積もりができるレベルにまで細かくする。<面倒くさがって大きな塊のタスクを選択した場合、何をすることになるのかを実際には考えていない> (p. 90) 可能性が高い。

  • 当初見積もりと現在見積もりを両方記録する。

  • 経過時間を毎日アップデート。

    • これを現在実際に試している。案外できるものだ。

  • <スケジュールにデバッグの時間を入れる> (p. 92) デバッグに関しては他の章でも述べているように、見つけたらすぐに対応することを鉄則とする。

  • <スケジュールにバッファを入れる> (p. 93)

    • 意外に忘れがち。だって担当するタスク量が多いンだもン。

  • 著者の Excel 5 の泣く泣くカットした機能を、次バージョン Excel 6 で見直した際のエピソードが面白い。

  • 囲み記事の「Excel についてあなたが知っておくべきこと」は必読。

    • 未だにピボットテーブルをうまく作れたことがない。

    • WORKDAY 関数どころか、日付から曜日を出す関数すら覚えていない。

第 10 章

デイリービルドに関する考察。

  • REP ループ (Read, Eval, Print) の概念。

  • <「編集－コンパイル－テスト」のループが速くなればなるほど、あなたの生産性は高くなっていく> (p. 101)

    • このループを速くするためならば、手段を選ばぬこと！

  • <開発プロセス全体がスムーズに実行できるようにするためには、この「報告修正再テスト」のループを緊密にすることに傾注する必要がある> (p. 102) ので、著者はデイリービルドを奨めている。

    • デイリービルド：自動化＋毎日＋完全

  • デイリービルドをするマシンには、最速のコンピューターを利用する。

  • <ファイナルビルドを生成するために必要な すべてのこと を、デイリービルドスクリプトによって行うことが重要だ> (p. 103) アイコンのダブルクリック一発でフルビルドできることが望ましい。

  • コンパイラを最高の警告レベルに設定すること。

    • -W4 (cl)

    • -Wall (gcc)

  • デイリービルドの失敗を、スクリプトにより開発チーム全体に送信するように仕掛ける。

  • この章で一つ変だなと思ったのは、ビルドの時刻を昼休みにすることを推奨している点。一時間やそこらでフルビルド可能なプロジェクトだけではないような……。

第 11 章

デバッグに関する考察。

  • <バグを直すことが重要になるのは、そのバグを直すことの価値が修正にかかるコストを超える場合だけだ> (p. 107)

  • <ただし、ほとんどの場合、バグは直す価値がある> (p. 108)

第 12 章

  • <彼女たち（引用者註：おばあちゃんたち）はチームビルディングに関する文献ではあんまり取り上げられてないように思う> (p. 116)

  • パッケージ

    • AltGr キー

    • オープンソースの世界では、開発者同士がリアルな世界で打ち合わせをすることがほとんどない。それゆえ、デザイン上の問題でまずい決定がなされがちだと指摘している。

  • インターナル

    • <1 つの会社のコンピュータで、1 つの状況において動きさえすればよい> (p. 119) ので、次のような傾向があると考えている。

      • ユーザビリティの優先度は低い。

      • パッケージソフトよりもずっとバグが多い。

      • <若くて熱心な開発者は、ソフトウェアがそれなりに動くようになったときに開発をやめるように言われて失望してしまうかもしれない> (p. 119)

  • 組み込み

    • ハードウェアの中に閉じ込められていて、アップデートが不可能。

      • 品質に対する要求は極めて高い。

      • CPU がはるかに遅い。

      • 開発作業の多くが手作業による最適化とチューニングになる。

      • 速くなければならない。

  • ゲーム

    • ヒット指向。映画に近い。バージョンがたった 1 つしかない。よって、

      • 組み込みソフトウェアと同じ品質要求がある。

      • <最初から正しくやることに対する非常に強い財務上の要請がある> (p. 120)

  • 使い捨て

    • ここは全四項の補集合的項目なので、重要ではない。箸休め的セクション。

  • <GUI については どんな 作業も自動化テストできたためしがない。（略）せいぜい GUI の皮の下の部分を自動化テストすること> (p. 122)

第 13 章

試作についての考察。

  • 著者の考えは身も蓋もないもので、 <ソフトウェアプロトタイプというものには見切りをつけている。もしプロトタイプに製品にできることがすべてできるのなら、それは製品と 一緒 であり、もしできないなら、あまり役には立たない> (p. 125)

  • そこで著者はペーパープロトタイプを提唱する。何かと言うと、<ユーザインターフェイスのモックアップとして 鉛筆 で描いた紙切れを使う。あまりきっちりしてない方がいい> (p. 126)

    • あえて体裁を整えないことで、紙切れモックアップを見てくれる人が <あなたの感情を害さないように気遣って自分の意見を自己検閲することもない> (p. 126) という狙いがあるため。

    • イメージとしては、紙切れ、鉛筆、消しゴム、はさみでダイアログボックスやら、ボタンやらポップアップするホニャララを工作して、それらを紙上で動かしてみせる。

第 14 章

  • <抽象化へ向かってあまりに高く上がると、酸素を切らしてしまう> (p. 127)

  • <アーキテクチャの連中は、彼らが解けると思った問題を解いているのであって、解くのが 有用な 問題を解いているのではないというのを覚えておこう> (p. 130)

第 15 章

かの有名な「射撃しつつ前進」の章。

  • しかし私を悩ませるのは 2 時間しか仕事ができない日々ではない。私が まったく 何もできない日々だ> (p. 132)

  • <本当に 始めなきゃいけないと、再び決心する> (p. 132)

  • <この射撃しつつ前進の原理が、人生で何かを成し遂げるときのやり方でもあることに気づくには、さらに 15 年かかった> (p. 133)

メールボックスのチェックやら、ウェブサイトの閲覧やらで時間をつぶすのはみんな一緒。

第 16 章

  • <マルチスレッドというのは、たいていの場合にプロセスを別にするのほど良い解決策ではない> (p. 139)

  • <ソフトウェアが本物のクラフトマンシップに則って作られたなら、すべてのネジがそろっているのだ> (p. 142)

  • 本当に言いたいのはこれだろう。<主要な機能よりもレアケースを正しく処理するために、より多くの労力が払われる。たとえ 1% のケースを処理するために 500% の余計な労力がかかったとしてもだ> (p. 141)

第 17 章

  • 検索の本質は <検索結果をいかにソートするか> (p. 144) だ。

  • Google のラリー・ペイジとセルゲイ・ブリンの名前が会話等でスラスラ出ると格好がつくと思った。ところで、この両者の名前が Google 日本語入力で suggest されないようだ。

  • アンチエイリアスされたテキストを <単に汚い> (p. 145) の一言でバッサリ。読みやすさよりも見てくれを重視するケースで、その価値を認めている。

  • ネットワーク透過性の話は、個人的に馴染みがないので楽しく読めた。ネットワークが関係する設計では、ネットワーク用に提供された API を利用する。

第 18 章

UNIX と Windows との違いについての論考。

  • <残っている違いは文化的なものだ> (p. 149)

  • <よく議論を巻き起こしているエリック・レイモンドが、最近『The Art of Unix Programming』という題の UNIX プログラミングについての長い本を書いて、彼自身の文化について深く追求している> (p. 150)

    ジョエル本の前にこちらを読んでいたのだが、かなり面白かった。買えばよかった。

  • <ポリシーとメカニズムの分離> (p. 153) は後で調べておくこと。読んだハズなのだが。

  • <1 つの文化しか知らないプログラマがあまりに多い> (p. 155) の直後の展開が謎。著者は UNIX しか知らないプログラマだけを貶めていないか？

第 19 章

クラッシュレポートについて、技術的に突っ込んだ内容になっている。

  • <オペレーティングシステムのバージョンとか、搭載している RAM の容量といった、その他の重要な情報のほとんどは、自動的に手に入れることができる> (p. 159)

  • <自動的に収集、送信される情報があることについても、ユーザに知らせておくように注意すること> (p. 159)

  • <私は開発者として何年も働いてきたが、コアダンプで何をするのかよく分からない。それにコアダンプデータを集めるのは不必要なことが分かった。プログラムがクラッシュしたのがどこか、その正確なコードが分かれば、その情報だけでほとんどすべてのクラッシュの修正には十分なのだ> (p. 159)

  • 囲み記事内の、筆者が「自動的に収集しているデータ」は参考になる。

  • <いろいろ実験した結果、エラー番号、ファイル名、関数名、行番号、ソフトウェアのバージョンを文字列に含めるのが、そのための一番良い方法だと分かった> (pp. 162-163)

  • 偶数のビルド番号と奇数のビルド番号を使い分ける。

  • <結構頻繁に起こるクラッシュにだけ対処するようにしている> (p. 164)

  • 決して直さないバグというのもある。特に一度しか起きていないようなものは調べさえもしない。

  • 最後の囲み記事も大いに参考になる。