レガシー互換性のベストプラクティス[終了]

Question

私の経験から、後方/前方互換性へのコミットメントは、金色のケージソフトウェアエンジニアリング産業。これは、ドキュメントファイル形式とプログラミング言語/ APIの場合に特に当てはまります。顧客やパートナーは、既存のデータやコードが壊れたときにそれを嫌います。ただし、互換性を決して損なわない場合、長期的に革新する能力を大幅に制限する可能性があります。

古い機能の段階的な廃止以外に、この問題の解決策はありますか？ Windows 7のXPモードのように、仮想化は1つのエキサイティングな可能性のようです。他にありますか？

また、できるだけ将来性のある新しいシステムを設計したい人にとって、業界で過去に犯した過ちからどのような教訓を学べますか？

Answer 1

パブリックAPIを書き換えるのではなく、拡張することで革新します。バックエンド機能への一貫した汎用パブリックインターフェイスを備えています。公開APIモジュールに期待する結果を提供する限り、いつでもプライベートモジュールを書き換えることができます。

バックエンドで改善を行い、可能な限りAPIの一貫性を保ちます。 APIの公開部分を拡張するときに新しいモジュールを作成し、それらを明確に文書化します。古い方法に追加するものを行うための新しいより良い方法を提供する場合、古い方法の廃止は自然に起こります。

ドキュメント形式の場合は、常にバージョン番号を含め、既存のすべてのバージョンをサポートする方法があることを確認してください。 APIと同様に、書き換えではなく拡張により、新しい機能を追加します。

ソフトウェアのアーキテクチャ全体に根本的な変更を加えたい場合、新しいバージョンに古いバージョンをモジュールとして含めます。これにより、サイズは大きくなりますが、古いデータとプログラムのサポートが向上します。

Answer 2

XMLをファイル形式の基礎として使用し、仕様DTDにのみ追加し、削除しないでください。このようにして、ファイルは以前のバージョンと後方互換性があるはずです。これはプラスです。

Answer 3

良い例： SLF4Jブリッジを使用して、1つのロギングモジュールから簡単に移行できるようにするJavaで別のものに。