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

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

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

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

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

以下はFog Creekにおける.NET開発ツールへの段階的な移行に関して、現在私が考えていることだ。

現状: CityDeskの大部分はVisual C++ 6.0で書いた部品を使いVisual Basic 6.0で書かれている。FogBUGZの大部分はC++で書いた部品を使いASP上のVBScriptで書かれている。社内ツールや私たちのWebプレゼンス(Fog Shop、Discussionsなど)はASP上のVBScriptで書かれている。

そもそも.NETに移行するのはなぜか? 端的に言えば、それは.NETがかつて作られたものの中で、もっとも生産性が高い優れた開発環境のひとつだと思えるからだ。ASP.NETを使うと役に立つWebアプリケーションを驚くほど簡単に作ることができる。この2日間、私は社内で使うあるアプリケーションを自分でも驚くほどの早さで作っていた。 ASPでWebアプリケーションを作る時間の75%を占めていた汚い部分(フォームの入力チェックとかエラーレポート出力とか)が全く簡単になっている。 ASP.NETはCに対するJavaと同じくらい大きな生産性の飛躍だ。ワオ。

C#はJavaの良いところの多くと、自動ボクシングのようなちょっとした改善を合わせ持っている。私たちはASPとVB6で書く場合でも、コードをオブジェクト指向的にするためにできることは何でもしてきたが、それでもC#への移行はすばらしいことだと思う。

最後に.NETとともに出荷されているクラスライブラリの素晴らしいこと。データベースアクセスやWeb開発からGUI開発まで、すべてが再設計されているという事実は、上から下まで驚くほどの整合性があることを意味している。古いWin32 APIを見てみるといい。関数から文字列を返すためにいかに多くの方法が使われているかは驚くばかりだ。彼らは2年ごとにそれをやるいちばんいい方法が何かについての考えを変えたもののようだ。.NETではそれらすべてがすっきりしている。私はひと月のカレンダの中から日付を選択させるためのHTMLを生成するASP.NETカレンダウィジェットが使えるのがうれしい。そしてそこから受け取る｢日付｣クラス(System.DataTimeだと思う)が SQL Serverクラスの使う日付クラスと同じだろうことは自信を持って言える。SQL文のために日付の形式を直したり、あるいはCOleDateTimeを別な日付型に変換したりといったことのために、今まで私たちがどれほど多くの時間を無駄にしていたか、あなたは信じられないかもしれない。最後に— string型がどこででも使えること! 先週ATLコードを書いていてBSTRとOLECHARとchar*とLPSTRをいじくり回していたが、あれはなんという混乱だろう。いい厄介払いができた。

.NETがルール｢決してスクラッチから書き直すな｣を破っていることは認めよう。Microsoftは2つの事実により、それをうまくやってのけることができた。第1に、彼らは過去20年のソフトウェア開発における生産性向上の90%に寄与した世界最高の言語設計者、アンダース・ヘジルスバーグを擁している。彼はTurbo Pascal(感謝!)、Delphi(感謝!)、WFC(いい試みだ!)、そして今度は.NET(場外ホームランだ)を私たちにもたらしてくれた。第2 に、競争が多かれ少なかれ落ち着いていた約3年の間に、彼らは膨大な数のエンジニアを投入したのだ。覚えておいてほしい、Microsoftにできたならあなたにもできるとは限らないということを。Microsoftは自分用の重力さえ作り出すのだ。通常のルールは彼らには適用できない。

さて、今頃2、3ダースの人たちが怒りのメールを書きはじめ、Write Once Run Anywhereを実現する(笑)Javaだとか、Delphi(才能は去ってしまった。.NETはDelphi 7.0であり8.0であり9.0である)だとか、Lispだとか、あるいは何であれ別な開発環境を賞賛し、それを使ってみてはどうかと薦めようとしているかもしれない。彼らは私がMicrosoftのトランクに閉じ込められていると言うだろう。残念ながら今は宗教上の議論をしている時間がないし、それにそんな議論はたいがい退屈なものだ。日本語が英語より優れた言語かどうかに私は興味がない。そんなことは問題ではないのだ。私たちの戦略について最後まで書かせて欲しい。

第1の問題: 我々はいいコードが書けるほど.NETのことをよく知っているわけではない。通常どんな開発環境でも、何かをする方法はたくさんあるものだが、私たちは2 番目はおろか、最初の方法さえまだ学んでいない。だから私たちに書ける.NETコードの品質は出荷できるほど良いものではない。ウィリアム・ボーンの最初のADO 本が出るまで、私たちは基本的なSQLクエリーを行う最適な方法さえ知らなかった。だから私たちの第1の優先事項は教育であり、それは将来における社内システムとWebベースの開発(基本的に誰も金を出さないソフトウェアのすべて)を.NETを使って行うことで達成されるだろう。私たちはFog Shopの一部を.NETに移行し、社内システムのあらゆるものに.NETを使うだろう。(今日私はFogShopのクーポンジェネレータを ASP.NETで書いた。少々ごちゃごちゃしているがちゃんと動いた!)

第2の問題: 大きすぎる20MBのCLRランタイム。8MBのCityDeskダウンロードのうちの6MBほどをランタイムとデータアクセスライブラリが占めているということだけでも十分具合の悪いことだ。CityDeskのスターターエディションを自宅で使うユーザが、さらに20MBダウンロードしてくれるのを当てにすることはできない。うまくすれば1年か2年か3年の内には、多くの人々が別なところから手に入れたCLRを持っているようになるだろう (MicrosoftがWindows XPにそれを入れなかったのは残念だ)。私たちはその辺のところを見守っていくつもりだ。Microsoftはユーザエージェント文字列を変えてきた。それを続けてくれれば、私たちはユーザの実行環境について統計を取ることができる。

結論を言うとCityDeskもFogBUGZも今はまだ.NETに移植できない。私たちはCLRの普及率が75%になったらCityDeskの将来のバージョンを移植するだろう。移行計画は:

1. 既存のコードとフォームをMicrosoftの変換ツールを使って移植する
2. 再び機能するようになるまで、力任せで問題をフィックスする
3. 新しいフォームやクラスはC#で作る
4. 古いフォームやクラスに大きく手を入れる場合はC#に移植する
5. 多くのフォームやクラスは、それがちゃんと動く限りは永久にVB.NETのまま残るだろう(後方互換のための醜い文字列関数などを使って)。

FogBUGZもサーバマシンにおけるCLR普及率が高くなることが必要だ。カスタマサーベイを行ってFogBUGZにCLRが必須となることがどれくらいまずいことなのか知る必要がある。

私たちにはまだ公にしていない開発中の製品がある。それはコードベースの多くの部分をFogBUGZと共有することになるだろう(このサブセットは Dispatchoと名付けるつもりだ)。そのためFogBUGZが移植されるまでは、こちらも基本的にVBScript/ASPのままとなるだろう。

FogBUGZ/Dispatcho/秘密の新製品の移行計画は:

1. CLRを前提とすることがOKとなるまで待つ
2. 既存のビジネスロジックをC#クラスに移植する
3. 現在のWebフォームはASPのままとする
4. 新しいWebフォームはASP.NETで作る