Joel on Software   このページは"ジョエル・オン・ソフトウェア

※新しい翻訳はJoel on Software Translation Projectにあります。

その他の "Joel on Software" の記事（日本語）

その他の "Joel on Software" の記事（英語）

著者へのメール（英文のみ）

私の家族がイスラエルで最初のIBM-PCを受け取ったのは、1982年のことだった。私たちは実際倉庫にまで行って、私たちのPCが港から運ばれてくるのを待ったのだ。 2つのフロッピーディスクドライブ、128Kバイトのメモリ、それに2台のプリンタ、高速でドラフトを出すためのドットマトリックスプリンタと、印刷中にマシンガンより大きな音を出すブラザー製の高品質印字用ディジーホイールプリンタを備えた完全装備バージョンを買ってくれるように、私はどうにか父を説得したのだった。私たちは手に入るほとんどすべてのアクセサリを買ったと思う: PC-DOS 1.0、BIOSの完全なソース付きの$75のテクニカル･リファレンス･マニュアル、マクロアセンブラ、それに見事なIBMモノクロディスプレイ、これは一行80文字で、しかも･･･小文字が表示できたのだ! 当時のイスラエルのとんでもない輸入税を含めると、全部合わせて$10,000ほどにもなった。なんと法外な!

さて、BASICは子供向け言語で、スパゲッティコードを書いて脳みそをカマンベールチーズに変えてしまうということは｢誰でも｣知っていた。それで私たちは$600払ってIBM Pascalを買った。それは3枚組のディスクになっていた。コンパイラのパス1が最初のディスクで、パス2が2枚目のディスク、そしてリンカが3枚目のディスクに入っていた。私は簡単な"hello, world"プログラムを書いてコンパイルしたが、所要時間は8分だった。

うーん、ちょっとかかりすぎる。私は作業を自動化するバッチファイルを書き、このプロセスを7分半にまで短縮した。幾分かは改善されたが、いつも私を負かしたあの素晴らしいオセロプログラムのような長いものを書くときには、コンパイル待ちでほとんどの時間を過ごすことになった。｢そうさね、｣とプロのプログラマが私に言った。｢僕らは腹筋台をオフィスに置いて、コンパイルしている間に腹筋するんだよ。プログラミングを2、3ヵ月もしていると、超人的な腹筋(killer abs.)が手に入るよ。｣

ある時、Compas Pascalというおしゃれなプログラムがデンマークから登場し、フィリップ･カーンがそれを買い取ってBorland Turbo Pascalと改名した。Turbo Pascalは衝撃的だった。それはIBM Pascalにできることは基本的に何でもできたが、テキストエディタを含めて、 33Kほどのメモリで走らせることができた。これだけでも十分驚くに値するが、さらに驚いたのは、それが小さなプログラムを1秒未満でコンパイルできたという事実だった。それはまるで、聞いたこともない会社がビュイック･ルセイバーのクローンを作り、それが時速百万マイルで走り、アリが病気にならずに飲み干せるほどのガソリンで世界一周できるというようなものだった。

突如私の生産性は跳ね上がった。

私がREPループの概念について知ったのはそのころだった。REPとは"Read、Eval、Print"の意味で、これはLisp インタプリタがしていることだ: それはあなたの入力を読み(Read)、それを評価し(Eval)、そして結果を出力する(Print)。REPループの例を下に示した: 私が何かタイプすると、Lispインタプリタはそれを読み込み、評価し、結果を表示する。

もう少しスケールを大きくしてみると、コードを書いているときのあなたは、REPループのマクロバージョンであるEdit-Compile-Testループの中にいる。あなたはコードを編集し、コンパイルし、ちゃんと動くかテストする。

ここで肝心な点は、あなたがプログラムを書くときには、このループを何度も何度も繰り返す必要があることで、瞬時のコンパイルを上限とし、Edit-Compile-Testループが早ければ早いほどあなたの生産性は高くなっていくということだ。プログラマがすごく速いハードウェアを欲しがり、コンパイラ開発者が超高速Edit-Compile-Testループを実現するためにできることは何でもすることの、コンピュータサイエンス的な公式の説明がこれだ。Visual Basicはユーザが一行入力するごとに字句解析と構文解析を行うことで、最終的なコンパイルの超高速性を実現している。Visual C++はインクリメンタル・コンパイラ、プリコンパイル済みヘッダ、インクリメンタル・リンクによってこれを行っている。

複数の開発者とテスタのいるチームで働くようになると、あなたはさらに拡大された同じループに再び出会うことになる(フラクタルだ、すげえ!）テスタはコードのバグを見つけ、バグを報告し、プログラマがバグを修正する。テスタが修正バージョンのコードを手に入れるまでにどれくらいの時間がかかるか? 開発組織によっては、このReport-Fix-Retestループには2週間もかかり、それは組織全体が非生産的に運営されていることを意味している。開発プロセス全体がスムーズに実行されるようにするためには、このReport-Fix-Retestループを緊密にすることに集中する必要がある。

そのための良い方法のひとつはデイリービルドだ。デイリービルドは自動化された、毎日行われる、完全なソースツリー全体のビルドのことだ。

自動化 - (UNIXの)cron jobか(Windowsの)スケジュールサービスを使い、毎日同じ時刻にコードがコンパイルされるように構成するから。

毎日 - あるいはもっと頻繁に行う。継続的ビルドも魅力的ではあるが、すぐ後で述べるソース管理上の問題により、たぶんうまくいかないだろう。

完全 - たぶんあなたのコードには複数のバージョンがあることだろう。複数の言語、複数のオペレーティングシステム、上位バージョンに下位バージョン。デイリービルドではそれらのすべてをビルドしなければならない。すべてのファイルをスクラッチから、コンパイラの完璧ではないインクリメンタル・リビルド機能を使わずにビルドする必要がある。

以下にデイリービルドの利点をいくつか挙げよう:

1. バグがフィックスされたとき、テスタは新しいバージョンを短時間で手に入れて、バグが本当に修正されているか確認するための再テストができる。
2. 開発者は自分のした変更が1024あるバージョンのどれも壊さないことに、より自信を持つことができる。彼らの机の上にOS/2マシンが実際にはなかったとしてもだ。
3. スケジュールされたデイリービルドの直前にチェックインした開発者は、「ビルドを壊す」もの(これは誰もコンパイルできなくする何かのことだ)をチェックインして他のみんなを殲滅してしまうことがないと分かる。これはプログラミングチーム全体が死のブルースクリーンを見ているようなもので、プログラマが新しく作ったファイルをリポジトリに追加し忘れたときによく起きる。ビルドは彼のマシンではうまくいくが、他の誰かがチェックアウトするとリンクエラーが起き、どんな作業もできなくなってしまう。
4. マーケティングやベータカスタマサイトなど、未熟な製品を使う必要のある外部のグループは、よく安定しているバージョンを選んでしばらくそれを使い続けることができる。
5. すべてのデイリービルドのアーカイブを維持しておくことによって、非常に奇妙な新しいバグが見つかってその原因の見当がつかないとき、ヒストリカルなアーカイブを二分探索して、そのバグが最初に現れた時点を正確に知ることができる。 良いソース管理システムと組み合わせれば、どのチェックインがその問題を引き起こしているか突き止められるだろう。
6. プログラマが修正したと考えている問題をテスタが指摘したとき、テスタはどのビルドでその問題が観察されたかを言うことができる。プログラマはいつ修正をチェックインしたか調べて、それが本当に修正されているか見当をつけることができる。

以下にデイリービルドの手順を説明する。あなたにはデイリービルドのためのサーバが必要で、それはたぶんあなたが手に入れられる最速のコンピュータになるだろう。リポジトリ(ソース管理システムは使ってるんだよね?)から最新のソースコードの完全なコピーをチェックアウトし、出荷されるコードの各バージョンをスクラッチからビルドするスクリプトを書く。インストーラやセットアッププログラムがあるなら、それもビルドする。あなたが顧客に出荷するすべてのものがデイリービルドプロセスで作成される必要がある。それぞれのビルドを日付ごとのディレクトリに置く。スクリプトを毎日決まった時間に実行する。

• コードのチェックアウトからWebサーバ上のダウンロードのためのしかるべき場所(開発プロセスの間はもちろんこれはテストサーバであるわけだが)に配置するところまで、ファイナルビルドを作成するために必要なすべてのことが、デイリービルドスクリプトによって行われるということが重要だ。これはビルドプロセスに、誰かの頭の中にしかないような要素が何もないことを確かにする唯一の方法だ。ただ一人インストーラの作り方を知っていたシャニカがバスに轢かれたために製品をリリースできない、 というような状況は絶対避けるべきだ。Junoのチームでは、スクラッチからフルビルドを作成するためにあなたが知らなければならないことは、ビルドサーバの場所と、｢デイリービルド｣アイコンをダブルクリックする方法だけだった。
• コードを出荷しようとしたとき小さなバグが一つ見つかったため、そのバグをデイリービルドサーバ上で修正して出荷する、という以上に精神衛生に悪いことはない。完全チェックアウトから始めたクリーンで完全なデイリービルドにより作成されたコードのみをあなたは出荷すべき である、というのが黄金律だ。
• あなたのコンパイラを最高警告レベル(Microsoftの世界では-W4、gccでは-Wall)に設定し、最小レベルの警告であってもコンパイルが停止するようにすること。
• デイリービルドが失敗するとチーム全体の作業を止めるリスクを犯すことになる。何もかもやめて修正できるまでリビルドを続けること。そのうちあなたは複数のデイリービルドを作るようになるかもしれない。
• あなたのデイリービルドスクリプトは、失敗をチーム全体にemailで報告すべきである。ログにgrepをかけてerrorやwarningを拾い出し、 emailに含めるのはそれほど難しくないはずだ。スクリプトはまた、プログラマやテスタがどのビルドが成功しているかすぐ分かるように、誰もが見ることのできるHTMLページにステータスレポートを追加する ようにもできる。
• 私たちがMicrosoft Excelチームにならっている一つのルールは、ビルドをこけさせた張本人は、別な誰かがビルドをこけさせるまでの間、ビルドのお守りをしなければならない、というものだ。これはビルドを失敗させないようにするためのインセンティブとなるのし、ほとんど全員にビルドマスタの仕事を持ち回りさせることになるので、みんなビルドの作り方を学ぶことができる。
• もしあなたのチームが一つのタイムゾーンの中で働いているのなら、ビルドするのに良い時間は昼休みだ。昼休み前にみんな最新のコードをチェックインし、彼らが昼食を取っている間にビルドが行われ、彼らが戻ってきたときにビルドが失敗していたなら、みんな集まってそれを修正する。ビルドができたら、みんなはビルドでこけるおそれなく最新版をチェックアウトできる。
• あなたのチームが2つのタイムゾーンで働いているのなら、一方のタイムゾーンの人たちが他方のタイムゾーンの人たちを殲滅しないようにデイリービルドをスケジュールする。Junoチームでは、ニューヨークの人たちはニューヨーク時間で午後7時にチェックインして家に帰っていた。彼らのビルドが失敗すると、インドのハイデラバードのチームは仕事に取りかかってすぐ(ニューヨーク時間で午後8時)に行き詰まり、一日中仕事ができなくなった。私たちはデイリービルドをそれぞれのチームが帰宅する前の2回行うようしてこの問題を解決した。

さらに読み進めるのであれば:

• デイリービルドツールに関するディスカッション
• デイリービルドを作ることは重要であり、それは良いコードのための12ステップの中の1つだ。
• パスカル･ザカリーの本Showstopper(邦訳:闘うプログラマー)には、Windows NTチームにより(毎週)作られたビルドにに関する興味深い話がたくさん書かれている。
• スティーブ･マッコーネルはここでデイリービルドについて書いている。