現在最もホットなプログラミング言語は何か、といえばJavaと答えるしかないだろう。正直最初に見たときは、これだけの普及を見せるとは夢にも思わなかった。予想をはるかに超える勢いで浸透し、しかもプログラミングという文化において、新しい動きを見せつけてくれている。それはパラダイムにとどまらず、ツール面でも新しい動きをしつつあるので、ちょっと解説してみよう。

EclipseというIDE[*1]がある。基本的にJava言語のためのものであり、なおかつJavaの実行環境で動くものだ。いわゆる流行のオープンソースのプロジェクトなので、誰でも自由に使うことができる。Javaで動くってことは、Mac OS Xでも問題なく動く（多少問題あるが、笑[*2]）。

これを使うと、もちろんコードを書いてビルドしてデバッグを行うことができる。普通の開発環境であれば、開発者と開発環境の関係はこのサイクルの繰り返しで終わる。しかしEclipseは、さらに開発者にとって便利な機能を提供する。まずはテスト環境だ。

11月号で簡単に紹介したが、「テスト・ファースト」という開発手法が最近の流行で、特にJavaの世界では一般的に受け入れられている。テストをするってひとくちに言っても たまにやる程度では意味がなく、またテストのプロセスが煩雑であれば頻繁に行えない。いつもテストができて結果をひと目で判断できなければ意味がないのだ。となると、開発サイクルにテストを組み入れるという考え方にたどり着く。Eclipseはテスト環境を内蔵しているので、コードを実行する前に必ずコードをテストすることが簡単にできる。

これは、デバッガとは似て非なるものだ。デバッガはコードに問題がありそうな部分で実行を止め、詳細を見ていくというものだが、テスト環境はその逆で、細かいことは知らないがこれが成功するかどうかだけ教えてくれ、というものだ。テストが失敗して初めてデバッガの出番となる。テスト環境がないと、出来上がったものを普通に使ってテストしてみるしかない。総当たりでいろんな動作を試してみて、運が良ければ問題が見つかる、という感じだ。テスト環境はそんな不確実で面倒な手間を自動化してくれる。

テスト結果は緑や赤など色を使って視覚的に表示されるので、成功したか失敗だったのかの把握も一目瞭然だ。クリックで該当部分を表示でき、修正するのも楽なのだ。デバッガがあったのにこうしたテスタがなかったとは、まだまだ、開発環境なんてものは未成熟の分野なんだな、と思い知らされる。
さてもう一つ、Eclipseですごいな、と思ったのが「リファクタリング」への積極的なサポートだ。これも以前に紹介した最近の開発手法であるが、テストのように独立しているものではなく、コードを書いていく過程で付随的に発生してくるものである。悪いところはどんどん直そう、コードをいじることを恐れるな[*3]というものである。

いままでの開発環境で実際コードを書くときに使えるサポート機能と言えば、関数の自動補完と呼ばれる機能があった。これはすでに定義された関数があって、他の場所でその関数の名前の頭数文字を入れると候補としてその関数を表示してくれるというものだ。SafariのURL入力のフィールドと同じようなもので、それがエディタ全体で使えるものと想像してもらえればいいと思う。新しい機能ではなく、Windowsの開発環境では当たり前についていて、CodeWarriorにもXcodeにも、もちろんEclipseにも用意されている。しかし、プログラマがコードを書くうえでのサポートと言えばこの程度のものであった。

Eclipseのリファクタリングのサポートは、もっと積極的にコードの編集作業にコミットしてくる。簡単な例を見てみよう。例えばプログラムで使っている変数名が実情と違う名前が付いているので、変更したいと思い立った。変数名cではなく countに変えたいとしよう。これまでだと、手作業で1つ1つ変えることになる。でもたくさんあるんで大変。よし一括置換で「c」を全部変えてみるか。いやいや、そうすると単語の一部で使われている「c」も変換してしまう、1単語として認識できる「c」のみを変えるぞ。おっと、別の場所で「c」は文字を表す意味で使われてしまっていた、そいつらは変えちゃダメだよ！……という感じになる。こんな単純な事例を見ても、実はいろんな判断のうえに成り立っている作業なのだ。Eclipseなら、この関数で使われているこの変数名をこれに変更しろ、と一発の指示で済んでしまう。もちろんこのほかにも、もっと複雑な変更に対してサポートが用意されている。これは強力な機能だ。

こうしたことができるのは、1つにはJava言語だから、ということがあると思う。Java言語はコードに関する規約がかなりしっかりしている。クラスや関数の名前の付け方はこうしましょう、大文字小文字の使い方はこうしましょう、この名前の規則に従ったメソッドは必ず同じ動きをすべき、などなど。C言語ではそんなものはほとんどない。最近でこそアップルの提供するAPIには統一した名前が付けられるようになってきたが、開発者がそれに従っているわけではない。面白いことに、Objective-Cではコーディングの世界観を前面に出していることもあり、この辺の規約はしっかりと決まっている。これは以前からInterface BuilderとProject Builderが連携して動いているという事実からも見て取ることができる。それもそのはずで、実はObjective-CがJava言語に大きな影響を与えていることを考えると、さほど不思議なことではないかもしれない。

なんかEclipseの説明でページが尽きてしまったので、来月まとめとして、こうした動きと、Xcodeの拡張性について見ていきたいと思う。ま、実はオレは考え方の違いもあって、このEclipseを使っていないんです（笑）。その理由なども来月に。

バスケ（http://www.saryo.org/basuke/）
年末です。忘年会シーズン。つまり酒の毎日です。ふー。うまいねぇ。やっぱ酒呑むために働いているんですよ、オイラ。どんなにつらくとも次の日が。ええ。さー明日も呑み会だ。大晦日までがんばるぞー。仕事も。ええ。

[*1] IDE - Integrated Development Environmentの略。いわゆる統合開発環境。
[*2] 多少問題あるが、笑 - 見方によるとかなり問題がある。まぁ見方次第。
[*3] コードをいじることを恐れるな - ちょっとはしょりすぎちゃってます（笑）。、あぁ気持ちとして、そんな感じのものです。