この質問は特定の技術に関するものではなく、一般的な開発者の質問です。
私たちは皆、物事が変化することを経験から知っています。フレームワークは進化し、新しい機能が追加され、何かが削除されます。
たとえば、「ABC」フレームワークのバージョン 1.0 を使用する製品は、バージョン 2.0 が登場したときにどのように適応するでしょうか (ABC は .NET、Java、Cocoa、または任意のものでかまいません)。
解決策の 1 つは、フレームワークに後方互換性を持たせることです。そのため、1.0 用に記述されたコードは、フレームワークのバージョン 2.0 でも機能します。
別の方法として、フレームワークのバージョン 1.0 のみを選択的にターゲットにすることも考えられますが、これにより、多くの優れた新機能が使用されないままになる可能性があります (多くの .NET 2.0 アプリはこれを行っているようです)。
アプリケーションを壊さずにテクノロジーを最新の状態に保つためのベスト プラクティスとして、開発者として何をすべきかについて何か考えはありますか?
変化を予測し、投資します。
多くの企業は、変化は悪いことだと考えているようです。そうでなければ作業プロセスが複雑になります。しかし、開発者として、私たちは物事を別の方法で見る傾向があります。
変更、特に新しいバージョンは、セキュリティの更新、パフォーマンスの強化、機能など、多くの良いことをもたらす可能性があります。そして多くの場合、変化は避けられません。では、それを驚きではなく、状況の現実として見てみませんか?
いくつかの新しい技術がうまくいかず、すぐに出荷する必要がある場合に備えて、ベンダー固有ではない形式でデータをバックアップしておくなどのことができます。
また、リソースがあれば、何かの古いバージョンと新しいバージョンを同時に実行し続けることができます。理想的には、誰かが評価してサインオフするまで、本番システムで最新かつ最高のソフトウェアを実行したくないでしょう。単体テストや本番システムのベータ/開発クローンなどは、このプロセスに役立ちます。
変化は恐れるのではなく受け入れる必要があります。開発者、利害関係者、およびビジネス関係者は、新しいテクノロジとフレームワークに遅れないようにしておく必要があります。常に変化に対処する態勢を整えてください。ソビエト ロシアでは、API があなたについていきます!
ああ、考えられる答えは....
私の考えは、（確かに）ユニークではありませんが、ほぼ次のようになります。
それほど簡単ではありませんが、最も単純な答えが最良の答えである可能性が高いと思います。前に進むしかない…
私が見る唯一の「解決策」は、あなたが提案するものです。新しいフレームワークを維持するか、アップグレードすることです。一般的に、API がメジャー アップデートを受け取り、ソフトウェアが重要な場合は、アップグレードのメリットを評価するのがおそらく最善であり、それらのメリットがアップグレードに必要な時間を上回る場合は、アップグレードするのが最善の方法だと思います。
ビジネスに適した保守的、危険、またはその中間のアプローチを選択し、最後までやり遂げてください。
たとえば、あなたの会社がイノベーションを重視している場合、最新バージョンのフレームワークを使用できる必要があります。または、少なくとも自由に調査できる必要があります。そのような環境に興味があり、快適に過ごせる人材を雇う必要があります。開発者の中には、これに非常に興奮している開発者もいれば、それほど熱心ではない開発者もいます。アップグレードを安全にするために何らかの構造を導入します (ブランチと静的アーキテクチャ)。顧客は、このような最先端の会社と一緒にいることで得られるメリットを理解する必要があります。これを伝えていない場合、顧客にとって価値のあるものではない可能性があります。システムアップデートの。
または、保守的なアプローチを選択します。堅固で使い古されたテクノロジーを選び、マイナー リリースを除いて、それを更新する予定はありません。つまり、特定のバージョンをターゲットにします。この種の環境に感謝する人を雇ってください。
または、道の真ん中でもっと何かを選んでください。
これらのアプローチはそれぞれ、さまざまな時期に適しています。私は、さまざまなプロジェクトで両極端を行ってきました。