Dois-je supprimer le code non référencé?
Je travaille sur une base de code de taille moyenne (100k lignes), c'est un code relativement récent (moins d'un an) et a une bonne couverture de test unitaire.
Je continue de rencontrer des méthodes qui ne sont plus utilisées nulle part ou qui ne sont référencées que dans des tests unitaires qui testent uniquement cette méthode spécifique.
Dois-je supprimer ce code si je suis certain qu'il n'est plus nécessaire?
Raisons de le retirer:
- Moins de code, moins de bugs
- Moins de code est plus facile à digérer pour les autres
- C'est toujours sous contrôle de source
Raisons de le garder:
- Peut être utilisé comme référence
- Cela peut être utile parfois
- Il peut avoir été écrit pour "compléter" la fonctionnalité d'une classe
La plupart de vos raisons de le garder ne sont absolument pas pertinentes, en termes simples. Si le code n'est pas utilisé, jetez-le - tout avantage impliqué dans sa conservation peut être dérivé trivialement du contrôle de code source. Tout au plus, laissez un commentaire indiquant dans quelle révision le trouver.
Tout simplement, plus tôt vous coupez le code, plus tôt vous n'aurez pas à perdre de temps à le maintenir, à le compiler et à le tester. Ces avantages l'emportent largement sur les avantages triviaux que vous avez décrits, qui peuvent tous être dérivés du contrôle de source de toute façon.
Toutes les raisons de le supprimer sont valables.
Raisons de le garder:
- Peut être utilisé comme référence
- Cela peut être utile parfois
- Il peut avoir été écrit pour "compléter" la fonctionnalité d'une classe
Toutes ces raisons de le conserver seront gérées par le contrôle des sources. Supprimez-le du code en direct et vous pourrez le récupérer si/quand il est nécessaire.
Le code non référencé revient à garder ces batteries qui sont un peu, à plat au cas où vous en auriez besoin un jour pour une torche.
Tant que vous utilisez une sorte de contrôle de version, je dirais de le supprimer du code en direct et d'utiliser l'historique des versions au cas où cela s'avérerait utile.
La seule bonne raison que je peux voir pour conserver le code qui n'est pas actuellement utilisé est s'il fait partie d'un module autonome: bien que certaines parties du code ne soient pas utilisées pour le moment, il se pourrait bien qu'elles le soient utilisé à l'avenir.
Cela peut être particulièrement vrai pour une bibliothèque que vous utilisez dans différents projets: vous ne voulez pas continuer à jeter des morceaux de code à l'intérieur et à l'extérieur, selon ce dont vous avez besoin pour un projet spécifique: je trouve cela long et source d'erreurs.
Mon approche est la suivante: (1) si vous l'utilisez une seule fois, ne conservez que ce dont vous avez vraiment besoin; (2) si vous l'utilisez deux fois, copiez-le et adaptez-le la deuxième fois que vous l'utilisez; (3) si vous l'utilisez plus de deux fois, faites-en un module stable et bien défini, et utilisez ce module selon vos besoins.
En résumé: je jetterais tout le code inutilisé sauf s'il fait partie d'un module polyvalent que vous avez conçu en tant que tel et que vous savez que vous allez réutiliser plusieurs fois.
Remarque: Bien sûr, une solution encore plus propre consisterait à créer un projet distinct pour une bibliothèque et à ajouter une dépendance entre les projets.
En général, je m'inclinerais devant YAGNI à ce sujet. Si "vous n'en aurez pas besoin", cela prend simplement de la place dans votre base de code, vos tests unitaires et vos assemblages. Vous pourriez en avoir besoin, mais vous devrez peut-être aussi le réécrire complètement car entre maintenant et lorsque vous en avez besoin, beaucoup de choses peuvent changer.
Cependant, cela change quelque peu lorsque vous écrivez un utilitaire ou une API destiné à la consommation générale. Tout comme vous ne pouvez jamais vous attendre à ce que les utilisateurs finaux du logiciel interagissent avec le logiciel de la manière que vous vouliez, vous ne pouvez jamais vous attendre à ce que les consommateurs de votre code souhaitent utiliser votre code exactement comme vous le pensez. Dans de tels cas, tant que vous pouvez justifier l'existence d'une méthode avec "c'est une façon valide de vouloir interagir avec mon objet", alors elle devrait probablement entrer, car même si vous n'en aurez pas besoin, les chances sont bonnes. .
Étant donné que la base de code a moins d'un an, elle est probablement toujours dans beaucoup de flux (oui?) - donc l'idée que certains bits pourraient avoir besoin d'être ressuscités dans un proche avenir n'est pas déraisonnable.
Pour les bits qui étaient difficiles à obtenir en premier lieu et qui semblent plus susceptibles d'être ressuscités, je les garderais un peu plus "en direct" que simplement en contrôle de source. Les gens ne sauront pas/ne se souviendront pas de leur existence - dire "vous pouvez simplement le trouver dans le contrôle de code source" suppose que vous savez/rappelez-vous qu'il est là! Dans ces types de cas, envisagez la dépréciation (avec un showstopper "assert (false)") ou un commentaire.
"Peut être utilisé comme référence" Je ne serais pas d'accord pour être une bonne raison de laisser le code inutilisé. Souvent, seule une petite partie du code inutilisé montre réellement quelque chose d'intéressant. Il existe plusieurs façons de documenter et de stocker du code utile mais non utilisé.
Bien que le contrôle de version contienne un historique qui vous permettra facilement de restaurer des fonctionnalités particulières si vous décidez plus tard que le code est nécessaire, sachant que vous devez aller consulter l'historique du contrôle de version pour trouver xy ou z de qui sait quelle révision précédente peut être un peu fastidieux, et est souvent négligé à moins que vous n'ayez une idée assez précise de ce que vous recherchez.
Le code pourrait être commenté avec une note sur quand il a été supprimé et pourquoi il n'a pas été simplement supprimé du code. Cependant, cela est généralement considéré comme un mauvais style, et le code qui n'est pas utilisé et n'est pas entretenu correctement peut introduire toutes sortes de bogues s'il n'est pas commenté plus tard, c'est donc généralement mieux comme étape de débogage/test temporaire pendant la refactorisation à mi-chemin que un moyen de quitter le code de production.
Ma façon préférée de stocker le code supprimé, s'il semble être utile à l'avenir, est de créer un document de référence secondaire contenant tous les différents morceaux de code supprimé utile. Chaque bloc de code est étiqueté avec une brève mention d'où il vient ou tout autre élément pertinent à retenir, comme quand il a été supprimé ou le numéro de révision où il était le dernier dans le code à. Tout ce qui a été supprimé mais "potentiellement utile" est en un seul endroit, facilement consultable, mais ne nécessitant pas d'effort constant pour maintenir et tester en continu (ce test est reporté à tout moment où le code est réintroduit).
Si le code est trivial et sans intérêt, je le jette juste pour me débarrasser de l'inertie inutile du système logiciel.
Pour les cadavres de code intéressants, j'utilise une branche archive dans mes systèmes de contrôle de version.
Une bonne raison de conserver les méthodes inutilisées est: elles pourraient être utilisées sur d'autres branches/tags!
Explorez toutes vos branches et balises actives avant de les supprimer.
J'ai eu assez fréquemment l'expérience de trouver une fonction qui semble faire exactement ce dont j'ai besoin et de lui faire confiance depuis qu'elle est en production depuis longtemps, seulement pour découvrir qu'elle n'a pas été réellement utilisée dans plusieurs années. Le code qui n'est pas utilisé n'est pas conservé, et même s'il a fonctionné il y a des années, l'API tout autour a suffisamment changé pour que vous ne puissiez pas lui faire confiance.
Au mieux, vous finissez par passer beaucoup de temps à vous assurer qu'il fait toujours ce que vous voulez. Au pire, cela semble fonctionner jusqu'à ce que vous soyez mordu avec un bogue méchant plus tard, et prenez plus de temps à le retrouver car vous supposiez que le code "testé en production" fonctionne donc le problème doit être ailleurs dans votre nouveau code. D'après mon expérience, il est presque toujours plus rapide d'écrire moi-même une nouvelle fonction.
Si vous le supprimez, mais découvrez assez rapidement que vous en avez réellement besoin, il est juste là dans le contrôle de code source. Si vous n'en avez pas besoin tant que le temps n'est pas écoulé que vous ne vous souvenez pas qu'il est en contrôle de source, vous feriez probablement mieux de l'écrire à partir de zéro de toute façon.
Rien ne consomme moins de temps qu'aucun code.
Si vous devez plonger dans une base de code, vous avez besoin de temps pour comprendre à quoi ce code est utilisé et s'il est utilisé pour rien, vous avez besoin de plus de temps.
Ok - cela pourrait être guéri soit un commentaire, mais encore une fois, tout le monde se demandera pourquoi ce code inutilisé est toujours dans la base de code, s'il doit être supprimé ou non.
S'il n'y a rien, personne ne perdra de temps avec.
S'il était difficile de bien faire les choses, vous avez besoin d'une bonne documentation, que ce code existe, mais si la base de code évolue au fil de certaines itérations, peut-être que cela ne fonctionnera plus, s'il est réactivé.
Supprimez le code inutilisé - moins d'encombrement, meilleure compréhension. Votre système de contrôle de version s'en chargera. De plus, si vous utilisez quelque chose de mieux que le bloc-notes, votre environnement vous permettra d'utiliser un code plus ancien pour référence.
Les longs commentaires de l'ancien code distraient et rendent la navigation difficile.
Cordialement
Suivez cet algorithme simple:
- Est-il sauvegardé dans un SCM? Si oui, passez à 3.
- Configurez un SCM.
- Jetez les trucs.
Tous vos points en faveur de la suppression sont valables.
Tous vos points en faveur du maintien de l'encombrement sont invalides une fois que vous avez un SCM pour le rechercher ou le restaurer. En fait, votre SCM devrait être en mesure de vous aider à déterminer pourquoi ce code est ici et inutilisé, s'il a été utilisé correctement.
Cela s'appelle "code mort" pour une raison. Qu'il meure et repose en paix.
Si vous utilisez un système de contrôle de version, ne vous inquiétez pas des futures références, car vous pouvez simplement voir l'historique de ce code et trouver la partie supprimée. Si vous ne le faites pas et que vous pensez qu'il serait utilisé un jour, laissez-le simplement y rester, mais commentez-le avec une description expliquant pourquoi il est commenté.
Cependant, si vous êtes sûr de ne pas l'utiliser à l'avenir, simplement supprimez-le. Je pense que les raisons que vous avez mentionnées sont assez simples pour que le code soit supprimé.
Mais avant de le retirer, assurez-vous qu'il n'est utilisé nulle part. Visual Studio a une fonctionnalité appelée Find All References qui recherche la solution entière et trouve toute référence à la variable, méthode, propriété, classe, interface, etc. en cours. Je m'assure toujours qu'aucune référence n'est en place avant de retirer une partie de mon code.
D'après mon expérience, la suppression du code inutilisé peut également se retourner contre. Vous pouvez oublier que vous aviez ce code et vous ne le chercherez pas dans l'historique. Ou vous ne savez peut-être même pas que quelqu'un a implémenté ce code, puis l'a supprimé plus tard. Encore une fois, vous ne le chercherez pas dans l'histoire ...
Sans doute, avoir du code inutilisé est une mauvaise odeur.
MISE À JOUR: Je viens de remarquer qu'Ed Staub a donné une réponse très similaire.
Il restera sous contrôle de source; il ne doit pas rester dans la base de code active.
La seule exception est que si le code termine la conception et que vous n'utilisez pas le code, vous prévoyez éventuellement de le rendre public et d'autres peuvent vouloir cette fonctionnalité de base. Ensuite, concevez simplement des tests pour vous assurer que ces parties du code fonctionnent qui imitent la façon dont vous en proposez d'autres peuvent utiliser ces parties du code. Cependant, si vous envisagez même de supprimer le code et que vous ne pouvez pas trouver une bonne raison de le conserver, cela devrait aller. Le code inutilisé fait plus de travail pour tout le monde (plus difficile à lire le code; le code peut être cassé; plus de travail à maintenir, etc.)