Quelles sont les meilleures pratiques pour éliminer progressivement le code obsolète?

J'ai le besoin de supprimer progressivement une méthode obsolète. Je connais l' [Obsolete]attribut. Microsoft a-t-il un guide de bonnes pratiques recommandé pour ce faire?

Voici mon plan actuel:

R. Je ne veux pas créer un nouvel assemblage car les développeurs devraient ajouter une nouvelle référence à leurs projets et je m'attends à beaucoup de chagrin de mon patron et de mes collègues s'ils doivent le faire. Nous ne conservons pas non plus plusieurs versions d'assemblage. Nous utilisons uniquement la dernière version. Changer cette pratique nécessiterait de changer notre processus de déploiement, ce qui est un gros problème (il faut apprendre aux gens comment faire les choses avec TFS au lieu de FinalBuilder et les amener à abandonner FinalBuilder)

B. Marquez l'ancienne méthode comme obsolète.

C. Parce que l'implémentation change (pas la signature de la méthode), j'ai besoin de renommer la méthode plutôt que de créer une surcharge. Donc, pour informer les utilisateurs de la méthode appropriée, je prévois d'ajouter un message à l' [Obsolete]attribut. Cette partie me dérange, car le seul changement que je fais est de découpler la méthode de la chaîne de connexion. Mais, comme je n'ajoute pas de nouvel assemblage, je ne vois aucun moyen de contourner cela.

Résultat:

[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.
        }

Microsoft utilise l'attribut [obsolète] pour indiquer aux développeurs que la méthode, la propriété ou la classe est obsolète et peut être modifiée (ou non prise en charge du tout) dans les versions futures.

Cela vous donne au moins un cycle de publication pour informer les utilisateurs de votre API que leur fonctionnalité "disparaît" et pour supprimer les références à celle-ci dans les futures versions de leur logiciel.

La durée pendant laquelle vous laissez la fonction d'origine dépend entièrement de vous. Si vous souhaitez "fortement encourager" les développeurs à utiliser vos nouvelles fonctionnalités par rapport aux anciennes, vous n'avez besoin que d'un cycle de version supplémentaire pour les supprimer. Si vous avez l'intention d'avoir une compatibilité descendante permanente, vous pouvez la laisser indéfiniment.

Comme le souligne Brian, si vous modifiez uniquement l'implémentation sous-jacente, mais pas la signature de la méthode, vous n'aurez peut-être pas besoin de faire quoi que ce soit du tout.

Parce que l'implémentation change (pas la signature de la méthode), j'ai besoin de renommer la méthode plutôt que de créer une surcharge.

Je ne comprends pas. Si l'implémentation change mais que la signature ne l'est pas, pourquoi feriez-vous cela? Laissez l'ancienne méthode utiliser la nouvelle implémentation améliorée. Tous les développeurs utilisant cette API rouleront des yeux lorsqu'ils verront une méthode avec la même signature créée et des avertissements de dépréciation sur leurs appels de méthode existants. (Pouvez-vous penser à un moment où cela s'est déjà produit dans une API?)

Si vous ne savez pas si la modification de l'implémentation sous-jacente de cette méthode fonctionnera, vérifiez le comportement avec des tests unitaires avant et après avoir modifié l'implémentation.