私の経験からすると、後方/前方互換性への取り組みは、ソフトウェア エンジニアリング業界の金色の檻です。これは特に、ドキュメント ファイル形式とプログラミング言語/API の場合に当てはまります。顧客やパートナーは、既存のデータやコードが破損することを嫌います。ただし、互換性を壊すことがなければ、長期的には革新する能力が大幅に制限される可能性があります。
古い機能を段階的に廃止する以外に、この問題の解決策はありますか? Windows 7 の XP Mode のような仮想化は、1 つの刺激的な可能性のようです。他にもありますか？
また、可能な限り将来を見据えた新しいシステムを設計したいと考えている私たちにとって、業界で犯した過去の過ちからどのような教訓を学べるでしょうか?
パブリック API を書き直すのではなく、拡張することでイノベーションを起こします。バックエンド機能への一貫したジェネリック パブリック インターフェイスを用意します。パブリック API モジュールに期待される結果を提供する限り、いつでもプライベート モジュールを書き換えることができます。
バックエンドで改善を行い、可能な限り API の一貫性を保ちます。新しいモジュールを作成し、API の公開部分を拡張する場合は、それらを明確に文書化します。古い方法に追加されたものを実行するための新しいより良い方法を提供すると、古い方法の廃止が自然に行われます。
ドキュメント形式については、常にバージョン番号を含め、既存のすべてのバージョンをサポートする方法があることを確認してください。API と同様に、書き直すのではなく、拡張して新しい機能を追加します。
ソフトウェアの全体的なアーキテクチャに根本的な変更を加えたい場合は、新しいバージョンに古いバージョンをモジュールとして含めてください。これにより、サイズが大きくなりますが、古いデータとプログラムのサポートが向上します。
ファイル形式の基礎として XML を使用し、仕様の DTD に追加するだけで、削除しないでください。このようにして、ファイルは以前のバージョンと下位互換性があるはずです。これはプラスです。
良い例を次に示します。SLF4J ブリッジを使用して、Java で 1 つのロギング モジュールから別のロギング モジュールに簡単に移行できるようにします。