Quali sono le migliori pratiche per eliminare gradualmente il codice obsoleto?

9

Ho la necessità di eliminare gradualmente un metodo obsoleto. Sono a conoscenza dell'attributo [Obsolete] . Microsoft ha una guida consigliata alle best practice per farlo?

Ecco il mio piano attuale:

A. Non voglio creare un nuovo assembly perché gli sviluppatori dovrebbero aggiungere un nuovo riferimento ai loro progetti e mi aspetto di ottenere un sacco di dolore dal mio capo e dai miei colleghi se devono farlo. Inoltre, non gestiamo più versioni di assembly. Usiamo solo l'ultima versione. Cambiare questa pratica richiederebbe cambiare il nostro processo di distribuzione che è un grosso problema (devi insegnare alla gente come fare cose con TFS invece di FinalBuilder e fargli rinunciare a FinalBuilder)

B. Segna il vecchio metodo obsoleto.

C. Poiché l'implementazione sta cambiando (non la firma del metodo), ho bisogno di rinominare il metodo piuttosto che creare un sovraccarico. Quindi, per rendere gli utenti consapevoli del metodo corretto, ho intenzione di aggiungere un messaggio all'attributo [Obsolete] . Questa parte mi infastidisce, perché l'unico cambiamento che sto facendo è disaccoppiare il metodo dalla stringa di connessione. Ma, poiché non sto aggiungendo un nuovo assembly, non vedo alcun modo per aggirare questo.

Risultato:

[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.
        }
    
posta P.Brian.Mackey 09.04.2012 - 16:26
fonte

2 risposte

5

Microsoft usa l'attributo [obsoleto] per dire agli sviluppatori che il metodo, la proprietà o la classe è deprecato, e potrebbe essere modificato (o non supportato affatto) nelle versioni future.

Questo ti dà almeno un ciclo di rilascio per notificare agli utenti della tua API che la loro funzione sta "andando via" e per rimuovere i riferimenti ad essa nelle versioni future del loro software.

Il tempo per cui lasci la funzione originale dipende interamente da te. Se si desidera "incoraggiare strongmente" gli sviluppatori a utilizzare le nuove funzionalità su quelle precedenti, è necessario solo un ciclo di rilascio aggiuntivo per rimuoverlo. Se intendi avere una retrocompatibilità permanente, puoi lasciarla per sempre.

Come sottolinea Brian, se stai solo cambiando l'implementazione sottostante, ma non la firma del metodo, potresti non aver bisogno di fare nulla del genere.

    
risposta data 09.04.2012 - 17:30
fonte
4

Because the implementation is changing (not the method signature), I need to rename the method rather than create an overload.

Non capisco. Se l'implementazione sta cambiando, ma la firma non lo è, perché mai dovresti farlo? Lascia che il "vecchio" metodo usi l'implementazione nuova e migliorata. Gli sviluppatori che utilizzano questa API sposteranno gli occhi quando vedranno un metodo con la stessa identica firma creata e avvisi di deprecazione sulle chiamate dei metodi esistenti. (Puoi pensare a un momento in cui questo è mai accaduto in un'API?)

Se non sei sicuro che la modifica dell'implementazione sottostante di questo metodo funzionerà, verifica il comportamento con i test unitari prima e dopo aver modificato l'implementazione.

    
risposta data 09.04.2012 - 17:26
fonte

Leggi altre domande sui tag