新しいIDEと付き合う
Javaで開発する場合、Eclipse、IntelliJ IDEA、NetBeansのいずれかを使うのが一般的です。ビズリーチでもEclipseが主力でしたが、今はIntelliJ IDEAに、ほぼ全面移行しました。JavaだけでなくScalaのプロジェクトも増え、さらにフロントエンドエンジニアがTypeScriptの導入を進める中で、すべての言語に一貫性を持って対応できるのはIntelliJだけではないでしょうか。
しかしEclipseからIntelliJに移行する中で意外なネックがありました。エンジニアの開発用マシンでアプリケーションサーバを起動するために、Eclipseのプラグインに頼っていたのです。SysdeoプラグインやWTPプラグインと類似の、自社で内製したプラグインでした。その当時の我々のコードベースではIntelliJのTomcat連携機能でもアプリケーションを起動できませんでしたので、そのままではエンジニアもデザイナーもEclipseから離れることができません。
しかし、
public static void main(String ... args){}
といったエントリーポイントを経由して、
tomcat = new Tomcat();
で起動するように変更すると、IDEやそのプラグインへの依存性は全くなくなりました。
また、ビズリーチシステムではWebデザイナーもサーバーサイドエンジニアと同じコードベースで作業をしていますが、そもそもEclipseやIntelliJはWebデザイナーの作業環境として最適ではありません。そこで、
mvn compile exec:java jp.bizreach.Main
という単純なコマンドでアプリケーションを起動できるのであれば、Webデザイナーに重厚なIDEの使用を強いる必要もなくなります。
事業的には一見無意味に思えるこの変更は、前述の通りデプロイ戦略に柔軟性をもたらすだけでなく、ローカル開発環境を自由に選択しWebデザイナーも含む開発チーム全体の生産性を上げるために必要不可欠なことだったのです。2014年にSpringフレームワーク上に登場したSpring Bootは、こうした戦略を初めから実現してくれます。ビズリーチシステムの一部のサブシステムもSpring Bootに移行しています。
フレームワークを選ぶ、あるいは変える
ここでいったん12-Factor App戦略から離れ、アプリケーションの骨格を考えてみます。エンジニアがアウトプットしてWebサービスを事業として成立させるには、巨人の肩に乗ることが早道です。フレームワークがその1つです。
Java言語の強力な型システム、あるいはインターフェースに向かってコードを書けるという利点を最大限に活かせるのが、DI（Dependency Injection）の概念とそれを実現するフレームワークです。初期のビズリーチシステムではDIコンテナとしてSeasar2を使用していました。現在はSpring 4.3です。Seasar2からSpring 3に移行した際の話をしたいところですが、残念ながら筆者はそのころはまだビズリーチにいませんでした。
Spring 3からSpring 4への移行だけで考えると、それほど大きなコード変更は必要ありませんでした。下位互換性の高い言語とフレームワークを選択したことが、高い生産性をもたらしたと言えます。唯一大変だったのはXML設定のJavaConfig化です。XML設定のままでもSpring 4は稼働しますが、開発チームとプロダクトの巨大化が進む中、生産性を落とさずにスムーズに開発し続けるためには、Javaのタイプセーフ性を生かせるJavaConfig化に取り組むべきだと判断しました。
