En ingénierie, avoir du bon goût est un concept différent de la compétence [Article traduit]

En ingénierie logicielle, le « bon goût » ne désigne pas une préférence pour une pile technologique particulière, mais la capacité à choisir avec souplesse les valeurs d’ingénierie les plus adaptées à la situation d’un projet donné.

Le goût est un concept différent de la compétence

• Le goût technique est une sensibilité indépendante de la compétence, comme le palais en cuisine : même sans être capable d’écrire soi-même un excellent code, il se manifeste dans la capacité à distinguer « ce code est agréable à voir / je n’aime pas ce code » ou « cette décision de conception me plaît / elle me laisse mitigé ».
• Des choix comme for loop vs map/filter ne relèvent pas d’une supériorité technique absolue, mais simplement de différences de goût selon les valeurs que chacun juge les plus importantes (lisibilité, simplicité, performance, etc.) ; au final, un ingénieur porte ses jugements à partir de l’ensemble de valeurs qu’il privilégie.

Goût d’ingénierie = hiérarchie des valeurs

• La plupart des décisions en ingénierie logicielle sont des arbitrages entre des valeurs comme la performance, la lisibilité, l’exactitude, la flexibilité, l’extensibilité, la résilience, la portabilité ou la vitesse de développement, et il est rare qu’un seul choix soit toujours absolument correct.
• Le goût d’un ingénieur se définit par les valeurs qu’il place en priorité et à quel degré ; par exemple, si l’on accorde plus d’importance à la vitesse et à l’exactitude qu’à la rapidité de développement, on se tournera plus volontiers vers Rust ou un cloud spécifique, et si l’on privilégie la résilience à la vitesse, des choix comme une architecture distribuée multi-région viendront naturellement.

Mauvais goût : le culte rigide des « best practices »

• Le mauvais goût apparaît lorsque les valeurs qu’une personne préfère ne correspondent pas au projet en cours, mais qu’elle impose malgré tout, hors de tout contexte, des méthodes auxquelles elle croit parce qu’elles ont fonctionné par le passé (vérification formelle, réécriture dans un langage donné, multi-région excessif, métaprogrammation complexe, etc.).
• Ces personnes justifient leurs choix en s’appuyant sur des critères absolus du type « c’est une best practice » ; cela peut très bien fonctionner dans des situations particulières, mais dès que le contexte change, cela peut conduire l’équipe dans la mauvaise direction, comme une boussole qui se dérègle.

Bon goût : choisir les bonnes valeurs selon le contexte, avec souplesse

• Le bon goût est la capacité à choisir correctement quelles valeurs mettre en avant et lesquelles sacrifier dans un problème donné, sous les contraintes d’une organisation et d’un contexte métier ; c’est pourquoi il est difficile à mesurer avec de simples questions-réponses ou des tests théoriques, et il ne se révèle qu’à travers la conception et les résultats de projets réels.
• Ce n’est qu’en observant à plusieurs reprises, sur différents projets, que les projets intégrant des conceptions avec lesquelles on était d’accord se déroulent bien, tandis que ceux fondés sur des choix que l’on désapprouvait rencontrent des difficultés, qu’on peut enfin vérifier si « mon goût était juste / faux dans ce contexte ».

Comment développer un bon goût

• Le bon goût ne s’acquiert pas par une réponse unique ou un manuel, mais se construit progressivement en traversant des projets variés et en revenant consciemment, encore et encore, sur ce qui a été fluide ou difficile, et sur les choix de valeurs qui ont fini par poser problème plus tard.
• Le point clé est la souplesse : il faut éviter de traiter un langage, un pattern ou une architecture comme une règle absolue, et il est important de rester ouvert aux nouveaux domaines comme aux préférences de ses collègues, d’essayer plusieurs points de vue et plusieurs langages, puis de continuer à mettre à jour son propre goût de base.