Quand déprécier et quand supprimer en Java

Dans le cadre d'un effort de refactorisation ou simplement d'un développement continu, une méthode particulière ou peut-être une classe entière peut devenir obsolète dans un certain sens. Java prend en charge l' @Deprecatedannotation pour indiquer qu'il existe probablement une meilleure façon de gérer la fonctionnalité en question. J'imagine que cela est particulièrement utile dans les API publiques où les effets de la suppression de parties d'une API peuvent ne pas être connus. Pour une API non publique et un projet qui utilise des systèmes de contrôle des révisions (la suppression peut donc être annulée dans un certain sens), quand est-il approprié de déprécier plutôt que de supprimer le ou les éléments obsolètes?

Votre API est-elle une API publique? Cela dicte si vous devez ou non déprécier ou supprimer. Si l'API est strictement à votre avantage (c'est-à-dire uniquement utilisée au sein de votre entreprise), il est préférable de simplement supprimer le code incriminé. Il est beaucoup plus propre et causera moins de maux de tête d'entretien à long terme.

Cependant, si l'API est accessible au public, la simple suppression d'une méthode peut entraîner l'arrêt du fonctionnement du code qui fonctionnait auparavant avec les anciennes versions de votre bibliothèque. C'est là que les choses deviennent désordonnées. Voici quelques lignes directrices:

• API interne: supprimez plutôt que dépréciez. Si un client utilise une classe ou une méthode interne, c'est de sa faute si l'outil se casse.
• API externe: dépréciez d'abord, supprimez plus tard. La dépréciation est un indicateur que quelque chose sera supprimé plus tard. Plus tard, cela dépend de ce que vous croyez raisonnable. Donner au moins 2-3 versions avant de supprimer le code obsolète.

C'est probablement une bonne idée de configurer un rappel lorsque vous @deprecate une classe ou une méthode. Vous le faites pour favoriser son obsolescence. Alors devinez combien de temps il faudra, en tant que temps libre, au fur et à mesure, pour éliminer toutes les références. Marquez-le comme @deprecated et mettez un rappel dans votre calendrier. Lorsque vous recevez le rappel, vérifiez. S'il n'est plus utilisé, supprimez-le. S'il reste quelques références qui peuvent être rapidement mises à jour, faites-le et supprimez l'élément. Si un travail plus important reste, faites un peu avancer votre rappel.

Faites-le suffisamment de fois et vous comprendrez combien de temps il faut pour se débarrasser d'une classe ou d'une méthode dans vos projets.

À mon humble avis, si vous pouvez vous assurer que personne ne l'utilise et ne le fera jamais, supprimez-le. (Cela peut être délicat en présence de réflexion ou de composants externes tels que les macros Velocity - les IDE modernes tels qu'IntelliJ peuvent trouver des références par exemple dans JSP mais pas via la réflexion ou dans Velocity.)

S'il existe une meilleure alternative mais que l'ancienne est toujours utilisée dans de nombreux endroits et que vous n'avez actuellement pas le temps de refactoriser tout le code client, il suffit de @déprécier la classe / méthode obsolète (avec un commentaire adéquat sur l’alternative privilégiée).