いつ、どのように、そしてなぜ（Java）フレームワークをアップグレードする必要があるのですか？
概要としての短い要約：
私たちは小さなJava Web開発チームであり、JSF、Hibernate、Seamなどのさまざまなフレームワークとライブラリを使用してアプリケーションを作成し、すべて一緒にJBoss ASにデプロイします。
最初はアプリがまとめられ、いくつかの機能が追加されて潜在顧客に表示するショーケースが形成されました。研磨が行われ、アプリがリリースされ、承認されて機能し、時間が経つにつれ、追加機能が追加され、バグが修正され、新しいバグが発生しています。
高いバス要因とスタートアップレースのために、開発は手に負えなくなりました。システムのコアアーキテクチャを完全に理解していなかったため、ますます多くの機能が追加されました。それはまだ機能していますが、システムが元の場所から別の場所に進化したため、常に落とし穴があり、最初はさまざまなショートカットが開発をスピードアップするために行われました-回避策が使用され、プロジェクトに新しい開発者を紹介するのはかなり難しい。
今、私は物事の整理と整理の進行中です-バグ追跡システムのインストール、テスト/品質の文化の構築、自動テストの実行方法の検討、コードレビュー（私たちが欠けていたすべての豪華な専門的なもの）はじめに）クラスの階層や関数を整理するような一般的なリファクタリングを行い、ものを使いやすくします。これですべてが少し良くなりますが、やるべきことはまだたくさんあります。私は最初にシステムを構築した人（以前の主任プログラマーは去った）ではなく、経験もありません（現在2.5年間開発中ですが、これは今のところ私の唯一の「オープンワールド」の経験です）。行う。
これが私の問題です：
リファクタリングは常に良いことであり、私は常にそれを簡単にするためにそれを行っていますが、基本的なアーキテクチャ（つまり、システムが依存するライブラリ、アプリケーションサーバー、データベースなど）をアップグレードする必要があるのはいつ、どのように、そしてなぜなのかと私を困惑させています。
例：
現在、JBoss 4.2.2を使用しています。JBoss7.1のどこかをすでに読んでいます。これをどのように評価できますか？
大きなブロッカーと思われるSeam 2.2を使用します（JBossの上位バージョンでは機能せず、JSF2をサポートしていません）。さらに、Seamの代わりにJEE機能を使用するように指示するソースが表示されます。
基本的に、私は上記の例で述べたものだけでなく、この問題の一般的なアプローチに興味があります-別のシステムで別のライブラリの別のときにこの問題に遭遇する可能性があります（または他の誰かが同様の問題に直面する可能性があります） 。
だから、ポイントは何ですか？最新の状態で最先端のライブラリのみを使用する必要がありますか、それとも私が持っているものを使い続けるべきですか？私が使用しているテクノロジーが文字通り死んだ馬であり、飛び降りるのをどのように認識しますか？このようなテクノロジーのアップグレードはどのくらいの頻度で表示されますか？
そして、一般的な「アップグレード方法」の横にある別の質問。私のソフトウェアが「専門家によって作成された」ものと呼ばれる可能性があることをどのように認識しますか？一般的なプログラマーの感覚以外に、よくできたソフトウェアのJoelテストはありますか？
簡単に言えば、切り替えない努力が切り替えの努力を超える場合、またはすぐにそうなることが予測できる場合に切り替えます。これは、経験を必要とする非常に主観的な評価ですが、極端なケースを見るのは比較的簡単です。
たとえば、切り替えに1か月かかると予測しているが、切り替えがない場合は、アップグレードバージョンでのみ利用可能なモジュールを使用できないため、1か月から実装するのに2か月かかることになります。選択は簡単です。
別の例として、ベンダーでサポートされなくなったソフトウェアのセキュリティ脆弱性を修正するためにすべての時間を費やしている場合は、切り替えるのがよいでしょう。
誰かが「新しいバージョンを使うとこれははるかに良く/簡単になるだろう」と言う場所でミーティングをしたことがなければ、おそらく切り替える必要はありません。
中間のケースは認識が難しくなりますが、通常は古い圧力に固執することがますます制限されるように感じられるプレッシャーを構築するように感じます。
十分に完了したソフトウェアテストに関しては、バグトラッカーが適切な経験則を提供します。重大な欠陥がゼロであり、重大でない欠陥のリストが妥当なレベルにあり、着実に縮小している場合、それを「完了」と呼ぶことができます。新しい機能を追加したり、バグを修正したりするまでの所要時間によって、ソフトウェアアーキテクチャの品質を把握できます。 「これはプロフェッショナルです」と言っているカットオフポイントはありませんが、低いほど良いです。
基盤となるインフラストラクチャをアップグレードする理由はいくつかありますが、それぞれをできる限り経験的に評価する必要があります。たとえば、次の理由でアップグレードする可能性があります。
- ベンダーは、使用しているバージョンをサポートしていません
- 重大なバグまたはセキュリティ修正があります
- 活用したい新機能があります
- 速度が上がります
- アップグレードで直接設備投資コストが削減されます（安価なサポートライセンスなど）
これらの理由は、アップグレードのコストと比較して検討する必要があり、そのほとんどはテストに費やされます。これは [〜＃〜] tdd [〜＃〜] / [〜＃〜] bdd [〜＃〜] が実際に前面に出てくる場所です。特に、良いCI設定。
それはあなたができることを意味します「恐れることなく迅速にリファクタリング」
適切な包括的なテストスイートがない場合は、手動でテストしていることになります。これは時間がかかり、エラーが発生しやすく、アップグレードのコストが高くなります。
あなたが挙げたテクノロジーは広く使用されており、それらのドキュメントや、それらに精通している人々のためのドキュメントを簡単に見つけることができるので、それらを変更する本当の理由はないと思います。一方で、フレームワークを最新のリリースバージョンにアップグレードすることをお勧めします。いずれにせよ、遅かれ早かれそれを行う必要があると思います（新しい機能と新しいライブラリとの互換性がない場合は、新しいリリースで修正されたバグを修正する必要があります）。早い段階で行うと、このタスクはそれほど面倒ではなくなります。