Dette technique : le mot a de quoi faire peur...
Lorsque l'on parle d'application mobile ou de projet web chez TroisPointZéro, on préfère parler d'abord innovation, application métier ou solution collaborative... Mais la qualité reste au centre des préoccupations de nos équipes, et l'une de ses facettes est la maintenabilité dans le temps de l'environnement technique.
La dette technique pour les nuls
Quand vous livrez une application mobile ou un site web, dans un monde idéal le code est propre, commenté et censé suivre une architecture réfléchie et pérenne dans le temps. A mesure que le temps passe, certains facteurs vont venir compromettre la stabilité du code :
- correction de bugs
- évolutions fonctionnelles
- évolutions des bibliothèques utilisées dans le code
- évolutions du framework utilisé
- changement des développeurs intervenants sur le projet
Ces éléments rendent la maintenance du code plus complexe et plus chronophage : c'est la dette technique qui va peu à peu s'accumuler et venir réduire la productivité sur un projet. En réalité, la dette technique s'accumule dès la première ligne de code, de manière mécanique. Dans l'urgence, on ne prend pas toujours le temps de l'analyse et parfois c'est comme mettre un pansement sur une jambe de bois.
La dette technique pose donc un double problème : un entretien de plus en plus délicat, potentiellement générateur de bugs, ainsi qu'un coût de maintenance qui explose et qui peut rendre le projet commercialement insoutenable.
Bien entendu il y a des définitions beaucoup plus complètes que ces quelques mots d'introduction, voir des vrais débats sémantiques sur la dette technique, mais tenons-nous en là pour le moment. Qwant est votre ami pour creuser le concept :)
Mon code ressemble à la falaise d'Etretat ?
OK, on constate donc une sorte d'érosion dans la gestion technique du projet. C'est grave docteur ?
Réponse classique du Normand que je ne suis pas : oui et non.
L'entropie naturelle existe partout : un code va vieillir comme peut le faire une maison. Sans entretien, votre jolie petite bicoque va se dégrader de manière exponentielle jusqu'à ce qu'elle menace de s'effondrer et qu'elle nécessite de tout raser pour reprendre sur une base saine. Evidemment, si vous prenez le temps d'entretenir, de réparer, d'améliorer votre maison, elle gardera sa structure inviolée et pourra héberger pendant longtemps les enfants des enfants de vos enfants.
La bonne nouvelle c'est donc que rien n'est inéluctable et que la dette technique peut - doit - être anticipée afin de permettre la longévité du projet. Plus on attend et plus il sera compliqué d'intervenir et de minimiser ou combler les failles qui vont peu à peu apparaître.
Dette technique au fil du temps
Dans un premier temps, la refactorisation du code permet de s'assurer que le code reste cohérent dans son ensemble. C'est un processus continu qui permet de rapprocher les premières lignes du codes des dernières tapées pour éviter conflit, doublon ou incohérence.
Si le code n'a pas été refactorisé ou maintenu pendant quelques mois, il va falloir rapidement envisager une refonte partielle pour réduire la dette technique. La mise à jour des plugins appelés; bibliothèques utilisées, ou même du Framework, va nécessiter plus de travail qu'un simple réaménagement du code. Le contrôle des dépendances et la non-regression vont représenter une phase cruciale et non-négligeable en terme de temps et donc de coût.
Enfin, si le code a vieilli pendant plusieurs années sans maintenance particulière, la meilleure solution sera probablement une refonte complète en partant sur un framework plus moderne, ou en tout cas une version à jour. On repart donc de zéro ou presque, en espérant qu'une documentation fonctionnelle fournie et à jour avait été anticipée...
On sort la boîte à outils et on s'y met
Parfait : on a les symptômes et on a mis un nom sur la maladie. Maintenant, on la traite comment ?
Retour arrière sur les premières lignes de cet article : la qualité. Comme aime à le dire notre bien aimé CTO : concevoir un site web ou une application mobile c'est comme construire sa maison. On ne le fait pas sans plan, on ne le fait pas sans architecte, et on ne le fait pas dans n'importe quel ordre et de n'importe quelle manière.
Quelques pistes pour traiter la maladie, pas forcément dans un ordre logique :
Documenter l'architecture technique
Tout d'abord la phase d'architecture de la BDD et le choix des technologies doivent faire l'objet d'une formalisation. Cette première brique de la documentation est cruciale car elle décrit le squelette du projet et explicite l'origine des choix. Et pourquoi prendre un serveur Node, passer par une BDD ElasticSearch ou une couche d'abstraction d'API comme GraphQL ? Autant de questions qui ne trouveront peut-être plus de réponse claire 6 mois, 1 an ou 5 après la livraison du projet.
Il existe des solutions pour faciliter la documentation : typiquement on utilise le package hads en interne chez TPZ.
Normaliser le code
C'est le principe du design pattern qui nous est cher au sein de TroisPointZéro : suivre une nomenclature, une manière de coder. On adaptera bien sûr au framework, à la technologie, mais adopter une convention de nommage et une certaine philosophie dans la manière de produire du code permet une meilleure maintenabilité de celui-ci.
On peut aussi aller plus loin en travaillant en peer coding, c'est à dire en codant littéralement à deux en même temps. L'avantage est que l'on optimise deux fois plus le code. Le désavantage est que l'on occupe deux personnes simultanément sur la même portion de code... Pas évident :)
Commenter !!
Au risque de se lancer dans les poncifs, commenter son code est à la fois la base du développement et paradoxalement l'oubli le plus répandu. Le grand classique étant "je le ferai plus tard" sauf que dans un projet web ou mobile, on trouve rarement du temps à la fin mais plutôt une pression des délais qui n'incite pas à la refactorisation et à un commentaire.
Tests unitaires, tests end to end, tests automatisés...
La base : le test unitaire. On développe, on teste, on livre.
Mais ça n'est pas suffisant, des conflits peuvent se produire entre deux composants apparemment indépendants. Les tests end to end (de bout en bout) permettent de vérifier la non-regression : qu'un composant qui fonctionnait très bien jusque là ne se mette pas à bugger. Et si l'on peut automatiser tout cela dans une intégration continue, c'est encore mieux !
Choisir son framework en connaissance de cause
C'est de notoriété publique que certains frameworks sont plus buggés que d'autre. On entend par là que leurs développeurs ont laissé courir la dette technique et que ça se paye forcément à un moment ou à un autre. Il existe une mesure de la dette technique basée sur le nombre d'heures / jours de travail qui seraient nécessaires pour réaligner proprement tout le code.
En préparant cet article, je suis tombé sur cette illustration qui certes date un peu, mais qui illustre plutôt bien l'importance du choix du framework. Ce qui ne veut pas dire qu'il ne faut pas utiliser Wordpress mais simplement qu'il faut être prêt à accepter les risques (bugs, failles de sécurité) liées à la dette technique.
Le mieux est l'ennemi du bien : le rien aussi
Evidemment en me faisant le chantre de la documentation, du commentaire et de la qualité en général, je reste bien conscient que tout cela a un coût. La grande inconnue est à partir de quel moment maintenir le code sera plus coûteux que d'en produire de nouveau.
Si ne rien faire serait évidemment suicidaire, il n'est pas non plus nécessaire d'en faire trop. Le contexte, les urgences, la pression commerciale jouent malheureusement beaucoup sur le temps consacré à la maintenance du code. Mais en travaillant à minima sa documentation technique (archi), en commentant son code et en automatisant le contrôle qualité, on peut déjà minimiser la dette technique et éviter le pire.
