いつ、どのように、そしてなぜ1つの（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か月かかることになります。選択は簡単です。

別の例として、ベンダーでサポートされなくなったソフトウェアのセキュリティ脆弱性を修正するためにすべての時間を費やしている場合は、切り替えるのがよいでしょう。

誰かが「新しいバージョンを使うとこれははるかに良く/簡単になるだろう」と言っている会議がない場合は、おそらく切り替える必要はありません。

中間のケースは認識が難しくなりますが、通常は古い圧力に固執することがますます制限されるように感じられるプレッシャーを構築するように感じます。

十分に行われたソフトウェアテストに関する限り、バグトラッカーはその大まかな経験則を提供します。重大な欠陥がゼロであり、重大でない欠陥のリストが妥当なレベルにあり、着実に縮小している場合、それを「完了」と呼ぶことができます。新しい機能を追加したり、バグを修正したりするまでの所要時間によって、ソフトウェアアーキテクチャの品質を把握できます。「これはプロフェッショナルです」と言っているカットオフポイントはありませんが、低いほど良いです。

基盤となるインフラストラクチャをアップグレードする理由はいくつかありますが、それぞれをできる限り経験的に評価する必要があります。たとえば、次の理由でアップグレードする可能性があります。

1. ベンダーは、使用しているバージョンをサポートしていません
2. 重大なバグまたはセキュリティ修正があります
3. 活用したい新機能があります
4. 速度が上がります
5. アップグレードで直接設備投資コストが削減されます（安価なサポートライセンスなど）

これらの理由は、アップグレードのコストと比較して検討する必要があり、そのほとんどはテストに費やされます。これは、特に適切なCIセットアップと組み合わせると、TDD / BDDが実際に前面に出てくる場所です。

「恐れることなく迅速にリファクタリング」できることを意味します

適切な包括的なテストスイートがない場合は、手動でテストしていることになります。これは時間がかかり、エラーが発生しやすく、アップグレードのコストが高くなります。

あなたが挙げたテクノロジーは広く使用されており、それらやそれらに精通している人々のためのドキュメントを見つけるのは簡単なので、それらを変更する本当の理由はないと思います。一方、フレームワークを最新のリリースバージョンにアップグレードすることをお勧めします。いずれにせよ、遅かれ早かれそれを行う必要があると思います（新しい機能と新しいライブラリとの互換性がない場合は、新しいリリースで修正されたバグに対応する必要があります）。