On imagine volontiers que l’on devient un meilleur Software Engineer en évoluant exclusivement sur des projets exemplaires : des codebases testables, modulaires, qui reflètent fidèlement le métier, entourées de mentors aguerris. C’est un cercle vertueux, et il est tentant de ne jamais vouloir en sortir. Pourtant, plus les années passent et plus les projets s’accumulent, plus je suis convaincu que c’est ailleurs, dans le désordre des codebases « spaghetti » et des « big ball of mud », que se forge réellement une part essentielle de l’expertise technique.
Le confort du cercle vertueux
J’ai eu la chance de découvrir assez tôt dans ma carrière l’artisanat logiciel, et donc de m’entourer de mentors très expérimentés sur ces sujets. De fil en aiguille, j’ai été naturellement attiré par le fait de travailler avec des personnes qui partageaient ces convictions, et donc d’intervenir sur des projets et des codebases d’un niveau de qualité relativement élevé : du code qui reflète le métier, qui est testable, modulaire, et qui se prête bien à l’évolution.
C’est un environnement confortable et formateur. Mais il faut poser la question franchement : est-ce forcément une bonne chose de vouloir évoluer uniquement dans ce cercle vertueux ? À force de ne côtoyer que du code propre, on finit par ne plus voir ce contre quoi les bonnes pratiques ont été inventées. On manipule des solutions sans avoir réellement éprouvé les problèmes qu’elles résolvent.
Pourquoi le chaos est un terrain d’apprentissage
C’est précisément en arrivant sur des codebases en désordre que l’on rencontre le plus grand potentiel d’apprentissage. Deux dimensions ressortent à mes yeux.
Le potentiel d’apprentissage
C’est là, au contact du mauvais design, que l’on prend conscience de l’impact concret d’une architecture mal pensée : une efficacité et une productivité qui s’effondrent à chaque évolution requise, un coût qui grimpe à mesure que l’on touche au code. Tant que l’on n’a pas pris connaissance de ces problèmes de l’intérieur, les solutions que l’on nous présente ne résonnent pas vraiment en nous. Elles restent des concepts.
La douleur est ici un professeur irremplaçable. Tant que l’on n’a pas personnellement ressenti la friction causée par un couplage excessif, par une absence de tests ou par une logique métier noyée dans la plomberie technique, la plupart des « bonnes pratiques » demeurent théoriques et abstraites. Et il devient alors impossible de réaliser l’importance que le Craftsmanship et toutes les disciplines associées ont au sein de notre profession.
Le potentiel de satisfaction collective
L’autre dimension est plus humaine. Sur ce type de projet, ce que l’on laisse en partant est, presque par définition, dans une meilleure posture que ce que l’on a trouvé en arrivant. On laisse derrière soi une codebase qui place l’équipe dans une position de réussite et d’efficacité, plutôt que dans une lutte permanente contre son propre code. Et une équipe en position de réussite, ce sont mécaniquement plus de chances de succès côté business. La satisfaction de cette transformation collective est difficile à égaler.
Le chaos n’est pas une excuse pour mal faire
Il y a toutefois une condition non négociable, et elle est de taille. Pour se faire les armes sur de gros sujets comme le refactoring, rien de mieux que de combiner une réelle envie d’amélioration avec le background théorique et technique qui permet de la concrétiser, et de pouvoir l’appliquer sur des projets qui en ont vivement besoin.
Sans ce socle, le chaos ne forme personne : il se reproduit. Un ou une Software Engineer qui atterrit sur une codebase en désordre sans cette prise de conscience et sans ce bagage technique ne fera que contribuer au désastre, en empilant de nouvelles strates de complexité sur les anciennes. Le désordre n’est une opportunité que pour celui ou celle qui sait le lire, le nommer, et le démêler méthodiquement. Autrement, il n’est qu’un piège.
La vraie condition : un état d’esprit d’amélioration continue
Reste un dernier facteur, déterminant : l’environnement humain. Tant que l’état d’esprit de l’équipe est en phase avec l’amélioration continue et que l’on peut challenger le statu quo, ces projets se transforment en formidables opportunités de devenir continuellement un meilleur ingénieur. C’est cette ouverture qui fait toute la différence entre un chantier de refactoring et un baroud d’honneur solitaire.
À l’inverse, le meilleur background technique du monde ne sert à rien dans une équipe qui refuse de remettre son code en question. Le chaos n’est une opportunité que là où il existe une volonté partagée d’en sortir.
Conclusion
L’excellence technique ne se construit pas uniquement à l’abri, sur des projets déjà sains. Elle se forge aussi, et peut-être surtout, au contact du désordre, à condition d’y arriver armé de convictions, de méthode, et d’une équipe prête à avancer. Tant que ces conditions sont réunies, je perçois ces codebases difficiles non pas comme une corvée à subir, mais comme une opportunité de progresser. Le chaos, abordé avec les bons outils, est sans doute l’un des meilleurs professeurs que ce métier puisse offrir.