Pratiche agili per evitare codice deprecato?[Chiuso]

https://stackoverflow.com/questions/1087296

23-08-2019
|

Domanda

Sto convertendo una libreria Java open source in C#, che presenta una serie di metodi e classi contrassegnati come deprecati.Questo progetto è un'opportunità per iniziare da zero, quindi ho intenzione di rimuoverli completamente.Tuttavia, essendo nuovo nel lavorare su progetti più grandi, sono nervoso che la situazione si ripresenti.Poiché gran parte dello sviluppo agile ruota attorno al far funzionare qualcosa ora e al refactoring in un secondo momento, se necessario, sembra che la deprecazione delle API debba essere un problema comune.Esistono misure preventive che posso adottare per evitare/minimizzare la deprecazione dell'API, anche se non sono del tutto sicuro della direzione futura di un progetto?

Soluzione

Non sono sicuro che c'è molto che si può fare. Requisiti cambiare, e se avete assolutamente fare in modo che i clienti delle API non sono rotti dalla versione API più recente, dovrete semplicemente fare affidamento su deprecando il codice fino a quando pensi che nessuno sta usando il codice deprecato.

Collocamento [obsoleto] attributi sul codice fa sì che il compilatore per creare avvisi se ci sono riferimenti ai metodi obsoleti. In questo modo i clienti delle API, se sono diligenti circa fissare i loro avvertimenti del compilatore, possono passare gradualmente a nuovi metodi senza avere tutto rompere con la nuova versione.

Il suo utile se si utilizza di override del ObsoleteAttribute che prende una stringa:

[Obsolete("Foo is deprecated. Use Bar instead for munging widgets.")]

Forse si potrebbe creare un TimeBombAttribute:

[TimeBomb(new DateTime(2010,1,1), "Foo will blow up! Better use Bar, or else."]

Nel codice, riflettere per i metodi con l'attributo timebomb e gettare KaboomException se sono chiamati dopo la data specificata. Che farò in modo che dopo il 1 ° gennaio 2010 n-one sta usando i metodi obsoleti, e si può ripulire il vostro API piacevolmente. :)

Altri suggerimenti

Come dice Matt, il href="http://msdn.microsoft.com/en-us/library/system.obsoleteattribute.aspx" rel="nofollow noreferrer"> Obsolete attributo

Naturalmente, si dovrebbe essere diligente nel fare in modo si non si chiama il codice obsoleto -. In particolare nel codice di esempio

Poiché gran parte dello sviluppo agile ruota attorno al far funzionare qualcosa ora e al refactoring in un secondo momento, se necessario

Non è agile.È un codice da cowboy mascherato sotto l'etichetta di agile.

L'ideale è che qualunque cosa tu completi, lo è completare, in base alla definizione di Fatto che hai.Di solito il Dipartimento della Difesa afferma qualcosa sulla falsariga di "funzionalità implementate, testate e relativo refactoring del codice".Naturalmente, se stai lavorando su un prototipo usa e getta, puoi avere un Dipartimento della Difesa più rilassato.

Le modifiche API sono una bestia difficile.Se si stanno modificando solo API interne al progetto, il modo migliore per procedere è eseguire il refactoring in anticipo.Se devi modificare l'API interna, vai avanti e modifica tutti i client API contemporaneamente.In questo modo il debito del refactoring non diventa molto grande e non è necessario utilizzare la deprecazione.

Per le API pubblicate probabilmente hai alcune garanzie di compatibilità sorgente e binaria che devi mantenere, almeno fino alla prossima versione principale o giù di lì.Contrassegnare le vecchie API come deprecate funziona mantenendo la compatibilità.Come con le API interne, dovresti correggere il tuo codice interno il prima possibile per non utilizzare le API deprecate.

La risposta di Matt è un consiglio solido. Volevo solo dire che all'inizio avevamo deciso probabilmente avrete bisogno di usare qualcosa sulla falsariga di:

[Obsolete("Please use ... instead ", false)]

Una volta ottenuto il codice di porting, modificare il falso per vero e il compilatore, poi, il trattamento di tutte le chiamate al metodo come un errore.

La regola generale per la progettazione API è quello di concentrarsi su ciò che fa, piuttosto che come lo fa. Una volta che si conosce l'obiettivo finale, capire l'input minimo assoluto che ti serve e usare quella. Evitare di passare i propri oggetti come parametri, passare solo i dati.

configurazione separata dall'esecuzione. Per exmaple, forse hai un codificatore image / decoder.

Invece di fare una chiamata del tipo:

Encoder.Encode( bytes, width, height,  compression_type, compression_ratio, palette, etc etc);

Lo rendono

Encoder.setCompressionType(compression_type);
Encoder.setCompressionType(compression_ratio);
etc,etc
Encoder.Encode(bytes, width, height);

In questo modo l'aggiunta o la rimozione di impostazioni è molto meno probabile per rompere implementazioni esistenti.

Watch Josh Bloch " Come progettare un buon API e perché è importante "

La maggior parte importante w / r / t deprecazione è sapere che "in caso di dubbio, lasciare fuori." Guarda il video di chiarimenti, ma ha a che fare con la necessità di sostenere quello che fornisci sempre. Se si sta realisticamente aspettate che API per essere riutilizzato, si sta impostando in modo efficace le vostre decisioni in pietra.

Credo che il design API è una cosa molto più difficile da fare in modo agile, perché ci si aspetta che venga riutilizzato probabilmente in molti modi diversi. È necessario preoccuparsi di rompere gli altri che dipendono da voi, e così mentre si può fare, è difficile avere il giusto disegno emergere senza ottenere un ritorno rapido da altre squadre. Naturalmente deprecazione sta per aiutare qui, ma penso che YAGNI è molto migliore progettazione euristica quando si tratta di API.

Credo deprecation di codice è un sottoprodotto inevitabile di processi agili come refactoring continuo sviluppo incrementale. Quindi, se si finisce con il codice deprecato come si lavora sul progetto, che non è necessariamente una brutta cosa - solo un fatto della vita. Naturalmente, probabilmente troverete che, piuttosto che deprecando il codice, si finisce per mantenere un sacco di codice, ma refactoring in diversi metodi, classi, e così via.

Quindi, linea di fondo: io non mi preoccuperei deprecando codice durante lo sviluppo Agile. Se è servito allo scopo per un po ', si sta facendo la cosa giusta.

Per deprecazione, ci sono fondamentalmente 3 tipi di API:. Interno, esterno e pubblico

interno è quando il suo solo la tua squadra a lavorare sul codice. Deprecando queste API non è un grosso problema. La tua squadra è l'unico ad usarlo, quindi non sono in giro a lungo, non c'è pressione per cambiare loro, le persone non hanno paura di cambiare, e la gente sa come cambiare loro.

esterno è quando i suoi la stessa base di codice, ma diverse squadre stanno usando. Questo potrebbe essere alcune librerie comuni in una grande azienda, o di una libreria open source popolare. Il punto è che la gente può scegliere la versione del codice che compilano con. La facilità d'intaccare un'API dipende dalle dimensioni dell'organizzazione e come comunicano. IMO, il di deprecator di lavoro per aggiornare il vecchio codice, piuttosto che segnare è deprecato e lasciare che gli avvertimenti volano per tutta la base di codice. Perché la deprecator invece del deprecatee? Perché il depcarator è a conoscenza; essi sanno che cosa è cambiato e perché.

Questi due casi sono abbastanza facili. Fino a quando non v'è la compatibilità all'indietro, in generale si può fare quello che desideri, aggiornare i client da soli, o convincere i manutentori per farlo.

Poi ci sono API pubbliche. Queste sono fondamentalmente API esterne che i clienti non hanno molto controllo su, come ad esempio un'API web. Questi sono incredibilmente difficili da aggiornare o disapprovare. La maggior parte non notare la sua rotta, non avere qualcuno per risolvere il problema, non sarà possibile ottenere le notifiche che il suo cambiamento, e solo risolvere il problema una volta la sua rotta (dopo che hanno urlato a si per romperlo, oltre ovviamente).

Ho dovuto fare quanto sopra un paio di volte, ed è un lavoro di routine. Penso che il meglio che puoi fare è volutamente romperlo primi , attendere un po ', e poi ripristinarlo. Si invia le solite avvertenze e deprecati prima, naturalmente, ma - credetemi -. Non succederà nulla fino a quando qualcosa si rompe

Un'idea devo ancora provare è quello di permettere alle persone di registrare semplici applicazioni che girano piccole prove. Quando si desidera fare un aggiornamento API, si eseguono i test esterni e contattare le persone colpite.

Un altro approccio per essere popolare è quello di avere clienti dipendono da servizi (web). Ci sono costrutti là fuori che ti permettono alla versione vostri servizi e consentono ai clienti di eseguire le ricerche. Questo aggiunge molto di più parti e la complessità in movimento nell'equazione, ma può essere utile se si sta cercando di girare su un sacco di versioni, e di dover supportare più versioni in produzione.

Questo articolo fa un buon lavoro di spiegare il problema e un approccio.

Autorizzato sotto: CC-BY-SA insieme a attribuzione

Non affiliato a StackOverflow