Quando deprecare e quando eliminare in Java

Come parte di uno sforzo di refactoring o di uno sviluppo continuo, un metodo particolare o forse un'intera classe può diventare obsoleto in un certo senso. Java supporta l' @Deprecatedannotazione per indicare che probabilmente esiste un modo migliore per gestire la funzionalità in questione. Immagino che ciò sia particolarmente utile nelle API pubbliche in cui gli effetti della rimozione di parti di un'API potrebbero non essere noti. Per un'API non pubblica e un progetto che utilizza sistemi di controllo delle revisioni (quindi l'eliminazione può essere annullata in un certo senso), quando è appropriato deprecare anziché eliminare gli elementi obsoleti?

La tua API è un'API pubblica? Ciò determina se è necessario deprecare o rimuovere. Se l'API è strettamente a tuo vantaggio (ovvero utilizzata solo all'interno della tua azienda), è meglio rimuovere semplicemente il codice offensivo. È molto più pulito e causerà meno mal di testa di manutenzione a lungo termine.

Tuttavia, se l'API è di fronte al pubblico, la semplice rimozione di un metodo può causare l'interruzione del codice che funzionava con le versioni precedenti della libreria. Ecco dove le cose si fanno confuse. Di seguito sono riportate alcune linee guida:

• API interna: rimuovi anziché deprecare. Se un client utilizza una classe o un metodo interno, è colpa sua se lo strumento si rompe.
• API esterna: prima deprecare, rimuovere in seguito. La deprecazione è una bandiera che qualcosa verrà rimosso in seguito. Successivamente dipende da ciò che ritieni ragionevole. Almeno dare 2-3 versioni prima di rimuovere effettivamente il codice deprecato.

Probabilmente è una buona idea impostare un promemoria quando si definisce una classe o un metodo. Lo stai facendo per promuovere la sua obsolescenza. Quindi, indovinate quanto tempo ci vorrà, come tempo libero, per arrivare a, compito, per eliminare tutti i riferimenti. Contrassegnalo come @deprecated e inserisci un promemoria nel tuo calendario. Quando ricevi il promemoria, controlla. Se non viene più utilizzato, eliminalo. Se rimangono un paio di riferimenti che possono essere aggiornati rapidamente, farlo ed eliminare l'elemento. Se il lavoro più significativo rimane, fai avanzare un po 'il tuo promemoria.

Fallo abbastanza volte e svilupperai un'idea di quanto tempo ci vuole per sbarazzarsi di una classe o di un metodo nei tuoi progetti.

IMHO se puoi assicurarti che nessuno lo stia usando e non lo farà mai, rimuovilo. (Questo può essere complicato in presenza di riflessi o componenti esterni come le macro di Velocity - gli IDE moderni come IntelliJ possono trovare riferimenti in ad esempio JSP ma non tramite reflection o in Velocity.)

Se esiste un'alternativa migliore ma quella vecchia viene ancora utilizzata in molti luoghi e al momento non si ha il tempo di refactoring di tutto il codice client, è opportuno @deprecare la classe / il metodo obsoleti (con un commento adeguato su l'alternativa preferita).