問題タブ [backwards-compatibility]

ここまで答えが見つからないことに驚きました。何か基本的なことが欠けている場合は、それを知っていただければ幸いです。

Java 6 (1.4 から) にアップグレードされた大規模なレガシー コード ベースがあります。コードには多数の JUnit 3 テストが存在し、Eclipse の JUnit 4 デフォルト ランナーで正常に実行されるテスト スイートに編成されています。

現在、純粋な JUnit 4 テスト (注釈、TestCase なしなど) である新しいテストを追加しています。古い JUnit 3 テスト スイートと新しい JUnit 4 テストを一緒に実行するにはどうすればよいでしょうか?

私はオブジェクトデータベース（db4o）を使用してアプリケーションを作成しています。アジャイルな方法で、小さな最小限の実装から開始し、そこから機能を繰り返し追加しながら、ソフトウェアの新しいバージョンをリリースします。

私が持っている主な質問は、モデルクラスの新しい実装が開発されたときに、データベースの下位互換性を維持して、ユーザーが第10版のソフトウェアで第1版の保存データを使用できるようにする方法です。

特にオブジェクトデータベースを使用して、これを行うためのいくつかの標準的な方法はありますか？

そのため、私はWebサービスに少し慣れていません。最近、クライアントに返されるデータ型に要素を追加するという状況が発生しました。クライアントは、これが予期していなかった新しい要素を窒息させたため、実装が壊れたと不満を漏らしました。（私たちはAxis2を介してサービスを提供しています）。

私には、これはクライアントが適切に処理できるはずの無害な変更のように思えます（オプションの情報を追加することが完全に受け入れられるいくつかの非Webサービスフレームワークで作業しました）。クライアントに問題を引き起こす可能性のあるいくつかのフィールドを削除または名前変更したかどうかは理解できました。

基本的に、wsdlがインターフェースのように機能することを期待します。基本的にそのインターフェイスをサブタイプ化する変更を行う場合、クライアントは無関係な要素を喜んで無視することを期待します。これはWebサービスの単なる短所なのか、それとも古いクライアントが自由に更新できるように新しいクライアントが追加のデータを取得できるようにサービスに受動的な変更を加えるための正しい方法がありますか？

私が割り当てられたこの現在のプロジェクトでは、次のバージョン 3.1 レベルを使用しています。

Ent Lib の機能についてもっと知ろうとすると、さまざまなバージョン (3.1、4.0、および 5.0 だと思います) に関する記事やドキュメントがたくさん出てきます。

一般に、新しいバージョンは、以前のリリースの Ent Lib 用に作成されたアプリケーション コードで動作しますか? 継承したこのアプリのすべてのソース コードを調査したわけではありませんが、データ アクセス アプリケーション ブロックの「基本」のみが使用されていると思います。典型的なコードは次のとおりです。

率直に言って、これは通常の ADO.Net を超えるものを提供しているようには見えませんが、新しいバージョンでは物事がより単純になっている可能性があります (Unity について非常に良いことを聞いたことがあります)。

背景:
私は、急速に変化する API と急速に変化するデータ モデルに依存するツールに取り組んでいます。

データ モデルと API の変更はよくあることです。ここでの問題は、コードが現在および過去のすべてのバージョンで引き続き動作する必要があることです (つまり、100% のバックワード互換性)。これは、すべてが引き続き内部で使用されるためです。

また、欠落している機能や不明な機能などが発生した場合は、正常に機能を低下させる必要があります。

ツールは、WinForms を使用して C# で記述され、カスタム ハードウェアをテストするためのものです。

私の目標は、機能を追加するためのクラスを作成するだけで済み、データ モデルの変更が発生したときに、API バージョンに基づいてファクトリによって作成されるデータ モデル クラスの新しいセットを作成するだけで済むようにすることです。

私にとっての課題は、将来の機能が特定のデータ モデルに依存する可能性があることです。これは、(最終的なコンボに到達するまで) 混合および一致する可能性があります。これをどのように優雅に処理しますか？

もちろん、製品が出荷されたら、ツールを再利用して新しい製品用のコードを追加したいと考えています。ここに着手する前は、すべての製品サイクルはすべてのツールを (ゼロから) 書き直すことを意味していました。

質問:
API/データ モデルの複数のバージョンとの互換性を維持するために、どのような設計手法とパターンを提案したり、成功したりしますか?

どのような落とし穴に注意する必要がありますか?

バイナリの下位互換性を壊すことはそれほど難しくありません-DSO/共有ライブラリとC++インターフェイスの互換性。そうは言っても、DSOの以前の状態のものと現在の状態のもの（そしておそらくDSOも）の2つの異なるヘッダーファイルのセットが与えられた場合、そのようなABIブレークを検出するのに役立つ静的分析ツールはありますか？無料と商用の両方の製品提案を歓迎します。

インライン関数やDSOインターフェースのデフォルトの関数パラメーターなど、悪い習慣についても警告できるのであれば、それは素晴らしいことです。

コードを比較することによって、コンパイルする前にそれを行うことはできますか? すでにこれを行っているツールはありますか?

ロックのエスカレーションに関連すると思われる問題を調査し、READ_COMMITTED_SNAPSHOT が解決策になると考えていたときに、それが既に有効になっているかどうかを確認しました。驚いたことに、データベースの互換性レベルは 80 でした (SQL Server 2000、私はここに来たばかりで、誰もその理由を知らないようです!)。

しかし、READ_COMMITTED_SNAPSHOT は 2005 年の新機能です。有効にされていても、2000 互換モードで実行している場合に影響はありますか?

アプリに 3.0 機能 (メディア ピッカー) を追加するように依頼されました。

ただし、そのアプリは 2.2.1 デバイスで引き続き実行する必要があります。(機能を無効にした場合)

3.0 機能を含めるために、コンパイラ エラーを発生させずに 2.2.1 で実行されるように、これをコンパイルするにはどうすればよいですか?

MailComposer の例の指示に従って、ターゲット設定を 2.2.1 に、ベース SDK を 3.1.2 に設定しました。

私は弱いリンクを見てきましたが、それは明らかにリンカーステップのためだけであり、コンパイラエラーについては何もしません.

3.1.2 SDK に対してビルドされているにもかかわらず、2.2.1 デバイスでアプリを実行しようとしています。

下の表に私の結果を示します

3 行目は、SDK 間で互換性のないコードがないことを証明しています。問題の根源を突き止めるために、弱いリンクにする必要があるすべてのものを取り出しました。

割り込みは、プログラムの開始後すぐに発生しますが、すぐには発生しません。そして、それが起こるポイントは、3.0 の機能とはまったく関係のないコードにあります。

停止している行は、4 つの浮動小数点 (ab)/(c/d) を含む単純な数学演算であり、それらのいずれにも問題はないようです。(これは C++ です)

これらの状況で他に何が割り込み信号を引き起こす可能性がありますか?

アップデート：

中断している正確なポイントは、u64 をフロートにキャストしているようです。