Code Refactoring en continu : indispensable pour faire évoluer sa plateforme

J’avais envie de vous parler aujourd’hui du Code Refactoring en continu car à mes yeux, c’est une étape importante pour les éditeurs de logiciels, voire indispensable, pour garantir le bon fonctionnement et la pérennité d’un produit digital. Inclure le refactoring de code continu dans sa routine, c’est s’éviter des complications en cascade, telles que :

• Perte de productivité.

• Difficulté à recruter ou à garder des développeurs.

• Anomalies récurrentes, instabilité.

• Mécontentement des utilisateurs.

Modifier au fur et à mesure son code, c’est garder un logiciel performant moins soumis aux anomalies. Contactez-nous si vous avez des questions !

Contrairement à ce que l’on pourrait penser, le refactoring n’a rien de sorcier, à condition qu’on le fasse bien et régulièrement ! À la longue, votre logiciel gagnera en performance, vos utilisateurs seront heureux (et recommanderont sûrement votre outil à d’autres) et vous n’aurez pas de difficulté à recruter des pépites de l’IT pour agrandir vos équipes et travailler à l’amélioration de votre produit.

Avant d’entrer dans le vif du sujet et de vous expliquer plus en détails les bénéfices et l’intérêt du refactoring continu d’un point de vue éditeur de logiciel, j’aimerais citer Martin Fowler, le gourou en la matière et qui résume simplement mais parfaitement l’intérêt de la chose :

« Each transformation (called a « refactoring ») does little, but a sequence of these transformations can produce a significant restructuring. »

Refactoring continu : de quoi s’agit-il ?

Le refactoring continu consiste à adapter et modifier au fur et à mesure son code afin d’améliorer sa structure, sa lisibilité et sa sécurité dans le but notamment de faciliter la maintenance mais sans modifier ses fonctionnalités.

Tous les logiciels ne sont pas forcément concernés. Par exemple, si une entreprise développe un logiciel pour un besoin interne ponctuel qui n’a pas vocation à être utilisé dans la durée, le refactoring continu (montées de versions, réarchitecture lors du développement de petites évolutions…) a beaucoup moins de sens.

En revanche, si le logiciel est destiné à être commercialisé et enrichi et ce sur le long terme, le refactoring en continu est primordial.

Le refactoring continu pourrait être comparé à l’entretien d’une maison : les changements, petits mais réguliers, permettent de garder une maison saine, agréable à vivre tout en contrôlant les dépenses. Il en est de même pour le code de votre logiciel qui restera performant et agréable à utiliser par vos clients si vous faites un nettoyage régulier plutôt que de le laisser prendre la poussière !

Le refactoring continu doit devenir une bonne habitude

Le code refactoring est loin d’être une opération à des fins esthétiques ou pour assouvir les TOC de Jean-Michel, le dév du 3e qui ne supporte pas de voir un code écrit différemment du sien. Il apporte de nombreux avantages qui ne seront que bénéfiques à la croissance du produit digital.

Si le refactoring continu doit être mis en place dès les premières itérations du logiciel, il y a exception dans le cas d’un POC (Proof Of Concept). Qu’il s’agisse d’une startup ou d’une entreprise bien installée, le POC permet de tester le produit avant de l’industrialiser et là, la vitesse prime le plus souvent sur la qualité, l’objectif étant de tester le marché au plus tôt.

Néanmoins, dès les premiers résultats des objectifs obtenus, il est important de s’aménager du temps pour revoir et améliorer le produit afin de démarrer sur des bases solides.

Voici les principaux avantages que je vois dans le refactoring :

Mieux vaut refactorer en continu que redévelopper from scratch

Avec un refactoring continu qui adopte une approche progressive, le produit reste utilisable, contrairement à un logiciel qui doit être entièrement réarchitecturé, voire redéveloppé. Comme je l’ai dit, je pense que c’est la meilleure option pour pérenniser un produit digital mais ce n’est pas une solution miracle. Elle demande du temps et des compétences, quitte à reporter le développement de certaines nouvelles fonctionnalités.

Si je peux donner un conseil sur l’organisation, ce serait de garder un temps au refactoring de code dans chaque itération et quand c’est nécessaire lui réserver une itération.

Quels sont les risques à ne pas faire du refactoring continu ?

Je vais reprendre l’exemple de la maison : si on la construit vite, dans l’immédiat on se retrouve avec un produit satisfaisant, tout de suite fonctionnel et en plus de ça, livrer dans les temps. Mais en cas d’accident, comme un dégât des eaux par exemple, on se rend compte que ce n’est pas une fuite à colmater mais toutes les canalisations à refaire. Résultat : les travaux sont bien plus chers et prennent plus de temps que prévu.

C’est pareil pour le logiciel : sans refactoring continu ce dernier va accumuler les malfaçons, l’utilisateur final va se retrouver avec un produit qui évoluera difficilement et avec des régressions récurrentes.

Le mécontentement se fera également ressentir auprès de vos équipes de développeurs : avouez que travailler sur des technologies que plus personne n’utilise n’a rien de valorisant et que passer sa journée à réparer des anomalies n’a rien de très motivant. Alors qu’ils seront bien plus motivés et feront preuve d’innovation si vous leur proposez un produit qui adopte les versions les plus récentes des technologies.

Ajoutons à cela un problème d’incompatibilité grandissant, et votre produit digital ne pourra plus être commercialisé.

Attention aux développeurs commando !

S’il n’y a pas forcément besoin de compétences techniques spécifiques pour faire du refactoring, je préfère vous mettre en garde contre les développeurs qui sont en mode
« commando ». J’entends par là des personnes qui ont une vision à court terme et qui veulent développer vite.

C’est notamment le cas de certains freelances (attention, je ne veux pas en faire une généralité) dont l’objectif est de développer au plus vite (surtout s’ils sont au forfait) et passer à un autre projet. Pour éviter les mauvaises surprises, il faut s’assurer que le développeur ait une vision sur le long terme ainsi que des notions d’architecture.

Quelques conseils pour réussir son code refactoring

Le mieux est bien entendu de mettre en place une intégration continue avec des tests unitaires afin de constater s’il y a des régressions ou non. Dans le cas d’une organisation Agile, le refactoring doit être intégré à chaque sprint. Il est quasi-impossible de généraliser le temps que prendra un refactoring continu mais dédier 10% de son temps par sprint au refactoring me semble suffisant et raisonnable.

Je vous déconseille de vous lancer sur une technologie qui n’a pas encore été éprouvée, tout simplement par manque de retour et de fiabilité. Exception faite pour les startups ou pour les POCs qui, par leur caractère jeune et innovant, peuvent se diriger vers de nouvelles technologies avec un risque de perte moindre.

On peut affirmer qu’un refactoring réussi est un refactoring dont le code est simple et lisible. Afin de garder un code aussi simple que possible, mieux vaut :

Approche TDD, tests de performance, mesure de la qualité du code

Les tests unitaires sont nécessaires pour tout refactoring afin de s’assurer qu’il n’entraîne pas de régressions. De même, l’implémentation de tests de performance est intéressante à mettre en place pour s’assurer que le refactoring n’a pas d’impact négatif sur les performances.

Les outils de mesure de la qualité du code tel que Sonar sont des outils à considérer dans son plan de refactoring continu car ils permettent de définir des règles de coding, d’analyser la méthode et si besoin, de refuser le code qui ne respecte pas les règles. Le même type d’outil peut également être mis en place au sein de l’environnement d’intégration continue pour la mesure de la sécurité.

Pentalog et le code refactoring façon Agile

Nous privilégions une approche Agile qui est intégrée dans l’ADN de Pentalog. Avant de démarrer tout projet, nous avons comme prérequis d’analyser la qualité du code et de mesurer la dette technique, que ce soit avec vos outils ou avec les nôtres, afin d’évaluer et orienter au mieux le projet.

Nous proposons également les personnes qualifiées, que ce soit par le recrutement ou la constitution d’une équipe dédiée.

Pour conclure, retenons que plus tôt le refactoring est assimilé, moins grande sera la dette technique. Le monde du digital est en perpétuelle évolution, il est logique que votre produit suive le rythme aussi non ? Pour cela, adoptez une cadence qui est le vôtre grâce au refactoring continu au lieu de le subir quand il sera trop tard.

Vous avez d’autres questions concernant le Refactoring Continu ? N’hésitez pas à me contacter !

Consultez aussi :

Méthodologie Agile : 4 manières de configurer la réussite de votre projet

La transformation digitale passe par l’agilité. 8 conseils pour se lancer

Cas pratique Rue de la Paye : urbaniser son SI pour accélérer sa croissance