オフィスの人員配置にいくつかの変更が加えられたため、C#の専門知識のレベルは急激に低下し、Java開発者が増えています。上層部がC#で記述された既存の.NETプロジェクトをJavaの世界に移動することを検討しているところまで来ています。
完全にゼロから始めるという明らかな問題は別として、この会社が.NET C#からJavaへのプロジェクトの開発を成功させるために考えられる方法は何ですか?
オフィスの人員配置にいくつかの変更が加えられたため、C#の専門知識のレベルは急激に低下し、Java開発者が増えています。上層部がC#で記述された既存の.NETプロジェクトをJavaの世界に移動することを検討しているところまで来ています。
完全にゼロから始めるという明らかな問題は別として、この会社が.NET C#からJavaへのプロジェクトの開発を成功させるために考えられる方法は何ですか?
考慮すべき事項は次のとおりです。
変換する場合:
Brian と Eric の意見に付け加えると、私の意見では、Java 開発者が C# を選択するのは簡単なはずです。これらは概念的に非常によく似た言語であり、面倒な移行プロセスを余儀なくされないように、Java 開発者をトレーニングして C# のスキルを習得することをお勧めします。
完全な書き直しはほとんどの場合間違いであるという Joel の見解に同意します。他の投稿者の言うとおりです。C# と Java は十分に似ているため、有能な Java 開発者であれば、数週間または数か月で C# を扱えるようになるはずです。彼らが専門家になるというわけではありません。それには時間がかかりますが、プロセスをガイドできる C# 開発者がいれば問題ありません。
アプリケーションの詳細 (サイズ、アプリケーションの種類、業界など) を知らずに、このような移行が良いアイデアか悪いアイデアかについてコメントするのは困難です。
私の謙虚な意見では、C# は現在 Java よりもはるかに現代的な言語であり、Java 開発者として 10 年以上 (1.0.2 から/1.1日)。
Javaが悪いと言っているわけではありません。そうではありません。Sun には確かに雲がかかっており、近年、プラットフォームを前進させようとしない、または推進できないことを示しています。
.NETプロジェクトのJavaへの変換を完了する前に、変換プロジェクトに参加していたすべてのJava開発者はC#を学習しているはずです。これで、Javaに変換する必要がなくなります(変換で生成されたすべてのJavaコードを破棄できます)。これで、JavaとC#の両方を実行できる開発チームができました。問題が解決しました。:D
関連する言語に関係なく、この会社の経営陣は非常識に聞こえます。些細なアプリケーション以外の場合、適切な言語のスキルを持つ人を 1 人雇うのではなく、コード ベース全体をゼロから書き直すことは経済的に合理的でしょうか? これはよく知られた問題を抱えたビジネスですか?
既存のコードの開発期間はどれくらいですか? 始めたばっかりなら、これは理解できた。それがリリースされ、アクティブなユーザーがいる場合、それを捨てることは決して意味がありません. 適切なスキルを持つ新興企業に C# コードを寄贈した場合、彼らがあなたよりもどれだけ有利なスタートを切れるかを考えてみてください。
すでに分離されているコンポーネントがある場合、またはサービス指向アーキテクチャを使用しているコンポーネントがある場合は、一度に 1 つのコンポーネントを移行し (個々のコンポーネントが書き換えられます)、同じコンポーネントを使用してコンポーネントが互いに通信できるようにすることが考えられます。相互運用可能なネットワーク プロトコル。おそらく、話しているアプリの種類によって異なります。
大量のテストがあることを確認してください。そのような移行は、最も予想外の場所に影響を与えるからです。
これを行うことにした場合は、シナリオをウォーターフォール変換から段階的な移行に変更するため、基本的に同じアプリケーションに C# と Java を混在させることができるハイブリッド アプローチの恩恵を受ける可能性が高くなります。ここで私は2つの可能性を知っています:
1) .NET ランタイムで Java コードを実行できるikvm ( http://www.ikvm.net/ )。これにより、Java コードから C# コードを呼び出すことができ、その逆も可能です。その後、C# コードの開発を凍結し、機能するアプリケーションを維持しながら、改訂された機能を Java 部分にゆっくりと追加できます。
2) .NET バイトコードを Java バイトコードにコンパイルできるMainsoft ( http://dev.mainsoft.com/Default.aspx?tabid=130 )。無料のエントリーバージョンがあります。私はこの製品の経験はありませんが、Java しか利用できない私たちのプラットフォームで大々的に広告を出しています。
経営陣に証明するには、常に ROI と数値の観点から話す必要があります。これらのアプリケーションを移動すると、膨大な時間と QA リソースが必要になること、また他のプロジェクトや新しい開発が重要視されているために優先順位が下げられた場合、後回しにされてしまう可能性があることを示してください。
タイムライン、ROI、関連する作業、関連するお金などを彼らに示したとき、私は成功しました.
つまり、実際のポイントに来て、Java 開発者は、Microsoft の技術に対する基本的な精神的ブロックがない限り、C# をサポートできると思います。
C# から Java へのコード変換を支援する Net2Java をご覧ください。完璧であるとは思えませんが、互換性のないフレームワーク呼び出しや言語機能のねじれを解決するために、タスクから多くの単調な作業を取り除く 1 つの方法です。
それが完了したら、タスクは他の大規模な移行プロジェクトと同様に、テスト、テスト、およびテストを繰り返します。ユニットテスト、システム統合テスト、そしてエンドユーザーテスト。単体テストとは別に、元のアプリケーションで使用したこれらのテストを既に配置しておく必要があります。それらは引き続き関連します。
本番環境に .Net または Java アプリケーションが増えていますか。.Net サーバーとアプリケーションにすでにかなりの投資をしている場合は、Java 開発者の中に .Net に移行するボランティアを募ってみませんか? 言語と構文は非常に似ているため、難しいのはフレームワークを学習することです。UI 開発にすべての時間を費やさない限り、フレームワークを学習することはそれほど難しくありません。
私たちのオフィスには、必要に応じて Java と .Net の間を行き来する非常に優れた開発者が多数います。
私は Java の専門家ではありませんが、C# のファンでありながら Java コードを扱った経験から、考えられる頭痛の種のいくつかを以下に示します。
個人的には、ゼロから書くことは悪い考えではないと思います。すでに動作するアーキテクチャがあるためです。
移住を拒否するという考えを誰も提案しなかったことに少し驚いています。
私は、C# 開発者が Java への切り替えを強いられる (またはその逆) とは思いません (銃で脅された場合はそうなるかもしれません)。少なくとも 1 つのテクノロジー スタックを習得するには、多くの時間、運動、情熱が必要です。新しいテクノロジーを一夜にして始めて、同じ品質を提供できると期待することはできません。
移行を開始するように言われるまで、個人的には気にしません。その時点で、私はマネージャーに、私は .NET の専門家であり、別のテクノロジに切り替えるつもりはないと伝えました。
技術的な側面に関して言えば、異なるのは言語の構文ではなく、ライブラリとその機能です。もちろん、.NET 3.5 のすべての最新機能が広範囲に使用されている場合、言語の違いが実際の課題となります。
これは確かに面白い方法です。アプリケーションを .NET から Java に移行することに決めただけです。面倒なことを知らない人がいる...
jni4net - opensource bridgeを使用できますか? または私が知っている他のオプションのリスト。