プログラミングの効率を向上させるために、従来の Java Web アプリケーション (J2EE) をスクリプト言語 (任意のスクリプト言語) に移行したいと考えています。
これを行う最も簡単な方法は何ですか? ビジネスロジックの大部分を変換できる自動化ツールはありますか?
プログラミングの効率を向上させるために、従来の Java Web アプリケーション (J2EE) をスクリプト言語 (任意のスクリプト言語) に移行したいと考えています。
これを行う最も簡単な方法は何ですか? ビジネスロジックの大部分を変換できる自動化ツールはありますか?
これがあなたがしなければならないことです。
まず、走る前に歩けることを確認してください。メイン プロジェクトに関連する単純なものを構築します。
最終プロジェクトの一部を構築しないでください。最終プロジェクトに「進化」することを期待してください。これは決してうまくいきません。なんで?あなたはばかげた間違いをするでしょう。しかし、その間違いを最終的なプロジェクトに発展させることになっているため、それらを削除したり作り直したりすることはできません。
次に、aa フレームワークを選択します。何?2番?はい。2番。いくつかのスクリプト言語やフレームワークを使って実際に何かをするまでは、自分が何をしているのかについて実際に役立つ概念はありません。何かを構築すると、情報に基づいた意見が得られます。
「待って」とあなたは言います。「ステップ 1 を実行するには、フレームワークを選択する必要がありました。」真実。ただし、ステップ 1 には、取り消すことができる決定が含まれています。ステップ 1 で間違ったフレームワークを選択しても、長期的な悪影響はありません。勉強ばかりでした。
3 番目に、戦略的フレームワークとある程度の経験を基に、既存のサイトを分割して、新しいフレームワークで構築できるようにします。最も重要なものから最も重要でないものの優先順位を付けます。
変換全体を 1 つの大規模なプロジェクトとして計画しないでください。それは決して機能しません。それは大きな仕事を必要以上に複雑にします。
サンプル フレームワークとして Django を使用します。テンプレート、ビュー関数、モデル定義、URL マッピング、その他の詳細が含まれます。
ビルドごとに、次の手順を実行します。
既存のモデルを Django モデルに変換します。これは、レガシー SQL には適合しません。モデルを再考し、古い間違いを修正し、常に修正したいと思っていた古いバグを修正する必要があります。
単体テストを書きます。
古いデータをエクスポートして新しいモデルにインポートするための変換ユーティリティを構築します。
Django 管理ページを作成して、新しいデータに触れて感じてください。
代表的なページを選び、適切なテンプレートに作り直します。一部のレガシー JSP ページを利用する場合があります。ただし、これで時間を無駄にしないでください。HTML を使用して Django テンプレートを作成します。
URL と表示機能を計画します。これらのビュー関数は、レガシー アクション クラスを利用する場合があります。「変換」しないでください。最初から書き直します。新しい言語とフレームワークを使用してください。
保存する価値があるのは、データと運用コンセプトだけです。コードを保存または変換しようとしないでください。誤解を招きます。単体テストを JUnit から Python の単体テストに変換できます。
私は数ヶ月前にこのアドバイスをしました。処理中にコーチングとレビューを行う必要がありました。改訂されたサイトが稼働しています。古い技術からの変換はありません。彼らは提案された書き直しを最初から行いました。開発者は幸せです。サイトはうまく機能します。
すでに大量のビジネス ロジックを Java で実装している場合は、2 つの可能性が考えられます。
1 つ目は、 Groovy / GrailsまたはJRuby and Railsなど、JVM 内で実行され、Web フレームワークを備えた高水準言語を使用することです。これにより、サイト全体を再構築することなく、Java で実装したすべてのビジネス ロジックを直接活用できます。Web 開発に関してフレームワークの改善された生産性を活用しながら、既存のビジネス ロジックを活用できるはずです。
別の方法として、ビジネス ロジック層を標準の RPC メカニズム (REST、SOAP、XML-RPC、またはその他の単純な XML (YAML または JSON) over HTTP プロトコル ( DWRも参照)) を介して利用可能な一連のサービスに変換する方法があります。フロントエンドは、ビジネス ロジックに対してこれらの RPC 呼び出しを行うことができます。
JVM で高級言語を使用する最初のアプローチは、おそらく 2 番目のアプローチよりも再アーキテクチャーが少なくなります。
目標が Java からの完全な移行である場合、これらのアプローチのいずれかを使用すると、より小さなステップでそれを行うことができます。この種のハイブリッドは、非推奨の販売全体よりも優れていることがわかるかもしれません。JVM には多くのライブラリがあり、うまく統合されます。他の多くのシステムに。
自動化されたツールを使用して Web アプリケーションを「移植」すると、将来のプログラミング効率が最小限に抑えられることはほぼ確実です。改善されるわけではありません。
優れたスクリプト言語は、その言語の優れたコーディング プラクティスを理解している優れたプログラマーによって使用されると、プログラミングの効率を高めることができます。自動化されたツールは通常、洗練されたコードや適切に作成されたコードを出力するようには設計されておらず、機能するコードのみを出力するように設計されています。
プログラミングの効率が向上するのは、Web アプリを再実装する努力をした後だけです。再実装には時間がかかるため、全体的な改善につながる場合もあれば、そうでない場合もあります。
ここに示されている推奨事項の多くは、あなた (そしてあなただけ) がアプリケーションの完全な書き直しを行っていることを前提としています。これはおそらくそうではなく、答えがかなり変わります
すでに J2EE を使用している場合、正解は Grails です。それは単純です: あなたはおそらくすでに Hibernate と Spring を動かしていて、最小限の苦痛で古いコードと新しいコードの間を行ったり来たりしたいと思うでしょう。これはまさに Groovy の得意分野であり、この点では JRuby よりもさらにスムーズです。
また、すでに J2EE アプリケーションが動き回っている場合は、Java 開発者も動き回っています。その場合、Groovy を学ぶことは文字通り、はしごから落ちるようなものです。匿名の内部クラスを除いて、Groovy は Java の純粋なスーパーセットです。つまり、Java コードを記述し、それを Groovy と呼び、それで作業を完了できます。Groovy の機能に慣れてきたら、それらを Java 風の Groovy コードに統合できます。やがて、非常に Groovy なコードを作成するようになり、その移行に気付くことさえありません。