Qui porte la responsabilité ? Transition technologique / Refactoring

Bonsoir,

J’ai récemment rejoint une entreprise française en tant que Tech Lead pour la première fois. Jusqu’à présent, l’équipe était composée d’un développeur junior et d’un Product Owner.

Le développeur junior, travaillant seul et sans supervision, a fait un choix technologique de son propre chef : NestJS et VueJS. Il a développé sans bien maîtriser ces frameworks, ce qui a abouti à un résultat fonctionnel (qui convient donc au PO), mais qui reste largement perfectible d’un point de vue technique.

Étant au tout début du projet et souhaitant partir sur des bases solides, j’aimerais refondre la codebase existante (qui ne contient que 7 fichiers légers) en utilisant Java Spring ou C# ASP.NET Core (je n’ai pas encore pris de décision à ce sujet).

Je précise que le développeur junior quittera notre équipe à la fin du mois, ce qui me rend encore plus hésitant à l’idée de conserver la codebase actuelle, surtout sachant que je devrai continuer à développer dessus.

Cependant, puisque le produit fonctionne, le PO est réticent à l’idée d’investir du temps et du budget pour cela, d’autant plus qu’il s’agit d’un outil interne à l’équipe.

Qu’en pensez-vous ? Devrais-je passer à autre chose et ajouter la brique demandée à l’existant, ou prendre le temps de repartir sur des bases saines ?

(J’ai conscience que cette situation se présente souvent avec des juniors, l’envie de tout refaire sur un coup de tête, mais ma décision est vraiment motivée par des éléments factuels : seul développeur de l’équipe qui part, codebase à son tout début, et d’expérience, les langages dynamiquement typés font perdre beaucoup de temps au débogage malgré un temps de développement plus rapide. Je trouve que cela manque de garanties.)

Hello,

Une première solution pourrait être d’ajouter TypeScript pour typer un minimum : même si ce n’est que du sucre syntaxique, ça évitera déjà pas mal d’erreurs.

Autrement, si tu veux refacto, normalement c’est dans tes capacités de tech lead, mais ça implique de pas sortir de fonctionnel le temps de cette refacto et de changer le type de profils pouvant être recrutés pour la suite (JS étant de plus en plus courant et "hype" sur le marché du Web, comparé à des technos plus anciennes comme celles que tu cites).

La meilleure méthode étant probablement d’estimer le plus précisément possible l’effort de refacto et de le comparer au temps qu’elle peut faire économiser sur la durée de vie estimée du projet.

En tout cas, passer son temps à changer de techno ça plait rarement aux décideurs, et c’est très souvent causé par des caprices de devs sans trop prendre en compte les impératifs business de l’entreprise (qui doit généralement rester rentable alors que les développeurs sont une grosse source de coûts).

Pour te donner un exemple concret tiré de mon expérience, en arrivant dans mon ancienne boîte au même poste, le projet en cours était non seulement avec un framework front que je supporte pas (React pour ne pas le citer), utilisait du CSS-in-JS (l’opposé des standards Web des 20 dernières années) et MUI (une grosse lib de composants dont les styles étaient écrasés à la main quasiment partout pour donner une soupe indigeste et souvent répétitive), mais il avait hérité de plusieurs changements de direction du projet (le fonctionnel et le design avaient changé, mais la base de code était restée la même tout du long).

Malgré toutes mes appréhensions en amont j’y suis allé par étapes, sans tout dégager : React est resté, par contre le CSS est passé dans des fichiers dédiés rapidement pour rendre le code déjà plus simple à lire et maintenir. Ensuite les composants ont progressivement été rendus indépendants de MUI : les nouveaux composants avaient interdiction de l’utiliser, les anciens restant à migrer au fur et à mesure des besoins de refacto.

Ça a donné une migration en douceur qui non seulement a facilité l’acceptation par l’équipe de dev (qui étant assez junior n’en voyait pas l’intérêt de prime abord) qui a au passage pu apprendre et découvrir l’intérêt de ces changements (qu’ils ont ensuite poussés d’eux-mêmes ailleurs), mais les décideurs (CTO et dirigeants) ont ainsi moins eu l’impression de payer une équipe à ne pas produire : on a faisait ça entre deux fonctionnalités, par morceaux.

Logiquement ça a donné des situations pas toujours idéales avec un peu de dette technique à gérer par endroits, mais au final la décision a été acceptée par tous et le résultat 2 ans plus tard à mon départ était que les derniers arrivés (deux devs seniors) nous ont félicité de la propreté et clarté du code : malgré des restes de cette transition pas totalement terminée, le code était simple à comprendre et sur les bons rails, il restait juste à terminer quelques éléments sur lesquels on avait pas encore eu à agir.

Merci pour ton retour que je partage également.

Je suis toujours en réflexion et le PO ne me répond pas (peut être qu’il cherche à ce que je prenne moi même la bonne décision)

D’une manière générale, de mon expérience et au doigt mouillé, réécrire un projet de zéro est très rarement intéressant, même si ça donne très envie. Le principal risque, c’est d’avoir quelque chose qui fonctionnait (mal) et de le remplacer par quelque chose qui ne fonctionne plus du tout – des régressions, donc, qui sont très mal acceptées par les utilisateurs. Les cas que j’ai croisé sont :

Si la solution technologique utilisée n’est plus supportée du tout, tu n’as pas le choix et c’est l’un des rares cas qui justifie presque à coup sûr ce genre de manœuvre. Attention : j’insiste sur l’absence totale de support. Le fait qu’un outil soit vieux et plus du tout à la mode n’est jamais un argument, surtout si le code est fonctionnel. Par exemple, Pro*C est antique et horrible selon tous les standards actuels, mais toujours supporté par Oracle.

Sont des arguments en faveur d’une réécriture complète, sans qu’aucun d’eux ne suffise seul :

• Le projet est fonctionnellement cassé – il y a donc peu de risque de régression.
  Bien vérifier qu’on a des spécifications complètes avant de commencer la réécriture, puisqu’il n’y a pas de « version actuelle » pouvant faire foi.
• La technologie n’est pas maitrisée dans l’entreprise (par exemple, c’est le seul projet Perl et plus personne ne sait le maitriser).
  À croiser avec le cout de montée en compétence et/ou d’embauche de personnes dans cette technologie.
• La technologie est d’évidence inadaptée au projet – ça doit être facile de sortir une métrique qui le montre.

Et c’est à peu près tout ce que j’ai croisé. En fait dans la majorité des cas, c’est plus intéressant de nettoyer le code que de le réécrire, et ce d’autant plus que la version en cours est fonctionnelle (dans le sens où elle rends le service qu’elle doit rendre, même de façon inefficace).

Quand je dis « nettoyer », ça peut aller très loin si nécessaire : changement de framework, de base de données, d’API… mais toujours en partant du code d’origine.

C’est d’autant plus facile que le code a été correctement architecturé pour séparer les règles métier de tout l’interfaçage technique ; dans ce cas tu peux « assez facilement » garder tes règles métier et changer tout l’outillage autour (j’ai fait de la transformation de Spring Boot à Quarkus comme ça). Les architectures actuelles (exemple : hexagonal architecture, onion architecture, clean architecture…) sont assez efficaces de ce point de vue.

Une bonne technique de nettoyage, c’est d’abord de rajouter des tests fonctionnels sur tout ce qui peut l’être sans trop créer de couplage. Ça permet de se lancer dans des réusinages sans trop craindre les régressions.

@Halfmoon ce qui m’étonne dans ton message d’origine, c’est que tu parles d’un projet en NestJS et VueJS donc à priori une technologie front, puis tu dit vouloir les remplacer par Java Spring ou C# ASP.NET Core qui sont des technologies back.

@Spacefox NestJS (à ne pas confondre avec Next.js) est bien un framework back Node.js

Sinon +1 pour les arguments avancés, à moins que le projet soit encore très jeune et puisse être donc être entièrement refait rapidement, il y a peu d’avantages à recommencer de zéro.

Autant pour moi, j’ai confondu ! (j’ai toujours autant de mal avec le concept de « JS en back » cela dit, je sais pas, mettez au moins du typescript !)

A priori autant NestJs que Vuejs (la version 3) sont déjà écrits en typescript, donc je pense bien que c’est du typage statique