La notion de "code mort" ne vous parle peut-être pas, ou vous ne vous sentez peut-être pas concerné. Mais qui n’a jamais eu :

• Une portion de méthode devenue inatteignable.
• Une méthode ou une classe devenue totalement inutile.
• Une feature désactivée via un feature flag qui ne sera plus jamais actif.
• Une portion de code commentée.
• Une dépendance devenue inutile.
• Etc.

Nombre de situations peuvent nous amener à avoir du code mort ou des dépendances superflues. De premier abord, cette situation peut sembler anodine et sans conséquence grave. Au pire, il s’agirait peut-être d’un léger problème de qualité…

Au risque de passer à nouveau pour un extrémiste de la qualité, je vais présenter ici quelques problèmes découlant de la présence de code mort. Je vais enfoncer quelques portes ouvertes, énoncer quelques dangers que vous ne suspectez peut-être pas, et parler de leur impact environnemental. À une époque où l’on parle de plus en plus de sobriété numérique, j’espère que ce dernier point vous intéressera.

Les dépendances

Une dépendance inutile est une dépendance qui peut être référencée dans un projet sans être utilisée, ou être référencée dans un code mort. La présence de dépendances inutilisées aura toujours un impact. Il y a les impacts inévitables sur :

• Le stockage (sur les serveurs de build et de delivery, les serveurs applicatifs, ou les clients, etc.).
• Le réseau (pour le delivery, les serveurs web, etc.).
• Les temps (durées de build, durée de publication, durée de téléchargement, etc.).

Si le code qui utilise la dépendance inutile n’est pas exécuté, il n’y a pas d’impact sur la mémoire.

Mais il y a des cas que l’on oublie toujours et qui conduiront à un chargement d’une dépendance inutile :

• Une propriété inutile est d’un type défini dans une dépendance inutile.
• Une méthode utile a un argument inutile d’un type défini dans une dépendance inutile.

Sorti de ces quelques problématiques triviales, il en est une qui l’est moins : pour éviter toute faille de sécurité, il convient de mettre à jour ces dépendances. Une dépendance inutile ne doit pas échapper à cette règle. Ce qui ajoute une charge de travail, et qui dans certains cas peut aboutir à l’obligation d’adapter un code mort. Conserver du code mort peut donc devenir couteux.

En prime, si une dépendance inutile est distribuée via NuGet, npm, ou autre, il y aura un impacte sur la build (sa durée, et sa consommation d’internet). L’usage des Artefacts d’Azure DevOps peut réduire votre usage d’internet si vous travaillez avec DevOps Server on-premise. Mais cela ne réduira pas votre usage du réseau local (et donc la consommation électrique de vos switchs). Hormis si vous utilisez des VM pour vos agents de builds et nom des conteneurs.

Sécurité

Un code mort peut être lié à une Web API, un web service ou toute autre solution qui peut être atteinte de l’extérieur de votre application (ou service). Par définition, un code mort n’est plus maintenu, car il n’est plus utile. Mais rien n’empêche celui-ci d’être fonctionnel. Celui-ci peut donc exposer de données ou permettre des actions dont les scénarios ne sont plus supportés (exemple : risque d’incohérence ou de corruption des données). Pire encore, il est probable que celui-ci ne respecte pas les règles de sécurité actuellement en vigueur au sein de votre entreprise.

C’est tout à fait le genre de faille que des pirates recherchent.

Un code mort peut donc représenter un risque pour votre application ou vos utilisateurs.

Les codes commentés

Le fait d’avoir des pans entiers de code commentés peut fortement nuire à la lisibilité du code. Je ne vous apprends rien. Mais il est des situations plus embarrassantes qui rendent l’IntelliSence de Visual Studio totalement instable. Cela ce produit entre autres, quand on commente une méthode ou une classe sans commenter sa documentation.

Je n’ai pas toujours clarifié la totalité des cas conduisant à un dysfonctionnement d’IntelliSence, je vous conseille donc de supprimer un code plutôt que de le commenter. Laissez votre repository faire son travail (git, ou autre). C’est à lui de maintenir l’historique de votre code. En aucun cas, ce n’est le travail de votre propre code ;).

Les classes et méthodes inutilisées

L’instanciation d’objet à partir de classes contenant du code mort peut avoir un impacte plus ou moins important sur la quantité de mémoire utilisée. Ceci n’est pas une surprise. Si un objet a des propriétés et méthodes inutiles, il occupe plus d’espace en RAM.

Seule une session de profilage vous permettra d’évaluer les dégâts. Mais pourquoi perdre du temps à quantifier un problème quand on sait comment l’éviter ?

Supprimez, supprimez, supprimez…

Le poids de livrables (EXE, DLL, Scripts…)

La présence de code mort conduit inévitablement à augmenter inutilement le poids des livrables. On retrouve alors les mêmes problèmes d’usages non justifiés que pour les dépendances inutiles (stockage, réseau, mémoire, durées).

En fonction de la quantité de code mort présente, cet impact peut sembler négligeable. Mais il n’est jamais nul. Quand on souhaite travailler sa sobriété numérique, il ne faut pas négliger les pistes qui demandent aussi peu de travail que la suppression du code mort.

Conclusion

Tuer une bonne fois pour toutes votre code mort. Ne cherchez pas à le garder cacher dans votre application. Vous améliorez ainsi la qualité de votre code, la vitesse à laquelle vous délivrerez des mises à jour. En prime, votre lutte contre le code mort pourra être mise en avant dans le cadre de votre politique de sobriété numérique.

"Elle est pas belle la vie ?"

Si un code peut vous sembler utile, profiter de votre repository (git ou autre). Il suffit de tagger proprement le dernier commit l’incluant avec un commentaire explicite que la fonctionnalité en question. Ou plus simplement, créez une branche d’archive.