ホットコード置換の威力

今年の前半は主にC#のコードを書いていたのだが、Java側のフレームワークを拡張する依頼が発生したので、現在は急遽Javaの環境に戻って作業をしている。

C#の開発環境にはVisual Studio 2005をβ1の頃から一年近く使用しており、Javaの開発環境にはEclipse 3.1を使用している。これはEclipseに限ったことではないが、しばらくぶりにJavaの開発環境に戻ってみると、デバッグ、リファクタリング共にVisual Studioに比べても非常に快適なことに気がついたので、何が違うのだろうと考えてみた。

EclipseはJDK1.4.xから正式導入された「ホットコード置換」とJava開発環境を非常に上手く統合しているのが非常に大きな使い勝手の良さを生んでいる。
サーバサイドの開発、特にアプリケーションサーバ等、比較的重い、前処理の多いアプリケーション上でデバッグを行う場合は、できるだけデバッグセッションを止めたくないものだが、Eclipse + JDK1.4.xなどのホットコード置換に対応したIDEは、デバッグ中にコードを変更しても、そうやすやすとデバッグが中止に追い込まれることはないし、コードを変更することを注意されたり、変更をガードされることもない。(基本的にはクラスの仕様を変えないコード変更であれば再起動の必要は無い)
コードを変更して上書きのアクションを行った瞬間に、バックグラウンドでは差分ビルドが走り、一瞬でコードの変更が現在のデバッグセッションにも反映される。ブレークポイントに止まっている最中にスコープ内のコードを修正すると、ビルドを反映した後にそのスコープの先頭からコードを実行し直してくれるのである。もう素晴らしいったらありゃしない。

MicrosoftにはVBの頃から「Edit and Continue 」という機能があったが、Visual Studio 2005でも同様の機能がC#言語サポートにも新たに追加された。当初、私はこの機能が追加されると聞いた時には、真っ先にJavaのホットコード置換と同様の機能だと思ったのだが、実際に追加されたエディットコンティニュは、デバッグ時のコード変更の制限が厳しく、ホットコード置換と同じような使い方にはほど遠いことが解って非常に残念だった。

インタラクティブなデバッグは堕落であり、ソースコードを追う力が育たない、コードを読まないプログラマになる等、苦言を呈する人もいるが私はそうは思わない。コードを追う、読む力は、そのように努力しようとする力も含めて、問われるのはその人の資質であり、デバッグを支援する便利なツールの是非を問うことと結びつけてはいけないと思う。
複雑で長いコードは悪とされている時代であり、アジャイル、テスト駆動開発等によりデバッグに割く時間はどんどん短くなっている。最短の時間の中で最も効率良くデバッグを行う道具として、インタラクティブなデバッグは非常に有用であり、更に使い易く進化して欲しいと思う。