Utilisation de l'attribut Obsolète

Question

On m'a récemment dit que c'était une mauvaise pratique d'avoir marqué un certain nombre de méthodes dans notre code avec l'attribut [Obsolete]. Ces méthodes étaient internes à notre base de code, plutôt que d'être sur une API. Les méthodes géraient une fonction de cryptage plus ancienne. Je pensais que c'était une manière rapide et sûre d'indiquer au reste de l'équipe que ces méthodes ne devraient pas être utilisées, et j'ai fourni un message pour suggérer des alternatives.

D'autres ont estimé que j'aurais dû supprimer entièrement les méthodes, en réécrivant ou en refactorisant le code existant selon les besoins. En outre, il a été jugé trop facile d'ignorer les avertissements du compilateur.

Existe-t-il une «meilleure pratique» pour marquer le code comme obsolète lorsqu'il n'est pas utilisé par des tiers? Ou est-ce largement subjectif?

Answer 1

Étape 1. Sélectionnez le membre ou classe [Obsolete]

Étape 2. Mise à jour toutes les utilisations internes du membre ou de la classe à utiliser soit la nouvelle approche qui remplace l'approche obsolète ou marquer ce membre ou classe lui-même en tant que [Obsolète]

Étape 3. Si vous avez marqué de nouveaux éléments comme [Obsolète] à l'étape 2, répétez cette étape si nécessaire. Étape 4. Supprimez tous les membres et classes obsolètes qui ne sont ni publics ni utilisés par un membre ou une classe publique obsolète. Étape 5. Mettre à jour la documentation pour donner une description plus claire de l'approche recommandée pour remplacer tous les membres ou classes publics obsolètes. À la fin de ceci, vous n'aurez aucun code obsolète qui est seulement utilisé par le code interne. Il n'y a rien à dire que vous devez faire tout cela en une fois cependant; À chaque étape, vous avez progressé. Le délai entre le début de l'étape 1 et la fin de l'étape 5 peut être de 5 secondes ou de 5 ans, en fonction de nombreux facteurs (la plupart étant liés à la complexité). Incidemment, si quelqu'un trouve facile d'ignorer les avertissements du compilateur, le problème n'est pas avec [Obsolète]. Cependant, une raison pour ne pas laisser longtemps de tels appels dans le code (c'est-à-dire, avoir fait aussi loin que l'étape 2 ASAP) est de s'assurer que les utilisateurs ne finissent pas par s'habituer aux avertissements du compilateur. réponse habituelle à la compilation du code.

Answer 2

Je pense que c'est subjectif. Si c'est interne et que c'est un processus assez rapide, alors je ferais le changement.

Cependant, j'ai également eu la situation où le refactoring correspondant a pris beaucoup plus de temps (beaucoup d'appels dans la base de code), auquel cas j'ai utilisé l'attribut [Obsolete]. Dans ce cas, le nouveau développement utiliserait les nouvelles fonctions et celui qui aurait eu le temps d'effectuer des refactorings jusqu'à ce que tous les appels soient partis, ce qui signifiait que la méthode pouvait être supprimée.

Answer 3

Cela dépend. Oui, vous pourriez refactoriser le code. POUVEZ-VOUS?

Le problème est - refactor de youCAN DANS UN SEUL PROGRAMME. C'est beaucoup plus difficile si l'API est dans le public et vous ne pouvez pas refactoriser le code en utilisant votre API. C'est ce que Obsolete est fait pour.

Si l'API est interne à votre code, refactoring est le chemin à parcourir. Nettoyez le code, ne laissez pas un gâchis. Cependant, si l'API publique change, elle devrait, si possible, être effectuée lentement.

Le reste est encore subjectif. Je n'aime pas "Obsolète" pour les API internes.

Answer 4

Ce n'est pas un cas simple. Si vous supprimez des méthodes d'une application qui fonctionne et que vous refactorisez le code, vous créez la possibilité d'introduire de nouveaux bogues et de casser une application fonctionnelle. Si cette application est critique, l'impact pourrait être énorme et coûter beaucoup d'argent à l'entreprise, des changements comme ceux-là devraient être soigneusement planifiés et testés. Dans ce cas, le marquage des méthodes comme obsolètes pourrait valoir la peine d'être utilisé, cela devrait aider à empêcher les gens de les utiliser dans le développement ultérieur, facilitant ainsi le refactoring éventuel. Toutefois, si l'application n'est pas critique ou si le risque d'introduction de bogues est faible, il peut être préférable de refactoriser, si vous en avez le temps. En fin de compte ajouter l'attribut [Obsolete] est un peu comme un todo et son utilisation dépend de nombreux facteurs.

Answer 5

Je l'ai utilisé avant comme une sorte de situation temporaire quand nous avons ancien code qui doit être refondus finalement mais pas d'urgence. Le plus souvent, c'est le cas quand un nouveau code a été écrit qui rend le travail meilleur que ce qui l'a précédé, mais personne dans l'équipe n'a le temps de revenir en arrière et de remplacer beaucoup de vieux code pour le moment. Évidemment, cela implique une situation où un simple remplacement direct n'est pas immédiatement possible (parfois le nouveau code presque tout ce que l'ancien code a fait, mais il y a un petit peu de fonctionnalité qui n'a pas encore été implémentée).Ensuite, avoir tous ces avertissements du compilateur est un rappel constant pour quelqu'un de revenir en arrière et de finir le refactoring quand il a un peu de temps libre.

Que ce soit vraiment une bonne ou une mauvaise chose est plutôt subjectif. C'est un outil, comme un autre.