Adoption d’une nouvelle technologie et migration sans douleur

J’ai personnellement, comme beaucoup je crois, un rapport ambigu à React. D’une part, il y a son lien avec Facebook, la toxicité d’une partie de sa communauté et sa réputation pas toujours usurpée d’usine à gaz. D’autre part, bien employée, je pense que c’est la technologie la plus efficace pour le développement d’applications complexes avec laquelle j’ai pu travailler en quinze ans de web.

Il y a quelques mois, en rejoignant une nouvelle équipe en tant que développeur front, j’ai proposé un plan de migration vers React pour l’application dont nous nous occupons, qui souffrait des symptômes d’un prototype mûri trop vite. J’ai tenté d’importer le meilleur des méthodes pratiquées sur mon projet précédent, pour lequel j’avais travaillé sur une longue migration de Backbone/Marionette à React.

Dans les deux cas, il s’agit de migrations progressives, par opposition à des réécritures depuis zéro, ce qui a de nombreux avantages :

• assurer la continuité du service pour ses utilisateurs⋅rices,
• ne pas fractionner le travail de développement et de maintenance,
• permettre de doser et de mesurer facilement l’avancement de la migration,
• introduire progressivement de nouvelles pratiques de développement.

Ce dernier point est fondamental. Les enjeux d’une migration ne sont pas seulement techniques, ils sont également humains. Et les migrations sont des périodes compliquées pour la vie d’une équipe. En apportant des bouleversements durables dans des pratiques connues, elles sont forcément une charge de travail supplémentaire et peuvent être perçues comme une remise en question de compétences établies.

Cela fait partie du métier de développeur⋅se de savoir s’adapter aux changements. Mais tout le monde n’a pas le même niveau d’expérience ou d’implication dans le projet, la même énergie ou le même temps disponibles, la même appétence pour la nouveauté ou la même résistance à la JavaScript fatigue. Le rejet a priori du changement est possible et compréhensible.

Cela est encore pire si le choix vient de l’extérieur ou est imposé unilatéralement. Même dans les équipes sans structure hiérarchique explicite, qui appliquent des processus de décision collectifs, des dynamiques de pouvoir existent. Les principales orientations techniques sont souvent initiées par les développeurs⋅ses les plus expérimenté⋅e⋅s. C’est leur rôle, c’est peut-être le vôtre, mais celui-ci ne saurait être séparé de la responsabilité de construire l’adhésion collective de l’équipe et d’amener chacun de ses membres vers davantage d’autonomie et d’expérience.

Plus qu’un challenge technique, la problématique de la migration est bien l’appropriation d’un nouveau choix technologique par tou⋅te⋅s et la montée en compétence de tou⋅te⋅s. Dans cette démarche, voici quelques conseils méthodologiques, parfois illustrés d’exemples liés à React mais qui se veulent généralisables à tout autre contexte.

Préparer

Si le principe de la migration est validé par toute l’équipe, il reste un travail en amont à faire pour s’assurer qu’elle se fera dans de bonnes conditions.

La première priorité devrait être de s’assurer que vous avez des outils de non-régression. Pour une migration de l’interface de votre application, les tests unitaires seront probablement peu sollicités, en revanche des tests de plus haut niveau simulant le comportement d’un⋅e véritable utilisateur⋅rice prennent tout leur sens. Ils seront l’outil le plus précieux pour garantir que le changement progressif de technologie sous-jacente n’a pas de conséquences visibles et donneront confiance aux développeurs⋅ses pour avancer. Si vous n’avez pas encore de tests fonctionnels, c’est le meilleur moment pour commencer, en veillant à tester au moins vos fonctionnalités critiques avant de les migrer.

L’accroissement du poids d’une application web est une forme de régression en elle-même. C’est un compromis qui peut se justifier, mais votre nouveau choix technique sera peut-être plus lourd que l’ancien. Et dans tous les cas, la cohabitation de deux technologies pendant la migration apportera un surplus temporaire au poids de votre application. Il faut pouvoir mesurer cet impact, pour éventuellement adopter des stratégies pour le limiter, par exemple avec une meilleure séparation de l’application en bundles. On peut utiliser périodiquement un outil tel que Webpack Bundle Analyzer ou mieux encore, mettre en place des scripts automatiques de comparaison de taille avec des seuils d’alerte.

C’est également le bon moment pour installer ou mettre à jour certains outils de votre environnement de développement qui ne sont pas liés particulièrement à la migration mais qui amélioreront le confort des développeurs⋅ses. Je pense à des choses comme un linter, du live reload, etc.
Ne sous-estimez pas cette tâche et n’allez pas trop vite en introduisant de nouveaux outils, au risque d’embrouiller des gens qui ne les connaissent pas avant même le début de la migration. Faites-en au contraire une occasion pour chacun⋅e de découvrir de nouvelles pratiques.

Vous pouvez également chercher à corriger certains problèmes de votre code qui pourraient rendre la migration encombrée par beaucoup de refactorisation. Par exemple, en restant dans le cadre de votre framework historique, faites émerger des composants génériques élémentaires ou simplifiez des styles devenus trop spécifiques. Il y a toutefois un risque de sur-anticiper et de faire du travail qui sera défait très vite. Limitez-vous aux résolutions les plus évidentes et qui auront un impact significatif sur le confort de développement.

Une dernière étape de préparation indispensable est de constituer une documentation spécifique à la migration et de la rattacher au projet. Pour commencer, vous pouvez y agréger les éléments suivants :

• un rappel de la démarche : pourquoi la migration est nécessaire, son périmètre, etc. ;
• des ressources liées à la technologie cible : documentation officielle, article pertinent, etc. ;
• des recettes pour réaliser la conversion d’un module de l’application : des indications de nommage, de pratiques de code, d’écriture de tests, etc.

Cette documentation permettra le partage de la connaissance sur le sujet et pourra être enrichie par tou⋅te⋅s tout du long.

Poursuivre

La migration pourra être considérée terminée quand l’ancienne technologie diagnostiquée à l’origine des problèmes et les artifices techniques de cohabitation seront supprimés du code.

Et cela peut prendre du temps. C’est un des risques de cette approche progressive : si la méthodologie mise en place rend la cohabitation des deux technologies relativement confortable, la migration pourra s’éterniser. Cela peut ne pas être gênant ou au contraire empêcher d’exploiter les avantages du nouvel outil. Par exemple, dans mon projet précédent, un routeur d’application en Backbone a longtemps persisté, ce qui nous empêchait de généraliser le SSR de React au site entier.

Pour éviter ce phénomène de stagnation de la migration, il peut être utile de mettre « un coup de boost » pour réellement la terminer, par exemple en dédiant des sprints exceptionnels à cette problématique purement technique.

Mais un projet en développement continu est par définition en perpétuel chantier. Les problématiques reportées précédemment pourront être traitées une par une, portées par les personnes qui les auront soulevées pendant la migration. Le potentiel de la nouvelle base technique pourra être exploité… et nul doute que de nouveaux problèmes surviendront rapidement !

L’important est qu’à ce stade, la connaissance aura été diffusée. Chaque membre de l’équipe aura pu s’approprier la nouvelle technologie de manière opérationnelle et aura gagné en expérience.