確立されたエンタープライズ環境に新しいJVMプログラミング言語を導入する

現在の職場がJavaショップだと想像してください。Java言語については多くの知識が蓄積されており、すべてをスムーズでアジャイルな方法で処理するための包括的なビルドおよび展開プロセスが用意されています。

ある日、たとえばRubyで書かれようと叫ぶプロジェクトが始まります。上級開発者のみがRubyについての手がかりを持っていますが、JVMにはJRubyが存在するため、既存のインフラストラクチャを引き続き使用およびサポートできるという一般的な考え方があります。また、JRubyは、より少ないコードで現在のアプリケーションを実装するより良い方法への道を示すことができるため、これは継続的な移行を表すことができます。

JRubyは単なる例であり、Clojure、Groovy、またはJVM上で実行される他のすべてのものであることを忘れないでください。

問題は、このような変更をどのように導入するかです。

免責事項：JVMでのPolyglotプログラミングに関する本を執筆しているため、偏見があります（Shameless Plug !!-The Ground-Grounded Java Developer）:)

まず、本当に保証されている場合にのみ変更を導入する必要があります！

始めるのに適した場所は、Ola Biniのプログラミング言語ピラミッドを検討することです。オラは、安定した動的なドメイン固有の言語について語っています。

Javaは安定した言語（静的に型付けおよび管理）であり、さまざまな理由（人々が興味を持っている場合は後で説明します）は、動的なレイヤープロジェクト（ラピッドWeb開発など）またはドメイン固有のレイヤープロジェクト（モデリングなど）には理想的な選択肢ではありませんEnterprise Integration Patternドメイン）。これらのレイヤーのいずれかに適合するプロジェクトがある場合は、開始するのに適した場所になります。

代替言語が提供する基本的な機能がある場合は、安定したレイヤーに新しい言語を導入してJavaを置き換えることも検討できます。たとえば、Scalaは、Javaよりも安全で自然な方法で並行性を処理します。

要求されたように、これについてもう少し。WRT Java：

• 再コンパイルは面倒です
• 静的型付けは柔軟性がなく、リファクタリング時間が長くなる可能性があります
• 展開は重いプロセスです
• Javaの構文はDSLの生成に自然に適合しません

この時点で、次のことを自問するかもしれません。どの言語を選択すべきですか？」、特効薬はありませんが、選択を評価する際に考慮できる基準がいくつかあることを思い出してください。

ドメイン固有

• ビルド/継続的統合/継続的展開
• 開発者
• エンタープライズ統合パターンモデリング
• ビジネスルールモデリング

動的

• 迅速なWeb開発
• プロトタイピング
• インタラクティブな管理/ユーザーコンソール
• スクリプティング
• テスト駆動開発/行動駆動開発

安定した

• 並行コード
• アプリケーションコンテナ
• コアビジネス機能

小さな低リスクモジュール（これらのJVM言語は多くの場合、既存のJavaコードと美しく相互作用する）またはプロジェクトから始めます。これが使い捨てのプロトタイプになることを明確にしてください。

その言語のプログラミングのライフサイクルとツールの側面を調査したことを確認してください。TDD、ビルドツールおよび継続的インテグレーションの実行、強力なIDEサポート、およびその他のすべての要素を使用できることを確認したいでしょう。一部の言語では、特定のツールが存在しないか、非常に基本的なものであることを受け入れる必要があります。開発者とツールのサポートの強さは、言語の強さを上回る場合があります。

チームが動けなくなったときに役立つ、活気のあるコミュニティがあることを確認してください。これにはローカルユーザーグループの方が優れています。

特に言語がオブジェクト指向スタイルの言語でない場合（Clojureへの移行は簡単ではない）、開発者が最初の言語トレーニングを受けるようにしてください。

それについてだと思います。私は、XML処理、クイックWebサイトの構築、データのクランチなどのタスクに、Groovy、Scala、ClojureをJavaと並行して開発に個人的に使用しました。

「もしあれば」という発言で取り上げられたトピックについて、いくつかの考えを追加したいと思います。実際、なぜチームに追加の言語を導入する必要があるのですか？確かに、1つのプロジェクトだけを見ている場合、新しい言語がタスクの理想的なツールとして突出している可能性があります。しかし、多くのプロジェクトを作成する場合は、時間が経つにつれてかなりの数の追加言語が作成される可能性があります。メンテナンスサイクルとプロジェクト番号についてはわかりませんが、チームは以前よりも多くの言語でかなり多くの専門知識を提供する必要があるでしょう。

ビジネスの観点から見ると、言語を追加するということは、チームに複雑さと知識の要件を追加することを意味します。これにより、職業調整の期間が延長され、休日に基づいた（または恒久的な）チームのスペシャリストの交代がより困難になり、チームメンバーに追加のトレーニングが必要になります。

私の目には、導入を歓迎する戦略は、純粋に機能的な側面とは別に、このような問題を解決する必要があります。予想されるゲインは、上記で説明したような余分なトラブルやデメリットに見合うものですか？これを証明できれば、受け入れ率ははるかに高くなる可能性があります。チームメンバーの資格へのこれらの素晴らしい投資を指摘することも役立ちます。

端から始めましょう。ビルドスクリプト、Mavenプラグイン、レポート実行などの非プロダクションコードで言語を誇示します。ユーティリティとシンプルさを確認したら、小規模プロジェクトなどに対応する傾向があります。