Votre équipe ne connaît (déjà) pas le code de l'application qu'elle maintient

Quand j’ai commencé ma carrière¹ en SSII, mes chefs m’ont fait faire plusieurs interventions de quelques semaines, pour ajouter des fonctionnalités ou corriger des bugs, sur des applications qui existaient depuis des années.

Quelques années plus tard, on continuait à me solliciter de temps en temps pour des interventions “en mode pompier” : quelques heures à quelques jours de dépannage² ou de conseil³, généralement sur des projets que je n’avais jamais vu avant.

Job suivant, chez un éditeur cette fois, où je faisais partie d’une équipe qui maintenait des logiciels qui évoluaient depuis des années — et qui payaient les salaires de tous les employés de l’entreprise. Mes premières tâches — et mes tâches les plus fréquentes pendant plus d’un an — étaient de développer un nouvel écran dans un logiciel existant, ou d’ajouter un nouveau bloc sur un écran existant, ou même de corriger un bug “quelque part”.

Développer une nouvelle application from scratch ? Et bien, même si mon équipe a développé deux applications pendant mes deux ans dans cette entreprise, ce n’était jamais vraiment from scratch : nous réutilisions systématiquement des composants partagés avec les autres logiciels⁴.

Sans surprise, pareil pour les jobs suivants : des logiciels qui existaient, de la maintenance évolutive et corrective — et, bien sûr, quelques nouvelles APIs ou applications ici et là.

En allant plus loin, même, une question pour vous qui me lisez : fouiller dans le code d’une bibliothèque partagée open-source, peut-être parce que vous pensez avoir rencontré un bug, ça ne vous arrive jamais ?

Bref, en tant que développeur, j’ai toujours eu l’habitude d’entrer dans du code que je ne connais pas. C’est même, pour beaucoup d’entre nous, le gros du job.

Et les cas de “je connais très bien le code de l’appli et je sais exactement ce qu’il se passe” ont toujours plus été pour moi l’exception — bienvenue certes — que la règle.

Bien sûr, entre temps, j’ai aussi eu la chance d’être parmi les premiers⁵ à intervenir sur des projets qui ont duré quelques années et qui sont pour certains montés à plus de 20 développeurs / développeuses intervenant sur la même base de code.

Ça voulait dire du code écrit from scratch (modulo framework / CMS), donc on aurait pu penser qu’il soit bien connu du développeur… Mais nous étions deux développeurs. Puis trois, puis quatre, puis cinq… Puis une vingtaine sur certains projets. Donc, au final, la majorité du code était écrit par d’autres que moi.

Oh ! Aussi… À l’époque, les revues de code et le pair-programming, ça n’existait pas. Les tests automatisés non plus. Ça coutait trop cher. Du moins, en SSII.

Quand je parle de tout ça à certains collègues aujourd’hui, ils et elles me répondent⁶ qu’ils travaillent en équipe et donc “l’équipe connait le code de son projet”.

Mais même pour un logiciel écrit ou maintenu par une équipe, je doute que l’équipe entière le connaisse. Oui, des pratiques et conventions sont partagées par tous les membres de l’équipe, OK. Mais quand Dev A qui a bossé sur une fonctionnalité n’est pas là, je suis quasiment sûr que Dev  B et Dev C ne connaissent pas le code correspondant et vont devoir plonger dedans comme s’il avait été écrit par quelqu’un d’autre — puisque c’est le cas⁷.

Et puis, même quand un logiciel est développé ou maintenu par une équipe :

• Quelles équipes font réellement de la passation de connaissances pour que plusieurs membres de l’équipes connaissent chaque partie du logiciel ? Au moment des congés ? Des départs prévus ? Des arrêts maladie ? Au quotidien ?
• Quand une partie d’un logiciel n’est pas touchée par l’équipe pendant six mois, qui se souvient des détails de comment elle fonctionne ? Votre équipe fait-elle régulièrement des sessions pour se rafraichir la mémoire sur les composants qu’elle maintient sans les modifier tous les jours ?

J’ai déjà vu une équipe déclarer “personne dans l’équipe ne connait ce logiciel”. Pour un logiciel dont l’équipe en question était responsable ! Mais comme le logiciel fonctionnait et était mur, il n’avait pas été touché pendant deux ans — et les membres de l’équipe avaient tous tourné⁸, pendant ce temps.

L’idée que l’équipe connait son logiciel est parfois très théorique.

Aujourd’hui, j’entends des inquiétudes de collègues qui me disent :

Si c’est l’IA qui génère le code, l’équipe ne va pas le connaitre, je ne vais pas le connaitre.

Cette affirmation est parfois suivie de :

… et donc, en cas de bug, on mettra plus longtemps pour investiguer et corriger.

Et la première réponse qui me vient à l’esprit, c’est “ben, comme avant, non ?”

Oui, en effet, on va avoir du code — beaucoup de code, plus encore qu’avant sans doute — qu’on ne connait pas.

Mais votre application, surtout quand c’est le coeur de votre métier, vous ne la vibe-codez pas, tout de même ?

• Vous co-écrivez des spécifications, déjà : vous avez donc un document solide et plutôt complet qui décrit le quoi du projet.
• Et vous co-architecturez votre projet, aussi : vous itérez avec votre outil, plutôt que de le lancer sans aucun guide.
• Et vous avez mis en place des systèmes de revue et de validation.

Si vous travaillez ces trois points, c’est mieux que la plupart des projets sur lesquels j’ai bossé dans ma vie ! Et vous, vos collègues et votre IA ont des chances de faire du travail de qualité acceptable 🙏.

Bon, j’admets, si vous vibe-codez comme un ou une sauvage… Vous aurez sans doute du mal au bout d’un moment. Et c’est normal : le vibe-coding, tel que le terme a été initialement lancé, ce n’était pas pour des vraies applications !

Reste une question : comment est-ce qu’on entre dans du code, comment est-ce qu’on appréhende du code, si on a perdu l’habitude d’en écrire ?

Pour l’instant, j’ai deux éléments de réponse, qui ne vont peut-être pas encore jusqu’au bout.

Tout d’abord, il y a bien deux ans, quand je demandais à mes collègues comment ils utilisaient l’IA dans leur quotidien, pas mal de devs me répondaient “ChatGPT m’aide pour entrer dans du code que je ne connais pas”. Et bien, si ChatGPT vous aidait à comprendre du code que votre équipe avait écrit six mois auparavant, pourquoi est-ce qu’il ne vous aiderait pas pour comprendre du code écrit par Claude la semaine dernière ?

Ensuite, et c’est peut-être encore un peu tôt aujourd’hui, mais ça pourrait évoluer dans ce sens : si vous avez des specs complètes⁹, quand vous aurez un bug ou une évolution à faire dans deux ans, essayerez-vous de modifier le code ? Ou allez-vous mettre à jour les specs, jeter tout le code, et re-générer l’application entière, en bénéficiant au passage d’un modèle et d’outils plus performants ?

Cela dit, j’avoue : je ne sais pas quoi répondre à “et comment on appréhende du code si on en a jamais vraiment écrit de sa vie ?”

PS: nos métiers évoluent très vite et je comprends très bien que vous soyez inquiet ou dubitatif. Je vous encourage à au moins expérimenter, à découvrir. Et IA ou pas IA, croyez-en quelqu’un qui bosse depuis 20 ans : vous ne ferez pas la même chose, ou pas de la même manière, dans 10 ans ! Aussi, notez que je sais changer d’avis et d’opinions et que ce que j’écris aujourd’hui ne reflète pas toujours ce que je pensais il y a deux ans… ni, peut-être, ce que je penserai dans deux ans ;-)

Illustration par Dmitry Ratushny sur Unsplash