Rub a dub dub
From The Joel on Software Translation Project
Joel Spolsky ジョエル・スポルスキ
翻訳: Katsura Ozawa 小澤桂
翻訳チェック: Aki Sugiura 杉浦 亜希
2002-01-23
我々がコードベースをゼロから書き換えたいと思う理由のひとつに、オリジナルのコードベースが本来の目的用にデザインされていないということがあげられます。それはプロトタイプや、実験用、演習用、またはわずか９カ月ほどでゼロから書かれ公に出されてしまったもの、あるいは一回限りのデモ用として設計されたものだったりする訳です。
壊れやすくコードの追加は不可能でみんなの悩みの種となり、もともと居たプログラマーは絶望してあきらめ、新しく採用されたプログラマーはコードの裏表が分からず、マネジメントをどうにか説得して始めからやり直すようにすすめ、その間にマイクロソフトが彼らのビジネスを引き継いでしまうというような窮地に陥ってしまいます。今日は、そんな風になる前に何をするべきか話をさせてもらいます。
FogBUGZは６年前に私自身がASPプログラミングを習うため実験用に書き始めました。
じきにそれは社内のバグトラッキングシステムになり、もう必要な機能はすべて搭載されていると認められるまで毎日のように追加されました。
私は友人たちに彼らの会社でFogBUGZを使ってもいいか尋ねられました。しかし、問題は、ハードコードが多すぎて、開発に使用したオリジナルのコンピュータ上以外で動かすことが難しくなっていたことでした。例えば、SQLサーバーのストアドプロシージャがたくさん使われていたため、FogBUGZを走らせるには SQLサーバーが必要でした。これは、二人ほどの小さなチームにとっては高価過ぎで、大きすぎるものです。私は友人たちに「コンサルティング料に５０００ドル。SQLサーバーではなくアクセスを使ってサーバー上で動かせるように2,3日使ってコードを整理するから。」と言っていました。
ほとんどの友人たちがこれは高すぎると思っていました。
こんなことが数回起きた後、私はふと気がつきました。－もし私が同じプログラムを、例えば２０００ドルで３人に売ることができれば、お釣りがでる。あるいは２００ドルでの３０人の人々に売ったら。ソフトウェアをそれくらいすばらしいものなのです。２０００年後半に、マイケルは腰を据えて、AccessでもSQLサーバー上でも動くようにコードを変更しました。サイト固有の要素をすべて引き抜いてヘッダファイルに入れ、売り始めました。私はたいしたことは期待していませんでした。
当時、私はこんなふうに考えていました。巷にはやまほどバグトラッキングパッケージがあるじゃないか。多くののプログラマーがちょっとしたバグトラッキングパッケージを書いている。誰が我々の物を買ってくれるだろうか？しかし、私はあることに気付いていました：ビジネスを始めるプログラマーの多くは、ほかの誰も自分とまったく同じようなプログラマーであり、同じ物がほしいだろうと思う悪い癖があり、それを前提にプログラミングツールを売るビジネスを始めるという、良くない傾向がありました。だから多くのちっぽけな会社がプログラマーだけしか愛着をもてないようなソースコードを生成する物やら、エラーキャッチとeメールを送るとかいう物やら、シンタックスカラリング編集や、ftpを行う物やら、そしてバグトラッキングパッケージと称する物を売り歩いているのです。私はそんな風になるつもりはありませんでした。
もちろん、何事も計画したとおりに行くわけでは有りません。FogBUGZは人気がありました。驚くほどにです。FogCreekに多大な収入を与え、消費者は買い続け、売上は着実に伸びていきました。
そこで我々はバージョン２.０を作りました。これは必ず必要だとされる機能を追加する試みでした。デイビッドがバージョン２.０に取り組んでいる間、我々は正直言ってそれがそれほどの価値があるとは思いませんでした。そのため彼の作業のやり方は、どちらかというといわゆる「洗練された」というより、「急場しのぎ」的なものでした。明らかにオリジナルコードの、デザイン問題が悪化していました。メインのバグ編集ページの製図部分に、ほとんど同一のコードセットが２度書かれていたり、SQLステートメントがHTMLのあちこちに散らばっていたり。 我々のHTML はがたがきていて、about:blankをロードするとクラッシュするくらいバグだらけの古いブラウザ用にデザインされたものでした。
それでも、それは非常によく稼動し、しばらくの間 確認されたバグはゼロでした。けれども内部のコードは、専門用語を使うなら「ビッグメス（大混乱）」で、新しい機能を追加するのは悩みの種でした。中央のバグテーブルにフィールドひとつを追加するにはおそらく５０個所は修正しなくてはなりませんでした。それでもまだ、火星のビーチハウスへの週末旅行用に自家用飛行機で行けるようになっても、修正し忘れた場所を探しつづけていることになったでしょう。
多分、迅速配達のパッケージから経営まで一人でしているようなもっと小さい会社だったら、そんなコードをあきらめ再び始めからやり直すことにしたかもしれません。
私はゼロから始めるなどということは信じられないと、もう言及したでしょうか？それについて私はいろいろと話していますが。
いずれにしても、ゼロから始める代わりに、私はコードを完全に磨きあげるのに３週間費やす価値があると考えました。Rub a dub dub（コードをきれいにしましょう）。リファクタリングの原理にもとづき、これを実行するために私はいくつかのルールを作りました。
- 新しい機能は、どんなに小さくても追加はしない
- いつでも、どのチェックインでも、コードは完璧に稼動する
- 行うことはすべて論理的な変換－ほとんど機械的なことでで、コードの動きをかえないとすぐ確信できる、そういう類の物のみ
私は、各ソースファイルを一つづつ上から下まで目を通し、どうすればもっとよい構造になるかを、簡単な変更するにはどうするかを考えました。以下に述べるのがその３週間で私が入れた変更の一部です：
- すべてのHTML をxhtml に変えました。例えば、< BR >を< br / >とし、アトリビュート（付属物）を読みやすくするため付け加え、ネストされたタグを合わせ、すべてのページを規格に合うように見直しました。
- すべてのフォーマッティング（< FONT>タグなど）を削除して、CSS スタイルのシートに入れました。
- プレゼンテーションコードからすべてのSQL ステートメントと、プログラムロジック（マーケティングタイプ的には「ビジネスルール」と呼ばれるもの）を削除し、これらはきちんとデザインされていないクラスに入りました－必要とわかったとき、メソッドをいいかげんに追加したのです。（自分のクラスをデザインしなかったってどう言う意味だ？といって、どこかで誰かが4x6のカードを山と持って、私の目を突くために鉛筆をとがらせているかもしれません。）
- コードが繰り返しになっているブロックを見つけ、クラス、ファンクション、あるいはメソッドを作り、重複を排除するようにし、大きなファンクションを細分化しました。
- すべての英語テキストをメインコードから取り除いて、国際化を簡単にするためにシングルファイルに隔離しました。
- ASPサイトの再構築をし、たくさんの細かいファイルの代わりに、エントリーポイントをひとつしました。こうするとかつて難しかったものが非常に容易になりました。例えば、無効な入力があったそのフォームで入力エラーメッセージを表示できるように現在なっていますが、もしレイアウトのデザインがきちんとしていれば簡単なはずです。しかし私がASPプログラミングを学んでいたときには、きちんとレイアウトしていませんでした。
３週間のあいだに、コードは内部的にはどんどん改善されました。しかしエンドユーザーにとってはほとんど変化はありませんでした。一部のフォントはCSS のおかげで少しかっこよくなりました。この間、常に１００％稼動可能なコードを保持していたため、私はいつでもストップすることができました。（確認のため、稼動中の社内用のFogBUGZサーバーに毎回チェックインをアップロードしていました）
そして実際、私は難しく考える必要は全くありませんでしたし、ひとつもデザインする必要もありませんでした。というのも私がしていたことはすべて単純で論理的な変換だったからです。時々、私はコードのなかで、おかしな部分に出くわしましたが、それはほとんど数年間かけて行ってきたバグ・フィックスでした。運良く私はそれらのバグ・フィックスを手付かずにしておくことができました。こうした多くのケースで気づいたことは、もしゼロから始めていたなら、また同じバグを繰り返し作っただろうということ、それにまた何カ月間も、何年もそれに気づかなかったかもしれないということです。
私の作業は基本的に完了しました。計画したとおり３週間かけ、ほとんどすべての行のコードが前と違っています。そう、私は一行一行全てのコードを見て、そのほとんどを変えました。構造は完全に異なっています。すべてのバグトラッキング機能は完全にHTML UI 機能から独立しています。
私のコードクリーニング作戦の集大成がここにあります：
- 完全な書き換えよりはるかに少ない時間ですみました。仮に、（FogBUGZでここまでくるのにどれくらいかかったかをもとにして）完全に書き換えるのに１年かかったとしてみましょう。これは、私が４９週間分の作業を節約したということを意味します。この４９週は私が変えずに保存しておいたコードのデザインの知識を意味します。私は決して「お、ここで新しい行が必要だな」と、考えずにすみました。ただ何も考えず< BR >を< br / >に変えて、作業を進めるだけでした。ファイルアップロードのために複数の部分をどうやって稼動させるか考えずに済み、それはきちんと問題なく稼動しました。ただちょっと整理するだけでした。
- 新しいバグをほとんど持ちこみませんでした。もちろん、いくつかごく小さいのが入り込んだかもしれませんが、決してバグをひき起こすようなことは何もしませんでした。
- 必要ならいつでもストップしたり出荷したりできました。
- スケジュールは完全に予測可能でした。１週間の作業の後、誰でも正確に１時間で何行のコードをきれいにできるか計算して、プロジェクトの残作業に対してかなり良い見積もりができるようになります。Mozillaプロジェクトのように、ゼロから書き直しているみなさん、これを試してみてください。
- 今のコードは新しい機能により順応に対応できます。おそらく、最初に追加する主要な機能で、その3週間に対する報酬を取り戻すことができるでしょう。
リファクタリングについての文章の多くはMartin Fowlerによるものですが、コードのクリーンアップの原理は何年も前からプログラマーの間で周知のことでした。面白い新分野のひとつがリファクタリングツールです。これは、私かやったようなことの一部を自動的に行うプログラムの洒落た呼び方です。我々はまだ必要な良いツールすべてを有するには時間がかかりそうです－たいていのプログラミング環境では、変数の名前を変える（そしてそれを参照しているものがすべて自動で変化するようにする）というような単純な転換さえできません。ですが、それは徐々に向上してきています。もしあなたがプログラミングツールと呼ばれる物を売り歩く小さな会社を始めるか、オープンソースに有意義な貢献をすることを望むなら、その分野の門戸は大きく開いています。
この記事の原文（英語）は Rub a dub dubです。
