Pourquoi le code non utilisé doit-il être supprimé?

J’ai souvent entendu dire que le code non utilisé devait être supprimé du projet. Cependant, il n’est pas clair pour moi “pourquoi?”.

Mes points pour ne pas supprimer qui sont:

  • Le code est déjà écrit et des efforts sont déployés
  • Le code peut être testé sur un environnement réel et syntaxique
  • S’il est bien organisé (groupé, paquet séparé, couplé de manière lâche, etc.), cela ne vous dérange pas sur l’parsing du code global ou le refactoring
  • Le code peut être utilisé à l’avenir
  • Lorsqu’il est supprimé, l’auteur peut se sentir mal à l’aise

Quelqu’un pourrait-il expliquer les avantages de la suppression (ou de la conservation) du code non utilisé?

Merci d’avance!

Voici quelques raisons pour lesquelles le code inutilisé doit être supprimé:

  • Pour quiconque travaille sur un projet, il doit non seulement comprendre le code de travail, mais également comprendre le matériel inutilisé. C’est du temps perdu et crée de la confusion.

  • Il y a un risque que quelqu’un, à un moment donné, fasse un changement qui implique par inadvertance le code «dormant» et peut introduire des bogues. Je sais que c’est arrivé sur des projets sur lesquels j’ai travaillé.

  • La maintenance de tout code est une charge administrative. En préservant l’ancien code redondant, ce fardeau augmente. Par exemple, la fusion des modifications dans la twig principale devient plus difficile car il y a plus de code à traiter et plus de possibilités de commettre des erreurs.

  • Ce qui se passe avec le temps, c’est que de plus en plus d’anciens codes inutilisés sont ajoutés à la base de code. Cela augmente la confusion, les malentendus potentiels et les frais administratifs.

  • Il est peu probable que le code inutilisé soit utilisé à nouveau. Avec le temps, cette possibilité de réutilisation diminue. Si le code à supprimer est considéré comme suffisamment important, le code peut être extrait et documenté.

  • Tout sentiment personnel qu’un codeur peut avoir à propos du code sur lequel ils ont travaillé dur est compréhensible. Mais pour être professionnel, il faut que ces idées soient mises de côté pour le meilleur. Le temps est synonyme de personne et il n’y a pas de place pour préserver le code historique dans une base de code fonctionnelle.

@suspectus a fait un excellent travail en présentant les raisons de la suppression du code; Je voudrais aborder vos points individuels pour garder le code.

  • Le code est déjà écrit et des efforts sont déployés

Mais si le code déjà écrit n’est pas utilisé, cela ne coûte que sans valeur (future). C’est l’effort investi en vain, et la préservation du produit inutilisé de ces efforts ne valide pas ces efforts. Nous gardons le code car il est utile, maintenant, pas comme une sorte de mémorial pour les efforts des auteurs.

  • Le code peut être testé sur un environnement réel et syntaxique

Je suis désolé, je ne sais pas ce que tu veux dire par là.

  • S’il est bien organisé (groupé, paquet séparé, couplé de manière lâche, etc.), cela ne vous dérange pas sur l’parsing du code global ou le refactoring

S’il existe dans la base de code, quelle que soit son organisation, cela consortingbue à la charge de maintenance et de compréhension. Certes, il peut être organisé de manière à être moins lourd, mais s’il est parti, ce n’est pas un fardeau.

  • Le code peut être utilisé à l’avenir

Dans l’école Agile, on dit YAGNI : Tu ne vas pas en avoir besoin. Oui, vous en aurez peut- être besoin dans le futur, mais nous ne pouvons pas en savoir assez aujourd’hui sur les besoins de demain pour pouvoir prévoir cela avec toute fiabilité. Penser autrement est une arrogance qui tend à l’orgueil. Ce que nous pouvons savoir sur demain, c’est: nous voulons que notre base de code soit facile à modifier et que le code inutilisé détruise cette caractéristique.

  • Lorsqu’il est supprimé, l’auteur peut se sentir mal à l’aise

L’auteur doit le surmonter. Nous avons tous écrit des choses qui ne se sont pas avérées utiles – il est préférable de pouvoir pointer vers un corps de code qui est tout utilisé (parce que la version inutilisée a été supprimée) que vers un corps de code dans lequel vous pouvez dire quelques méthodes, “et celle-ci est réellement utilisée!”

N’est-il pas assez difficile de trouver du code et de comprendre l’intention, mais vous devez maintenant déterminer quelles parties ne sont pas utilisées?

Le code est déjà écrit et des efforts sont déployés

C’est aussi inutile. Si vous ne l’utilisez pas pour quelque chose, il est (par définition) inutile, peu importe ce qu’il fait ou combien d’efforts ont été consacrés à cela.

Le code peut être testé sur un environnement réel et syntaxique

Si cela ne sert à rien, cela rest inutile même si vous avez des tests dessus. Si le code est inutile, les tests devraient également être inutiles (en gardant le code commenté, cela crée une ambiguïté – conservez-vous les tests? Si vous aviez le code client du code commenté, commentez-vous également le code client? )

S’il est bien organisé (groupé, paquet séparé, couplé de manière lâche, etc.), cela ne vous dérange pas sur l’parsing du code global ou le refactoring

Pas si. Tous vos outils (contrôle de source, parsing statique, extracteur de documentation, compilateur, etc.) seront plus lents, car ils doivent traiter plus de données (et une partie plus ou moins importante de ces données est du bruit).

Par contre, si le code n’est pas bien organisé, cela perturbera l’parsing statique, le refactoring et tout autre.

Vous introduisez du bruit dans les entrées de vos outils et espérez qu’elles s’y adapteront correctement.

Que faire si votre outil d’parsing statique calcule un rapport commentaires / code? Vous venez de le foirer, avec quelque chose qui était pertinent jusqu’à hier (ou à chaque fois que le code était commenté).

Le plus pertinent de tous, les blocs de code commentés introduisent des retards dans la compréhension du code pour la maintenance et le développement ultérieur, et ces délais coûtent presque toujours cher. Demandez-vous ceci: Si vous avez besoin de comprendre la mise en œuvre d’une fonction, que préféreriez-vous regarder? deux lignes de code clair ou deux lignes de code et vingt-six autres commentaires qui ne sont plus réels?

Le code peut être utilisé à l’avenir

Si c’est le cas, vous le trouverez dans le MCS de votre équipe.

Si vous utilisez un SCM compétent et que vous comptez sur lui pour conserver le code mort (au lieu d’encombrer la source), vous devriez voir non seulement qui a supprimé ce code (commit author), mais pour quelle raison (message de validation), et des modifications ont été apscopes avec lui (le rest des diffs pour cette validation).

Lorsqu’il est supprimé, l’auteur peut se sentir mal à l’aise

Alors?

Vous êtes (je suppose) une équipe entière de développeurs qui est payée pour faire le meilleur logiciel que vous savez, pas “le meilleur logiciel que vous sachiez sans nuire aux sentiments de X”.

C’est une partie de la programmation, que la plupart des codes écrits seront finalement éliminés; Par exemple, Joel Spolsky a déclaré qu’à un moment donné, pour sa société, environ 2% du code écrit prévoyait la production.

Si vous donnez la priorité à l’ego des développeurs par rapport à la qualité de la base de code, vous sacrifierez la qualité de votre produit, car … quoi exactement? Préserver l’immaturité de vos collègues développeurs? Protéger les attentes irréalistes de vos collègues?

Edit: J’ai vu une raison valable de laisser du code commenté dans la source, et c’est un cas très spécifique: quand le code est écrit sous une forme étrange / non intuitive et que la méthode de réécriture est propre travailler pour une raison vraiment subtile. Ceci devrait également être appliqué seulement après qu’une tentative répétée ait été faite pour corriger le problème et chaque fois que la tentative a réintroduit le même défaut. Dans un tel cas, vous devez append le code intuitif commenté en tant que commentaire, et expliquer pourquoi il ne fonctionne pas (pour que les futurs développeurs ne tentent plus le même changement):

// note by : the X parameter here should normally // be a reference: // void teleport(dinosaur& X); // but that would require that we raise another dinosaur and // kill it every twelve hours // as such, the parameter is passed by value void teleport(dinosaur X); 
  • La peur Cela rend l’équipe plus inquiète et produit moins. La quantité de peur augmente de façon exponentielle lorsque plus de code mort est introduit. “Nous ne soaps pas si ce bit est utilisé, donc nous n’osons pas le supprimer ou le toucher.”
  • Changements rapides Si quelque chose qui doit être changé partout dans le système existe aussi dans le code mort, le changez-vous? Il est très difficile de savoir s’il n’est pas utilisé quelque part, alors c’est toujours un risque. Et même si cela ne cassait rien, le code mort fonctionnerait-il du tout s’il serait réutilisé après ce changement?

    En cas de changement radical, les développeurs devront également vérifier chaque endroit contenant le code et, en cas de code mort, cela sera redondant. Et les vérifier prend plus de temps lorsque le code est mort car il est difficile de vérifier qu’il n’est utilisé nulle part.

  • Charge mentale . Chaque fois que vous devez vous demander si quelque chose est utilisé ou si vous devez faire quelque chose pour le code mort, cela prend un peu de votre cerveau.
  • Chasse à l’oie sauvage “J’ai besoin d’un exemple sur la façon d’utiliser Foobar. Oh, c’est dans ces endroits dans le code. Je vais vérifier le premier coup et trouver où il se trouve dans l’interface utilisateur. Hmm … Je ne peux le trouver nulle part.”
  • Rapports gonflés (par exemple, combien de lignes de code, classes, routines, modifications). Distorsion de la visibilité du projet et décisions sur les parties du code qui devraient être travaillées et les estimations des projets futurs.
  • Confiance affaiblie sur la base de code . Cela peut entraîner plus de temps passé sur des tâches redondantes et briser le stream de l’utilisation de la base de code. Les développeurs devront peut-être vérifier très attentivement que tout ce qu’ils utilisent fonctionnera comme ils le pensent.

C’est extrêmement utile si vous savez qu’une partie du code n’est pas utilisée car vous pouvez la supprimer. Si vous le laissez restr, à l’avenir, il peut être difficile, voire impossible, de vous assurer qu’il n’est pas réellement utilisé. Par exemple, certaines des choses qui utilisent le code de manière surprenante: reflection, appel dynamic de routines concaténées à partir de chaînes, eval, framework magic .

Cependant, s’il y a une forte probabilité que le code soit utilisé à l’avenir, il est plus facile d’append si c’est le cas le long de l’autre code plutôt que dans le système de contrôle de version. Il se peut que vous ne vous souveniez pas des mots du code après un certain temps, il peut donc être très difficile de trouver le code dans les entrailles du VCS. Mais je laisserais le code mort exister seulement rarement et même alors je commenterais le code.

Le code mort pollue votre code

Le code mort diminue la compréhensibilité et la lisibilité.

Les meilleurs codes sont toujours réutilisés et si vous avez des codes morts, cela réduit la réutilisation

Nous sums guidés par une approche modulaire du codage, dans laquelle nous concevons des codes pour l’interaction avec nos collègues programmeurs, et non pour une machine. Nous devrions consacrer le plus d’énergie à la compréhension de notre code. La machine ira bien de toute façon.

Un code mort ou commenté est comme un faux sentier qui ne fait qu’embrouiller les gens, alors évitez-le à tout prix.

Tout d’abord, vous devez toujours utiliser un outil de contrôle de code source pour gérer vos projets. La suppression du code inutilisé est donc une bonne pratique car vous pouvez toujours revenir en arrière en utilisant le contrôle de code source pour obtenir le code supprimé. Pour moi, la raison de supprimer le code inutilisé est que seule la personne connaissant le code non utilisé le sait, quelqu’un d’autre dans l’équipe rencontrera ce code et essaiera de déterminer ce qu’il fait et comment il s’intègre dans l’application entière et se sentiront déçus après tant d’efforts que le code n’est pas utilisé du tout 🙂

Je pense que vous pouvez avoir deux cas: – le code de l’application: s’il est inutilisé, il est peut-être non testé et non modifié, peut-être vous pouvez passer à un “référentiel interne” – code API: si vous écrivez un meilleur choix pour le maintenir mais dans votre processus de développement actif

Êtes-vous sûr que le code n’est pas utilisé?

Il ne suffit pas de vérifier que le code comstack toujours. En C ++, si vous supprimez une méthode implicite définie par l’ operator= comme operator= vous n’allez pas obtenir d’erreur de compilation, la classe commencera simplement à utiliser une implémentation par défaut (potentiellement incorrecte). En Java ou en C #, le code peut être utilisé par reflection. Dans les langages orientés object, l’inheritance peut jouer un rôle (la classe de base peut maintenant être appelée). Dans presque toutes les langues, une autre fonction surchargée peut avoir pris le relais.

Vérifiez l’âge du code dans le contrôle de version, pas seulement qu’il n’est pas utilisé. J’ai vu du code qui semblait inutilisé mais qui venait juste d’être commis et qui était en fait la première étape d’un projet d’un autre développeur.

Supprimer agressivement le code inutilisé

Il y a de nombreuses façons de payer du temps pour la maintenance de chaque ligne de code, mais ce qui n’a pas été mentionné, c’est le coût en temps d’ingénierie pour réparer les versions endommagées. Nous avons récemment eu une chaîne compliquée de changement en cours, introduisant une nouvelle surcharge du code inutilisé, menant à un mal de tête de taille raisonnable pour chaque ingénieur de l’équipe.

Supprimer un code mort est un excellent travail pour un stagiaire, qui a peu de lien émotionnel avec la mise en œuvre. Il est regrettable que certains auteurs se sentent “mal à l’aise” de voir leur code supprimé, mais l’avantage est qu’ils apprendront l’importance de la qualité plus rapidement. Le code et la plupart des gens écrivent sur un horizon de dix ans.

Cette discussion a plusieurs années, mais je viens de la rencontrer …

Une chose que je n’ai pas vue mentionnée est le travail à faire pour supprimer le code inutilisé. Dans de nombreux cas, le temps et les efforts nécessaires pour supprimer le code inutilisé ne sont pas anodins. De plus, le test et la documentation du système refacturé entraînent généralement des coûts supplémentaires. Juste une autre chose à considérer dans le processus de décision.

  • Le code non utilisé est un espace de recherche plus important pour vous et pour tout ce qui parsing votre code. Par exemple, un compilateur, un IDE, une recherche dans un fichier, un débogage, une parsing statique, plus d’informations, l’inclusion de fichiers, l’extraction de VCS, etc. Cela ralentit ces processus et ajoute un bruit important.
  • Le code non utilisé n’est pas toujours un code mort. Il peut être exécuté dans certaines circonstances. Cela peut non seulement offrir un vecteur de bogues et de problèmes de performances, mais peut également constituer un problème de sécurité. En ce qui concerne les performances, cela peut s’exprimer de manière inattendue, comme des téléchargements plus importants.
  • Le code non utilisé engendre du code inutilisé. Si vous supprimez un appel de fonction et recherchez des utilisations de cette fonction pour voir si elle est encore nécessaire, vous pouvez voir une correspondance avec le code inutilisé précédent et supposer que vous pouvez la conserver. Plus vous avez de code inutilisé, plus il y a de sauts pour déterminer si le code n’est pas utilisé.
  • Le code non utilisé finit souvent par devoir être maintenu. Disons que A et B dépendent de C. Out of B n’est pas utilisé. Vous changez de C, puis B ne comstackra pas car vous avez supprimé un membre d’une structure dans C requirejse par B, maintenant vous devez corriger B ou le supprimer activement de la compilation. Vous devriez l’avoir simplement retiré.

Cette liste peut sembler simple, mais chacune d’entre elles se manifeste par des centaines de manières différentes, ce qui ajoute un effet de traînée synergique tout au long du processus de développement. L’inefficacité peut souvent être prouvée ou démontrée de manière simple et mathématique.

En réponse à vos points …

  • Le code est déjà écrit et des efforts sont déployés

Mais il faut souvent le maintenir. Il apparaîtra également toujours dans des choses telles que la recherche dans un fichier.

  • Le code peut être testé sur un environnement réel et syntaxique

Je ne suis pas sûr de ce que tu veux dire par celui-ci. Je pense que c’est la même chose que la dernière. Vous voulez dire que le code a déjà été testé et que le nettoyer peut nécessiter un nouveau test. C’est un coût qui en vaut généralement la peine, car il sera rentabilisé 90% du temps et pour éviter qu’il soit nettoyé avant de sortir en production. Presque tout le code a deux itérations, le fait fonctionner, le rend propre. La raison en est qu’il faut tester deux fois parce que quelqu’un a sauté la dernière étape. Si votre code est trop coûteux à prouver, lisez le diff, le test (ce qui est probablement le cas si le code est inutilisé), etc.

  • S’il est bien organisé (groupé, paquet séparé, couplé de manière lâche, etc.), cela ne vous dérange pas sur l’parsing du code global ou le refactoring

Votre code devrait être comme ça de toute façon, mais cela ne modère que modérément le problème. C’est l’argument le plus étrange d’entendre que quelque chose doit être organisé mais impur. Il est normal d’essayer de garder le code modulaire et de réduire les dépendances, mais vous voulez aussi du code réutilisable et si tous vos modules sont des îlots, il y a de fortes chances que vous n’ayez pas été sec. Vous pouvez également vous retrouver à effectuer un découplage excessif qui ne fait que réduire le problème du code désordonné inutilisé.

  • Le code peut être utilisé à l’avenir

Beaucoup de gens sur la valeur du code écrit. Si vous ne l’utilisez pas maintenant, c’est un poids mort et, en réalité, lorsque vous parcourez ce chemin, seule une fraction du code inutilisé est souvent utilisée. En toute probabilité, le code inutilisé est susceptible d’être un code utilisable ou utilisé. Le code le plus susceptible d’être réutilisé est déjà utilisé et fait quelque chose. Ce qui est pire, c’est que le code inutilisé n’a pas de but. Quand quelqu’un arrive et doit changer quelque chose qui finit par avoir un impact sur le code inutilisé, il va restr coincé en essayant de comprendre ce que ce code inutilisé n’a pas besoin de faire.

Il est facile pour les gens de se sentir comme ça au démarrage, car le code demande beaucoup d’efforts. Une fois couramment utilisé, le code devient comme faire du vélo. Vous constaterez que le coût d’écriture d’un tel code fait chuter le coût de sa conservation.

  • Lorsqu’il est supprimé, l’auteur peut se sentir mal à l’aise

C’est le problème de l’auteur. D’un côté, il est égoïste de laisser des tas de code inutilisé pour que d’autres personnes aient à traiter. D’autre part, si un auteur met ses sentiments sur la qualité du code, il ne devrait probablement pas être en train de coder. Vous allez sur la route avec ceci vous ne pouvez pas réparer leur code quand il est cassé parce que cela nuira à leurs sentiments. Ce n’est pas un bon signe si quelqu’un est attaché au code simplement parce que c’est le leur plutôt que parce que c’est bon. Un auteur devrait être heureux de voir son code nettoyé. C’est comme si quelqu’un sortait vos poubelles et les jetait à la poubelle.

Je serais sur la lune si quelqu’un le faisait pour moi. Ce qui pourrait rendre plus facile de surmonter ces sentiments, au lieu d’attendre que quelqu’un d’autre le fasse, essayez de le faire vous-même. Continuez à réécrire de manière itérative un morceau de code que vous avez fait, le rendant plus performant, évoluant de manière concise, avec moins d’excès et plus flexible tout en ayant moins de code à chaque fois. Essayez de ne pas vous sentir bien dans la quantité de code mais combien vous pouvez réaliser avec un code aussi petit. Cela grince vers le haut et une fois que vous faites cela, tout votre code sortira à un bon niveau, il ne sera donc pas nécessaire de le niveler aussi souvent.