Le code mort est le code devenu inutile car plus jamais utilisé dans une application.

Pourquoi du code mort ? Lors des opérations de maintenance correctives ou évolutives les développeurs (disciplinés) créent assez spontanément une nouvelle version de leur code … mais n’élimine que trop (très) peu souvent le code devenu inutile. Au mieux est-il commenté, ce qui finira de toutes façons par constituer une gêne. Autre phénomène tout aussi fréquent : la désynchronisation des commentaires d’avec le code (ou comment apparaissent des commentaires eux-mêmes morts).

Le code mort rend le code utile plus confus et plus complexe, avec comme conséquence immédiate une augmentation des coûts de maintenance.

Selon certaines études le pourcentage de code mort se situerait entre 10 et 15% pour les applications de 5 ans d’âge, et entre 30 et 40% pour les applications au delà de 20 ans d’âge.

D’autres études situent le coût d’une ligne de code autour de 3 à 4 euros, tests compris. L’éradication du code mort peut donc constituer une belle économie sur le budget de maintenance.

L’intérêt pour l’éradication du code mort est encore plus vrai et immédiat dans le cas d’une migration. Confronté par exemple à l’abandon de son mainframe (voulu ou obligé) toute organisation aurait intérêt à se poser la question de l’opportunité d’une telle opération avant de se lancer dans la migration de son code. Que ce soit par la voie d’une traduction automatisée ou par réécriture.

Dans le premier cas la facturation se faisant généralement à la ligne de code l’explication est simple. Et à supposer que la balance entre la réduction du coût de la traduction et le coût de l’éradication du code mort ne soit pas positive , ou pas assez, la justification peut être facilement trouvée dans la volonté de profiter du moment de la migration pour réduire la dette technique (dont l’éradication du code mort est une composante importante).

Dans le second cas, la qualité des documentations étant habituellement ce que nous savons tous, éliminer le code mort ne pourra être que profitable lorsqu’il s’agit de “plonger” dans le code pour en rédécouvrir la finalité. Pas de temps perdu à la redécouverte de code inutile, et pas de parasitage sur la compréhension du code utile par le code inutile.

Une opération d’éradication du code mort se doit d’être automatisée. Des outils existent pour ce faire, tel que l’outil Kris de la firme Telebig, spécialisée dans la migration de systèmes legacy. Il est possible de télécharger une version gratuite qui vous permet de situer votre code mort mais pas de l’éliminer. Il semble que la solution devrait à terme être rendue disponible en mode SaaS.

L’éradication du code mort ? Un outil de réduction des coûts, de gestion de la qualité et une source d’économie sans doute importante dans une opération de migration.

Het beheersen van complexiteit wordt steeds belangrijker in het huidige IT landschap. In een poging om de complexiteit te beheersen, kiezen vele bedrijven voor het pad van “standaardisatie”, bijvoorbeeld  op vlak van gebruikte softwares of middlewareplatformen. Hoewel standaardisatie een manier is tot simplificatie, mag de strategie niet beperkt worden tot één logisch niveau omdat dit de complexiteit kan verhogen ipv. te verlagen. Bovendien worden bedrijven geconfronteerd met een fundamenteel conflict, ten gevolge van de onstopbare technologische vooruitgang :

Vernieuwing vs. Beheersing

In deze blogpost pleit ik dan ook voor een verticaal-georiënteerde standaardisatie over de gehele stack hardware-OS-middleware-software, rekening houdend met zowel vernieuwing als beheersing.   Noodzakelijkerwijs zal deze visie voor sommige lagen een destandaardisatie inhouden.

Standaardisatie kan de complexiteit verhogen

Samenspraak tussen de verschillende lagen in de stack (bv. OS, middleware, software) is noodzakelijk,omdat de beperking van de keuzes op een bepaald niveau (bv. OS), de complexiteit op een hoger niveau aanzienlijk kan verhogen.  De realiteit is nu eenmaal dat bepaalde technologieën beter draaien en eenvoudiger integreren op een specifiek platform.

Behalve dat bij standaardisatie het luik “configuratie” over het hoofd gezien wordt (ook configuraties moeten gestandaardiseerd worden — het beheersen van configuraties is meestal moeilijker dan het beheersen van de software zelf), heeft standaardisatie op één bepaald logisch niveau tot gevolg dat de complexiteit op een hoger niveau toeneemt.

Stel bv. dat een bedrijf qua Web Server enkel IIS toelaat.  Stabiele Out-Of-The-Box oplossingen zoals Drupal op een LAMP stack, worden hierdoor onnodig complex gemaakt omdat Drupal ontplooid wordt op een platform of in een configuratie waar het oorspronkelijk niet voor gebouwd is.  Best-of-breed aanpakken, waarbij “de juiste aanpak” wordt gebruikt voor een specifiek probleem, worden hierdoor dus onmogelijk, waardoor we dus komen tot suboptimale oplossingen, die vaak ook nog complexer zijn.

Destandaardisatie kan dus de complexiteit verlagen, omdat de stack in zijn geheel eenvoudiger wordt.

Last but not least speelt er een cultureel aspect: met het steeds hoger tempo van technologische innovatie,is het misschien beter om werknemers deze realiteit te laten omarmen, eerder dan ze er van af te schermen?