Eclipseからテキストエディタに戻れない10の理由
ソフトウェアはいろいろな作業の効率化に貢献してきた。プログラミングという作業も例外ではない。現代の高度なIDE(統合開発環境)はプログラマが単純でつまらない作業に時間を割かずに済むようにさまざまな機能を提供してくれる。
もうテキストエディタ＋コマンドラインでのコンパイルなんて環境には戻れない。以下は自分が仕事でメインに使っているEclipseというIDEを使い続ける理由。
（追記）私は仕事では主にJavaの開発をやっている。C/C++/C#の開発では以下に挙げるメリットを享受できない部分があることを断っておく。
1. コードの自動補完
標準API+フレームワークのAPIで万単位のクラスが存在するので、暗記は無理。クラスに存在するメソッド名、フィールド名までの暗記はもっと無理。よく使う範囲なら暗記しているけど、typo -> コンパイルエラー -> 探して修正 の手間より、自動補完が断然効率的。補完の際はクラス名だけ入力すればimport文も自動的に補ってくれる。
よくあるコード定型はCtrl+スペースで記載できる。mainと書いてCtrl+スペースでpublic static void main(String[] args)が一発で書けるし、System.out.println();だってsysoと書いてCtrl+スペースで書ける。長ったらしくて面倒とかいうのは補完がない環境の人の愚痴に過ぎない。
悪名高いJavaのsetter, getterも自動生成で一発。ウザさはともかく、プログラマが面倒なタイピングを行う必要はない。継承元クラスのコンストラクタのシグニチャに合わせてコンストラクタを生成なんてこともしてくれる。
2. 構文解析を伴う高度なシンタックスハイライト
予約語のハイライトぐらいなら秀丸ぐらいのエディタでも可能だけども、Java言語の構文を解析した上でのハイライトはエディタではちょっと無理。例えば、ある文字列が、ローカル変数である、インスタンスフィールドである、staticフィールドであるといった区別をした上で、見分けがつくようなハイライトを行ってくれる。
非推奨メソッドは取り消し線で表示されるし、変数宣言のハイディングもチェックしてくれるし、構文をチェックした上であれこれ配慮してくれるのはヒューマンエラーの軽減に大きく貢献する。
3. 宣言への移動など
メソッド名を選択してその宣言部分にジャンプしたり、メソッドにカーソルを合わせるだけでメソッドのjavadocを表示したり、クラスのソースにジャンプしたり（jarファイルで参照しているライブラリでもソースがアタッチされていればジャンプ可能）、型階層をツリーで表示したり、あるクラスやメソッドを参照している場所を検索したりする機能がある。
Eclipseでは標準でTODOやFIXMEなどのコメントを一覧管理する機能が付いているし、ソースコード中にブックマークをする機能もついているので、コードを読んで分析するときにもメモをしながら読めるので非常に重宝する。
4. コードのフォーマットチェック
コーディング規約を定めているプロジェクトは多いが、細かいコードのフォーマットなんか人力でチェックなんて労力的に無理で、フォーマットや命名が統一されたコードなんて作りえない。機械によるコードフォーマットチェックならばコーディング規約を実施させることが可能になる。
また、単純にフォーマットをそろえるだけなら手作業でなくとも機械で一律のフォーマットに変換することができる。
（追記）Eclipse標準ではフォーマットはほとんどチェックできない。ここではCheckStyleプラグインについて述べている。興味のある人は調べてみるとよいだろう。
5. 危険なコードの検出
String型を==で比較しているとか例外をcatchして握りつぶすといった潜在的に危険なコードは機械がチェックして警告してくれるため、コードの品質を底上げできる。目視によるソースレビューでは漏らしてしまうものを確実に網羅することができる。
またFindbugsのようなプラグインを利用することでより高度なバグパターン検出が可能となる。技術のないコーダの書いたコードをレビューする手間が省けるのは大きい。警告が出て対策が分からないなら報告をしろと厳命しておけばよい。
6. バージョン管理ツールとの連携
CSVやSubversionなどとの連携機能を持っているので、エディタ上で履歴も見れればdiffもとれる。またtracやRedmineといったプロジェクト管理ツールと連携してチケットの編集や、そのチケットの作業に伴って変更されたソースの管理などが行える。
8. 自動テストツールのサポート
JUnitによる自動テストの標準サポート。プラグインなどを用いればテストのカバレッジ計測もできる。プログラムがろくに書けない奴にはテストコードの作成でもやらせておけ！
9. リファクタリング機能
メソッド名などのリネームに伴い利用箇所を網羅して一括変換するような機能性や、長いメソッドから範囲指定してメソッドを抽出する機能、メソッドの引数などの変更機能（利用箇所も網羅して変換）、親クラスへのメソッドの移動、子クラスへにメソッドを展開するなどといったリファクタリングをサポートする各種機能が用意されている。
手戻りの工数が大きからと言う理由で設計を慎重に行っていたのは前世紀の話。安全に手間無く設計をいじれるようになったため、プロトタイピングとリファクタリングによる極楽な開発スタイルになった。大体、試作もなしに紙の上で一発で設計ができるとか考える方がどうかしている。
10. コンパイルエラーに対して解決策を提示
コンパイルエラーがあった行の警告マークをクリックすると、コンパイルエラーを解決するための解決策を提示してくれる。コード補完の一種とも言えるかもしれない。
メソッドなどのシンボルがない場合はそのメソッドを作るという選択肢があり、クリックすればメソッドのひな型が作成される。オーバーライドしていない抽象メソッドがあれば、そのメソッドのひな型を書いてくれる。catchしていないチェック例外があればtry-catch文を補完してくれるなどなど。
機械化によって前提が変わる
既存の開発スタイルというのは、後で行うと手間がかかるというデメリットを回避する目的でいろいろなモノを禁じたりしてきたかもしれないが、そもそも機械化によってその手間がかからなくなったという前提の変化があったならば、禁止する理由もなくなるのだ。
リファクタリング機能の充実は、変更の手間を劇的に軽減した。後でいくらでも安全に手間無く変えられるという前提の世界ではプロトタイピングをがしがし行う方が効率がいい。プログラムの前に綿密な設計を考えるのは、後での設計変更が莫大な手間であるから故の策のはずだ。現状のリファクタリング機能で持っても手間がかかる部分は慎重に設計しなければならないが、後で全貌が見えてから直せばいいやという部分も相当に増えた。とりあえずプロトタイピングする、というスタイルが可能になったのだ。
機械化でソースレビューも楽になった。しれっと酷いコードが隠されていて地雷を踏んでは手当てをするようなプロジェクトの進め方はもうしなくていい。単純な潜在バグは機械的にあぶり出せる。くだらないバグに時間を取られることはない。
こうした前提の変化は、開発効率を劇的に上げる。何より下らない作業に追われてモチベーションを下げることがなくなる。ごきげんな開発を行えるのだからやめられない。
