Refactoring : éviter l'effet tunnel

Quand une voiture s'engouffre dans un tunnel, l'observateur extérieur ne sait rien de sa position tant que la voiture n'est pas ressortie. Cet "effet tunnel" représente une difficulté bien connue dans le domaine de la programmation en général et du refactoring en particulier. On peut le résumer en une phrase : tant que tout n'est pas fait, c'est comme si rien n'était fait.

Dans la vie de tous les jours, c'est Lucas qui prend en charge le développement d'une nouvelle fonctionnalité. 3 semaines de travail estimé, Lucas se met au travail. Fort bien (en fait non, nous verrons pourquoi). En tant que manager, vous venez régulièrement aux nouvelles, mais les réponses de Lucas vous paraissent à chaque fois un peu plus nébuleuses :

Je dois au préalable refactorer le state Redux parce qu'il est nesté et ça ne marche plus pour la nouvelle feature, il faut un state normalisé pour pouvoir travailler.

En attendant, rien n'est en production.

C'est un risque évident pour votre santé mentale et celle de Lucas ; c'est aussi le risque que le travail prenne plus de temps qu'il n'en faudrait (Loi de Parkinson : le travail s'étale naturellement de façon à occuper tout le temps disponible pour son achèvement), mais c'est surtout que vous êtes totalement exposé aux aléas de la vie en entreprise.

En effet, au moindre changement de priorité ou cut budgétaire, le travail déjà réalisé risque grandement d'être perdu. Rien n'est prêt à passer en production, ce qui a été fait se trouve sur une branche qui, chaque jour, va diverger un peu plus de main et ne pourra plus être mergée.

Vous l'avez compris, plutôt qu'un énorme développement atomique, vous seriez bien inspiré de procéder à une multitude de petits développements et de les "pousser" en production au fur et à mesure. C'est bien pour ça (entre autres) qu'on a inventé les user stories.

Mais les user stories, c'est pour les nouvelles fonctionnalités. Comment faire dans un contexte de refactoring ?

Le refactoring, c'est toujours compliqué. On touche aux fondations, à des aspects structurants de l'application. Il est fréquent qu'un refactoring dure des semaines, voire des mois ou même des années dans le cas de refontes totales. Encore une fois, créer une branche de refactoring n'est pas une option, car pendant ce temps de nouvelles fonctionnalités arrivent sur "main". Elles sont difficilement réintégrables car posées sur des fondations obsolètes.

Outre la Méthode Mikado, que nous avions déjà évoquée, votre bouée de sauvetage sera ici le Pattern Strangler Fig. Son principe : faire coexister l'ancien et le nouveau.

Pour cela, vous aurez besoin d'une façade, dont le rôle sera d'assurer le maintien du contrat qui régit les interactions avec le monde extérieur. Et derrière la façade, à l'insu des regards, on remplace progressivement l'ancien par le nouveau.

Le refactoring qu'évoquait Lucas pourrait justement se traduire ainsi :

• Création "à côté" de la structure du nouveau state (reducers, sélecteurs)
• Transfert une à une des données de l'ancien vers le nouveau state
• Durant tout ce temps, les actions + signature des sélecteurs sont restées identiques : l'API du state n'a pas changé.

Ce pattern est particulièrement utile dans les chantiers de modularisation, lorsqu'on "casse le monolithe". Un travail de titans, que le pattern strangler fig ramène à la portée des humains.