シェルやエディタの話は昔から宗教戦争を引き起こす危険な話題です。弊社でもこれまでは開発環境は個々人の自由で、かつ、IDE 派は少数でした。
ですが、弊社では Kotlin, TypeScript への移行に伴い、開発環境もまた IntelliJ IDEA や Visual Studio Code に移行しているところです。ちょうど「IntelliJ IDEA ハンズオン」という書籍が出版されたこともあり、あえて IntelliJ IDEA 及び Visual Studio Code (以下 VSCode) の魅力を語ろうと思います。
vim や emacs から見ればイケてないところ
まずはこれまでのエディタからの立場で、IntelliJ IDEA や VSCode のちょっとイケてないところを見てみましょう。
ターミナルで使えない
ssh などターミナルで直接使えないのは決定的な違いですね。
いずれも GUI アプリなので、リモートのファイルを編集するためには VSCode では sshfs を使う必要がありますし、IntelliJ IDEA も remote server 機能を使わなければ編集できません。
逆に言えば、適切に設定すれば ssh だけで編集できるということでもありますが。
キーボードだけで操作できない
これは主に IntelliJ IDEA で顕著です。
IntelliJ IDEA はキーボードフレンドリな IDE でほとんどの機能をキーボードで操作できます。
しかし、ツールウィンドウを操作する小さなボタンなど、ショートカットキーが定義されていなくて、マウスでないと使えない機能がどうしても残っています。
GUI で設定しないといけない
これも IntelliJ IDEA の問題になります。
カスタマイズ性の高さは emacs や vim に比べて決して劣りませんが、設定が GUI でないと変更できないのは問題です。もちろん GUI なので手軽に設定はできるのですが、設定ファイルを git で管理したり、共有したりする、となると途端に難しくなります。
VSCode は GUI で設定もできる箇所もありますが、基本的に JSON ファイルで直接編集するインターフェースが用意されています。git による設定管理は簡単に行えます。gist をリポジトリとして、様々なマシンの環境を自動同期してくれる settings sync という便利拡張も有名です。
プログラマブルではない
プログラマブルでないというのは言い過ぎですが、プログラムによるカスタマイズの敷居が少々高いです。
IntelliJ IDEA も VSCode もあくまで設定であって、 emacs lisp や vim script のようにプログラミング言語ではないので、設定ファイルにちょっとコードを書いて機能拡張することはできません。
機能を拡張するためにはどちらも拡張(プラグイン)として作成する必要があり、特に IntelliJ IDEA で独自拡張の作成は敷居が高くなってしまいます。
学習コストの高さ
これも IntelliJ IDEA に偏った問題でしょうか。
プロジェクトやモジュールをはじめ独自の概念が多数あり、設定もすべてを把握するのはもはや不可能なほど大量の項目があり、ちょっと触ってみようとするには少々腰が重くなってしまいます。
開発環境としての魅力
さきほどはこれまでのエディタと比べてイケてない点を挙げてみましたが、一方で後発だからこそ IntelliJ IDEA や VSCodeの強みはたくさんあります。でないとこの記事を書く意味がありません。:)
GUI の手軽さ
現代のアプリとしては当たり前とも言えますが、IntelliJ IDEA も VSCode もマルチプラットフォームです。どちらも高機能な GUI を持ちながら Windows, macos, Linux いずれも同じように利用できます。
設定が GUI なので、説明やカラースキームなど変更したときにどう変わるかをプレビューで見ながらカスタマイズが可能です。これは git で設定ファイルを管理できないというデメリットの裏返しでもありますが。
VSCode では markdown や Plant UML もプレビューしながら編集できます。これも GUI だからこそのフィーチャーですね。
コマンド体系が複雑な git も、変更ツリーや現在の状態、diff などすべて GUI から扱えるのも嬉しいポイントです。オジサンになると git のような複雑なコマンド体系を覚えることはほぼ不可能に近いのです。:(
IntelliJ IDEA だとさらに強力でデータベースやコールツリー、コードの継承構造や依存関係など、グラフィカルに構造を把握できるツールが非常に充実しています。
ビジュアルデバッガ
GUI だからこそできることではありますが、あえて別項目としました。
条件付きブレークポイント、停止時点の変数やコールスタック表示、スタックの巻き戻し、任意のスタック時点でのコード評価など、ビジュアルデバッガなしでどのように開発するのか私には想像もできません。
Developer Tool のない Chrome で web 開発しろ、と言われるとイメージいただけるでしょうか。30代以上の方は、Firebug が生まれるまでは、コンソールすらなく alert やメッセージ表示用の pre 要素を作って print デバッグしていた頃の苦労を知っていると思います。
ナビゲーションの高機能さ
クラスやメソッドなどのシンボルやファイル名から一発で対象ファイルを開くことができます。
コマンドパレットと呼ばれるキー入力でコマンドを探して実行する機能も標準装備です。
emacs だと anything, vim だと unite 等で頑張って設定しないといけない機能が何ひとつ設定することなく、より高度な機能として組込まれています。
最初から用意されている豊富な拡張
IntelliJ IDEA も VSCode も拡張(プラグイン)の標準インターフェースが定められていて、標準の拡張リポジトリがあります。
つまり、chrome 拡張や firefox アドオンのように手軽に拡張をインストールして使うことができるのです。
キーバインドレベルの互換性
IntelliJ IDEA, VSCode ともに emacs キーバインドは標準で用意されていますし、vim キーバインドはそれぞれ ideavim, vim extension と拡張機能で用意されています。
設定ファイルでカリカリにチューニングをしていなければ、コードエディタ上の操作性はほとんど変わらないと言えるでしょう。
とはいえ、emacs / vim の利用歴が長い人ほど秘伝のタレのように調整してきた設定ファイルこそが命で、標準キーバインドが同じというだけではなかなか移行の決心がつかないかも知れませんね…
言語を知っている
エディタと IDE の違い
テキストエディタと IDE の本質的な違いはプログラミング言語を構造的に処理できるかどうか、と言えるでしょう。VSCode はテキストエディタとしての機能も優秀ですが、コードを書くという観点から考えれば IDE と呼んでも支障はないと思います。
わかりやすい例で言えば、テキストエディタでは外部ツールである ctags を使っての定義検索がどうにかというところですが、IDE ではメソッドの定義箇所にジャンプしたり、特定のインターフェースを実装するクラスを一覧化したり、プログラミング言語の構造に従ったナビゲーションが可能です。
静的型付け言語の復権
Ruby などの動的型付け言語の開発ではテキストエディタと IDE の差はそう大きくありません。型情報を得られないため IDE が補助できる領域が限られてしまうためです。
しかし、現在、2010年代後半からは静的型付け言語の復権がはじまったといっても過言ではないでしょう。先日の Stack Overflow の調査でも Kotlin, TypeScript, Rust, Go, Swift, Scala などモダンな静的型付け言語が人気でした。
型情報があるからこそ自動補完や自動インポートが可能になります。
現代のプログラミングで必須とも言えるリファクタリングも自動化され、名前変更やメソッド抽出といったよく使うリファクタリングは、キーボードショットでインラインで実現できてしまいます。
コンパイラの進化
IDE が高機能になったのはコンパイラの進化も大きく貢献しています。
IDE 独自コンパイラ
かつては IDE が独自にコンパイラを実装してました。標準のコンパイラはバッチとして一度にコンパイルするので、AST をはじめとするコンパイル中の情報が得られないからです。
AST や型情報などプログラム構造の情報の取得、編集中の不完全なコードを処理する機能がないと IDE では自動補完の候補一つ出すことができません。
Eclipse の Java コンパイラが高速なので Tomcat が JSP コンパイル用に利用している、というのも IDE が独自にコンパイラを作らざるをえなかった時代だから話題になりましたね。
コンパイラの作り方が変わった
コマンドラインやビルドツールから実行する通常のバッチ式コンパイラと、中間情報を必要とする IDE 用のコンパイラをそれぞれ開発するのは明らかにリソースの無駄使いです。
C# の Roslyn プロジェクトが有名ですが、バッチコンパイラと IDE 用コンパイラを分けるのではなく、一つのコンパイラとして API 経由で情報を取得したり、AST を変換したり、処理をフック可能なコンパイラの実装が増えてきました。
Language Server Protocol
さらなる進化として Language Server Protocol があります。
TypeScript / VSCode の機能をもとにコンパイラを操作する HTTP API が Language Server Protocol (以下 LSP) として標準化が進んでいます。
これまでは各 IDE が言語ごとに独自コンパイラを実装するしかなかったので、IDE が対応している言語しか使うことができませんでした。
しかし、今では IDE とコンパイラが LSP に対応していれば、好きな IDE やエディタで自動補完やリファクタリングをはじめとするプログラミング言語サポート機能が利用できます。
LSP は IDE では VSCode 以外では vim や Eclipse が対応しており、プログラミング言語では TypeScript だけでなく Rust や Python に PHP などが対応しています。(厳密に言えば TypeScript / VSCode の開発の中で標準化がはじまった規格なので、VSCode と TypeScript 間には LSP は利用されていません)
新しい道具を積極的に試していこう
慣れた道具は変更しづらい
ソフトウェアエンジニアが意外と古い道具に頼っていることはままあります。
道具は使い込めば使い込むほど体に馴染みますし、設定という継ぎ足し継ぎ足し煮詰めてきた秘伝のタレを各自持っているので、新しい道具に乗り換えるのは難しいのは確かです。
新しいサービスを作る立場だからこそ
私達ソフトウェアエンジニアは新しいサービスやシステムを開発するのが仕事です。そして、そのような新しいサービスやシステムはライフスタイルや仕事の仕方自体を変えるものです。
ドッグフーディングという言葉がありますが、仕事の仕方や生活を変えるプロダクトを生み出す立場だからこそ、積極的に新しい道具を試し使いこんでいく心構えが必要なのではないかと思います。
ちなみにこの記事も早起きしたのでベッドの上で音声入力を使ってほとんど書き上げました。
IDE もエディタも進化している
本題に戻りましょう。現代の IDE もエディタは凄まじく進化し続けています。
VSCode は今や Github では最もコントリビューションの多いプロジェクトです。
IntelliJ IDEA も新しい言語やフレームワークへの追随が非常に早い IDE です。
いずれも無償で利用できるので、是非試してみてください。
この記事が新しい環境を使ってみる後押しになることを願って。