backwards-compatibility - 下位互換性はどのくらい重要ですか?

Question

開発ツールのアップグレードを検討している場合、後方互換性はどの程度重要ですか? ソースコードに大幅な変更が必要になった場合でも、Visual Studio 2010 を購入しますか? 新機能の後方互換性をトレードするという点で、転換点はどこですか?

score 13 · Accepted Answer

開発者の観点から質問されましたが、開発するソフトウェアに関しては、より興味深い質問になると思います。というわけで、代わりにその質問に答えます。:)

下位互換性がある (さらに重要なことに将来互換性がある) ハードウェアとソフトウェアは、特に Windows などのプラットフォームを購入またはアップグレードする場合に、ユーザーに安心感を与えます。少なくとも、Windows は下位互換性に細心の注意を払っていることで知られています。10 年以上前に作成されたプログラムを Windows Vista で実行するには、「適切に作成された」 (つまり、文書化されていない API を使用しない) 場合に限り、軽微な問題が発生するだけです。

一方で、新しい機能を導入したり、プラットフォームに革命を起こそうとしたりする場合、下位互換性に厳密に注意を払うと手を縛られる可能性があります。Apple は自社の OS が死につつあることを知っており、最も大胆な動きの 1 つである NeXT を買収し、NeXTSTEP を新しい MacOS にすることを決定しました。移行で人々を売り込んだ重要なものの 1 つは、下位互換性のあるレイヤー Classic でした。再び Apple が Intel チップへの切り替えを決定したとき、Rosetta と呼ばれる Intel 上で PowerPC アプリを実行するためのメカニズムと Universal Binaries により、人々はアプリケーションの損失を恐れることなく、PowerPC と Intel の間を自由に行き来することができました。

興味深い点の 1 つは、Intel への移行に伴い Classic 環境が消滅したことですが、Mac OS 9 からの移行に 5 年を要していたため、誰も気にしていませんでした。新しいシステムに移行し、ユーザーに十分な時間を与える簡単な方法です。

score 3 · Accepted Answer

開発ツールで、以前のコードとの完全な下位互換性が提供されない場合、私はそれを購入しませんし、誰も購入しないと思います。率直に言って、意味がありません。ソースコードを実行可能なコードにビルドするコンパイラが既にある場合は、それを使用します。ツールメーカーにとって明らかに標準ではないものに準拠するようにコードを変更するのはなぜですか? あるバージョンから別のバージョンへのソースコードの変更を強制する場合、なぜわざわざ次のバージョンに互換性を持たせるのでしょうか?

ソースとの 100% の下位互換性が必要です。これが完全な要件ではない唯一の状況は、互換性のないビットが拡張機能である場合です。つまり、Eclipse プラグインなど、ツール固有の API の変更です。それでも、互換性が欲しいのですが、完全には期待できないことがわかりました。しかし、基本アプリケーション/ツール開発用の API を提供していて、互換性を維持するのが面倒な場合。そうですね、あなたは明らかに自分のツールに真剣ではありません。私はそれらに大金を払いません。

score 2 · Accepted Answer

ホームプロジェクトの場合、下位互換性は実際には重要ではありません。オフィス/企業にとって、これは絶対に重要です。

score 1 · Accepted Answer

サポートする必要がある環境と、互換性がある場合とない場合があるサードパーティツールが使用されているかによって異なります。

たとえば、私が働いている場所では、SQL Server BI ツールが VS2008 と互換性がなかったため、BI グループを除いて全員を VS2005 から VS2008 にアップグレードしました。それらが更新されると、VS2008 にアップグレードされました。

VS を具体的に見る場合、VS2008 は .NET 2.0、.NET 3.0、および .NET 3.5 をターゲットにできることに注意してください。秘訣は、実際に .NET 2.0 SP1 と .NET 3.0 SP1 をターゲットにしていることを理解することです。そのため、IDE をアップグレードするためにコードを変更する必要はありません。

score 1 · Accepted Answer

ソフトウェアとハードウェアの分野では多くの変更が行われているため、ソリューションを設計する際に、新しい変更やより優れたツールに対してオープンになることをお勧めします。たとえば、90 年代にはマルチコアプロセッサとハイエンドグラフィックスカードやネットワークカードはありませんでした。そのため、コンパイラとツールの最適化の目標は当然異なっていました。しかし同時に、Visual Studio のようなツールは、古いフレームワークやアプリに対応するために最善を尽くしています。

より良い世界を望むのであれば、この業界が超成熟するまで、絶え間ない変化に対してオープンであるべきだと思います。（しかし、私たちの人生では起こらないかもしれません:)）

score 1 · Accepted Answer

他の多くのユーザーが独自の製品を構築するために常に使用するプラットフォームを開発しており、アプリケーションを長期間開発する予定がある場合、それは重要です。下位互換性を重視している PHP、Python、Eclipse などのオープンソースプロジェクトをご覧ください。n 層アーキテクチャで使用されるサービスやその他のオープン API を開発する場合にも重要です。サービスを変更すると、エンタープライズ内のすべてのアプリケーションが常に壊れる可能性があります。

現在、シュリンクラップアプリケーションまたはビジネスアプリケーションを構築している場合は、各バージョンがその前身から分離されているため、それほど重要ではありません。

score 0 · Accepted Answer

「重要な変更」を定義します。変更が広範囲であっても、慎重に作成された「検索と置換」で行うことができれば、私はそれを選びます。

しかし、それは私がすることです。私が働いたことのある会社は、既存のコードを変更することに躊躇します。

backwards-compatibility - 下位互換性はどのくらい重要ですか?

7 に答える 7

Related

Reference