廃止されたコードを段階的に廃止するためのベストプラクティスは何ですか?


9

廃止されたメソッドを段階的に廃止する必要があります。私はその[Obsolete]属性を知っています。マイクロソフトには、これを行うための推奨されるベストプラクティスガイドがありますか?

これが私の現在の計画です:

A.開発者がプロ​​ジェクトへの新しい参照を追加する必要があるため、新しいアセンブリを作成したくありません。これを行う必要がある場合、上司や同僚から多くの悲しみを得ることが期待されます。また、複数のアセンブリバージョンを維持しません。最新バージョンのみを使用しています。このプラクティスを変更するには、展開プロセスを変更する必要があります(これは大きな問題です(FinalBuilderの代わりにTFSで物事を行う方法を人々に教え、FinalBuilderをあきらめるようにする必要があります)。

B.古いメソッドを廃止するようにマークします。

C.実装が変更されているため(メソッドシグネチャではない)、オーバーロードを作成するのではなく、メソッドの名前を変更する必要があります。したがって、適切な方法をユーザーに知らせるために、[Obsolete]属性にメッセージを追加する予定です。この部分は私を悩ませています。私が行っている唯一の変更は、接続文字列からメソッドを分離することです。しかし、私は新しいアセンブリを追加しないので、これを回避する方法はありません。

結果:

[Obsolete("Please don't use this anymore because it does not implement IMyDbProvider.  Use XXX instead.")];
        /// <summary>
        /// 
        /// </summary>
        /// <param name="settingName"></param>
        /// <returns></returns>
        public static Dictionary<string, Setting> ReadSettings(string settingName)
        {
            return ReadSettings(settingName, SomeGeneralClass.ConnectionString);
        }

        public Dictionary<string, Setting> ReadSettings2(string settingName)
        {
            return ReadSettings(settingName);// IMyDbProvider.ConnectionString private member added to class.  Probably have to make this an instance method.
        }

回答:


5

Microsoftは[obsolete]属性を使用して、メソッド、プロパティ、またはクラスが非推奨であり、将来のリリースで変更される(またはまったくサポートされなくなる)ことを開発者に通知します。

これにより、少なくとも1つのリリースサイクルが提供され、APIの機能が「廃止される」ことをユーザーに通知し、ソフトウェアの将来のリリースでAPIへの参照を削除します。

元の機能を残す期間は完全にあなた次第です。開発者に古い機能よりも新しい機能を使用するように「強く奨励」したい場合は、1つの追加のリリースサイクルでそれを削除できます。永続的な下位互換性を維持するつもりであれば、永久に残しておくことができます。

Brianが指摘しているように、メソッドのシグネチャではなく、基礎となる実装のみを変更する場合は、これをまったく行う必要がない場合があります。


Microsoftの慣習は、一般に、次のメジャーリリースで廃止されたものを削除することです。対照的に、Javaは廃止されたものを削除することはありません-それはあなた次第です。
Scott C Wilson

アプリケーションレベル(多くのソリューションを備えた1つの巨大なアプリケーション)を超えてアセンブリをバージョン管理することはありません。これを、特定のアセンブリに依存するソリューションの数が定義されていないという事実と組み合わせる。知らないアプリケーションはテストできません。しかし、私が知らないアプリケーションの破損を引き起こす変更を加えた場合...まあそれは私のせいです。これが、メソッドの名前を変更した理由です。だから、これまで読んだことから、これについてより良い方法はありません。
P.Brian.Mackey

4

(メソッドシグネチャではなく)実装が変更されるため、オーバーロードを作成するのではなく、メソッドの名前を変更する必要があります。

わかりません。実装が変更されているが署名が変更されていない場合、なぜこれを行うのですか?「古い」メソッドに新しく改善された実装を使用させます。このAPIを使用する開発者は、まったく同じシグネチャが作成されたメソッドと、既存のメソッド呼び出しで非推奨の警告が表示されたときに目を見張るでしょう。(これがAPIで発生したことがあると思いますか?)

このメソッドの基本となる実装を変更しても機能するかどうか不明な場合は、実装を変更する前と後で、ユニットテストで動作を確認してください。


それは素晴らしい理想です。問題は、テスト用のハーネスがないことです。それは私が一緒に解決したいと思っている別の問題です。統合テストがないので、私はあなたが推奨することはできません。テストされないままになっている未定義の依存性が多すぎます。
P.Brian.Mackey

テストについて述べた理由は、APIを使用するユーザーがテストを実行し、2つの呼び出し間の問題を理解するのに役立つように、これを明確にしたかったためです。あなたの最良の選択肢は、あなたのコードを使用している開発者を火の中に投げ込み、彼らに新しい実装を使用させて、彼らが完全なQAを行うか、独自のテストをすることを望んでいるようです。
ブライアン2012

私は自分を火の中に投げ込みます。私はむしろ私が投稿した元のコードを使い続けたいと思っています。そのようにして、誰も私を3時に呼び出して、なぜプロダクションコードが壊れたのか疑問に思いました。次に、開発者がコードの陳腐化を解決し、警告フラグを修正して修復するようにします。それらがその時点でそれを修正しない場合、接続文字列がそれらで失敗し始めたとき、警告フラグを修復しないための彼らの責任は...私のものではありません。
P.Brian.Mackey

新しいコードを書くときはいつでも、問題を引き起こすリスクがあります。テストでは、恐れることなくリファクタリングできます。恐怖はマインドキラーです。さらに、あなたは避けられないことを遅らせているだけです。彼らは今から数回の繰り返しで彼らの通話に不本意ながら「2」を追加し、それがうまくいかない場合は同じ電話を受けることになります。
ブライアン2012
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.