- Le goût technique est une notion distincte de la compétence technique : on peut être très compétent et avoir mauvais goût, ou manquer de compétences tout en ayant bon goût
- Le goût d’un ingénieur logiciel désigne la capacité à choisir les valeurs d’ingénierie adaptées à un projet
- Il se manifeste dans des perceptions comme le fait qu’un code semble bon ou mauvais, qu’une décision de conception soit satisfaisante, ou encore les problèmes auxquels on s’obsède ; cela reflète l’ensemble des valeurs d’ingénierie que l’on privilégie
- Toutes les décisions en ingénierie logicielle sont une succession de trade-offs ; l’ingénieur immature considère une approche donnée comme une vérité absolue, tandis que l’ingénieur mature ajuste ses valeurs avec souplesse selon le contexte
- Le bon goût est la capacité à choisir les priorités entre différentes valeurs en fonction d’un projet donné ; le mauvais goût se manifeste par une rigidité qui s’accroche à des critères absolus comme les « best practices »
- Le goût se développe grâce à des expériences sur des projets variés et à une pensée ouverte ; au final, c’est le succès du projet qui révèle la présence ou l’absence de bon goût
Différence entre goût technique et compétence
- Le goût technique ne coïncide pas nécessairement avec un excellent niveau de compétence
- De la même manière que l’on peut distinguer un bon plat d’un mauvais indépendamment de ses talents culinaires, en logiciel le goût se forme avant même la compétence
- Le goût d’un ingénieur se reflète dans la façon dont un code « a l’air bon » ou « semble médiocre »
- Le fait d’être satisfait par certaines décisions de conception et d’accorder plus d’attention à certains problèmes fait partie du goût
- La compétence technique peut progresser par la répétition et l’apprentissage, tandis que le goût se développe d’une manière plus floue et plus intuitive
-
Indicateurs du goût en ingénierie
- Ressentir qu’« un code est beau / mauvais »
- Une forte satisfaction, ou au contraire une indifférence, face à certaines décisions de conception
- Les problèmes logiciels qui continuent de vous préoccuper après la fin de la journée de travail, et ceux qui ne vous préoccupent pas
- Le goût est selon l’auteur la capacité à adopter les valeurs d’ingénierie adaptées au projet en cours
Distinguer compétence et goût
- On peut se demander si un « code qui a l’air bon » doit forcément être un meilleur code dans la réalité
- Exemple : les personnes qui préfèrent
map/filter valorisent la lisibilité du code et les fonctions pures, tandis que celles qui privilégient les boucles for peuvent mettre l’accent sur les performances et la simplicité de l’extension
- Ce n’est pas une question de vrai ou faux, mais de différence entre les valeurs jugées importantes
- Comme chaque langage et chaque contexte ont leurs avantages et leurs inconvénients, aucun choix n’est nécessairement supérieur dans l’absolu
- Chaque ingénieur accorde de l’importance à des valeurs différentes, ce qui fait varier les préférences
Qu’est-ce que le goût en ingénierie ?
- Presque toutes les décisions en ingénierie logicielle relèvent d’un équilibre entre des valeurs contradictoires (trade-offs)
- L’ingénieur inexpérimenté s’entête excessivement dans ses propres préférences
- L’ingénieur mature, lui, sait percevoir les avantages sous différents angles et privilégie les choix adaptés à la situation présente
- La vraie question n’est pas de savoir si X (une technologie) est meilleur que Y (une autre technologie), mais si les avantages de X sont plus nécessaires que ceux de Y dans le projet actuel
-
Exemples de valeurs d’ingénierie
- Resiliency : le système continue-t-il de bien fonctionner malgré des pannes ou des problèmes réseau ?
- Speed : les performances se rapprochent-elles des limites théoriques, y a-t-il beaucoup de travail inutile ?
- Readability : un nouvel ingénieur peut-il comprendre et prendre en main rapidement le système, les fonctions sont-elles courtes et claires ?
- Correctness : des états erronés sont-ils modélisés, les tests, les types et les
assert sont-ils suffisants, va-t-on jusqu’à une vérification formelle ?
- Flexibility : le système est-il facile à faire évoluer, les changements sont-ils simples à appliquer ?
- Portability : le système dépend-il d’un environnement spécifique, un changement d’environnement de déploiement est-il simple ?
- Scalability : en cas de trafic multiplié par 10 ou 100, le système peut-il s’étendre ou s’auto-scaler, où se situent les goulots d’étranglement ?
- Development speed : à quelle vitesse peut-on faire évoluer le système, la majorité des ingénieurs peuvent-ils y contribuer ?
- Il existe aussi d’autres valeurs comme l’elegance, le modern-ness, l’usage de l’open source ou encore les coûts de maintenance
- Tous les ingénieurs ne portent pas le même niveau d’attention à chacune de ces valeurs
- Selon les valeurs que chacun place au plus haut, les langages, frameworks et patterns de conception utilisés diffèrent
Caractéristiques du mauvais goût
- Le mauvais goût apparaît lorsque les valeurs que l’on préfère ne conviennent pas au projet en cours
- Le problème vient d’un manque de souplesse : pousser systématiquement dans son projet les avantages d’une technologie ou d’une méthodologie donnée
- Les discours qui invoquent toujours les « best practices » révèlent une absence de jugement adapté à la situation
- Un ingénieur sans souplesse peut très bien convenir à certains projets, mais provoquer de sérieux problèmes lorsque l’environnement ou la nature du travail change
Caractéristiques du bon goût
- Le bon goût est la capacité à bien choisir les bonnes valeurs d’ingénierie selon la situation
- Contrairement à la simple compétence technique, il ne peut être validé que dans le contexte complexe de projets réels
- Si un projet avance bien après l’adoption de décisions de conception auxquelles on a adhéré, on peut évaluer dans quelle mesure son goût était pertinent
- L’expérience sur des projets variés et, à certains moments, une attitude ouverte envers de nouvelles valeurs sont des éléments d’apprentissage importants
- Préserver sa souplesse et éviter les idées figées sur une technologie ou une méthode aide à développer un bon goût
Conclusion
- Le bon goût est aussi important que la compétence, et peut se développer au fil de la progression grâce à la diversité, à la souplesse et à l’introspection
- Certaines personnes montrent un goût remarquable au-delà même de leur expérience (surdoués en programmation et dans d’autres domaines, par exemple)
Discussion complémentaire
- Dans les commentaires Hacker News, certains exprimaient aussi des doutes sur l’existence même du « goût »
- Certains affirmaient qu’il n’existe qu’une seule bonne solution à chaque problème, mais l’auteur répond qu’en pratique plusieurs solutions sont possibles et que ce sont finalement les valeurs personnelles et le contexte qui orientent le choix
- Une autre opinion soulignait que le contexte client et business fait lui aussi partie du goût
7 commentaires
Cela ressemble moins à un mauvais goût qu’à une mauvaise tendance qui peut être toxique pour l’équipe et le projet.
Avis Hacker News
J’ai constaté que les ingénieurs peu mûrs ont tendance à trop s’attacher à leurs propres préférences, et cette immaturité peut aussi exister chez des ingénieurs expérimentés. Quand j’aidais autrefois des amis sur leur code de devoirs d’informatique, je ressentais l’envie de tout réécrire simplement parce que je n’aimais pas leur code. Mais j’ai fini par comprendre que cela prendrait beaucoup trop de temps et que mes amis ne comprendraient plus le résultat. Je les ai donc aidés en apportant seulement quelques ajustements à leur approche, et ils en ont été plus satisfaits. Ce genre d’expérience m’a permis de découvrir d’autres points de vue et d’améliorer aussi mon propre code. J’en suis venu à penser que c’est plutôt moi qui devrais remercier mes amis. Même aujourd’hui, j’ai du mal à me défaire de mes préjugés, mais j’essaie autant que possible de comprendre sérieusement le point de vue de l’autre, et parfois d’admettre que sa manière est meilleure. Les principes sont en réalité assez subjectifs, donc s’y reposer systématiquement signifie adopter une approche paresseuse, sans réfléchir sérieusement à la situation
Même quand un ingénieur junior fait quelque chose de manière inefficace, je ne lui dis jamais qu’il utilise une méthode moins optimisée. À la place, je lui demande toujours pourquoi il l’a fait ainsi. À la fin de chaque conversation, l’un de nous deux a appris quelque chose. Soit j’apprends une nouvelle manière de faire ou sa raison, soit il apprend pourquoi cette méthode ne tiendra pas à long terme. Dans tous les cas, ce genre d’échange ne se termine jamais de façon conflictuelle
Je pense que le « bon goût » se forme au contact de grandes API et de bon code. On reconnaît immédiatement un bon code quand on le voit, et avec le temps, on devrait être capable d’écrire ainsi soi-même. Mais quand on débute dans le domaine, il est difficile d’avoir un bon goût en programmation, et l’expérience seule ne garantit pas non plus son acquisition ; il faut donc faire l’effort constant de chercher le bon goût, de le reconnaître et de l’imiter
La solution pour sortir des idées préconçues, des biais et d’une manière de penser rigide, c’est l’éducation et l’accumulation d’expériences variées au-delà de son propre point de vue. Il faut faire un effort actif pour comprendre le monde à travers le regard d’autrui afin de progresser comme personne et comme professionnel, et d’élargir sa perspective. En tant qu’ingénieur comme moi intéressé par des domaines variés, le simple fait de savoir qu’il existe d’autres solutions ou d’autres points de vue change ma manière de résoudre les problèmes et m’aide à trouver de meilleures réponses que mon premier réflexe
C’est pour cela qu’il est bon d’expérimenter avec plusieurs langages de programmation. En se confrontant sans cesse à de nouveaux langages qui remettent en cause sa vision actuelle, on vit continuellement des moments de révélation. Au début, cela peut sembler étrange ou faux, mais il faut accepter cet état de fait tant qu’on n’en a pas complètement compris la raison et le fonctionnement
Excellent point de vue. C’est exactement cette façon de penser que j’applique aux personnes que je recrute ou avec qui je travaille. Tant que l’objectif ou le résultat est atteint, il n’est pas nécessaire que la méthode ou les détails correspondent exactement aux miens. J’accepte qu’il existe plusieurs façons de faire
Dans la mode, le « bon goût » me semble moins tenir à chaque vêtement pris isolément qu’à la capacité d’assembler des pièces qui, chacune, peuvent paraître sans grand intérêt en soi, pour produire une impression forte et harmonieuse. J’espérais que l’article irait dans cette direction. J’aimerais davantage explorer ce que les ingénieurs logiciels décident réellement par goût, plutôt que comme simple arbitrage technique. Cela dit, ce texte lui-même me donne l’impression d’être un exemple de mauvais goût. Chaque partie est correctement écrite prise séparément, mais l’ensemble ne crée pas de « look » cohérent, ce qui donne une impression dispersée. Ce n’est pas une attaque contre l’auteur ; je trouve le sujet excellent, et c’est justement pour cela que j’ai encore plus envie de proposer des pistes d’amélioration
Je ne suis pas d’accord avec l’idée qu’un vêtement est dénué de sens en soi. Un vêtement porte une signification culturelle, historique et symbolique avant même d’être combiné à d’autres. La mode va au-delà d’un simple assemblage. Et elle comporte aussi divers arbitrages liés à la production, au port et aux associations
La question qui t’intéresse — « comment percevons-nous la beauté et l’élégance ? » — occupe les philosophes depuis l’Antiquité, et elle est bien trop vaste pour être tranchée dans un seul article. Christopher Alexander, dans le domaine de l’architecture, l’a explorée en profondeur, et sa pensée a fortement influencé l’architecture logicielle. Alexander soutenait qu’il existe une beauté objective. Son keynote OOPSLA et la thèse de doctorat de Roy Fielding valent le détour. La notion de « valeurs » mentionnée dans cet article y est structurée de manière plus systématique sous le terme de « propriétés architecturales »
Fait amusant, moi je pense au contraire que cet article est un texte rare et remarquable, difficile à trouver, qui traite le sujet avec profondeur et méthode
J’aimerais savoir à quel moment, dans quel type de compromis, on peut réellement dire que le « goût » d’un ingénieur entre en jeu, et comment le distinguer d’un simple arbitrage technique. À mes yeux, beaucoup de décisions relèvent de « compromis techniques qu’on ne peut pas démontrer de manière absolue, ou dont la différence est si faible qu’elle n’a pas vraiment d’importance en pratique ». Autrement dit, quand c’est difficile à trancher, on appelle ça du goût
La plupart des développeurs manquent généralement de goût vestimentaire, et comprennent donc assez mal ce qu’est le bon goût en général. Et la plupart des choses du monde de la tech ne paraissent ni élégantes ni cool aux non-techniciens. Les langages de programmation ne sont pas cool. Dans le monde du développement, le point de départ lui-même est « pas cool », puis on descend encore. Par exemple, Rust et C++ relèvent de la catégorie « pas cool », tandis que les langages fonctionnels obscurs, Bash ou Linux appartiennent à la catégorie « vraiment pas cool »
Le bon goût, c’est écrire un code puissamment simple, qu’on a l’impression que n’importe qui aurait pu écrire
Je partage un autre exemple. En démontant puis remontant une Dodge Challenger de 1972, je suis toujours étonné de voir à quel point cette voiture a été conçue de manière simple, directe et peu coûteuse, tout en étant remarquablement bien faite. Par exemple, l’alimentation du tableau de bord nécessite 5 volts, séparés de la tension globale de la voiture (10 à 18 V). Il existe donc une sorte de buzzer utilisant un électroaimant qui coupe le circuit au-dessus de 5 volts et le referme en dessous, oscillant rapidement entre on et off pour produire en moyenne 5 volts. Beaucoup remplacent cela par un régulateur de tension électronique, mais alors le tableau de bord cesse de fonctionner correctement. En réalité, les jauges étant mécaniques, si ce 5 volts ne contient pas un léger bruit, les aiguilles se bloquent fréquemment ; ce 5 volts « rugueux » empêche justement ces blocages. Si on le remplace par une version électronique, il faut réintroduire artificiellement du « bruit ». J’admire à quel point un dispositif mécanique aussi simple peut être excellent à la fois en efficacité et en simplicité
La vraie valeur de ce code simple, même lorsqu’il réduit la maintenance ou fait gagner du temps aux équipes, est souvent mal reconnue. Le code qui applique le principe KISS (Keep It Simple, Stupid) est souvent dénigré parce que sa valeur ne se voit pas. C’est ainsi qu’il existe des équipes ou des organisations qui passent leur temps à gérer une complexité qui n’était pas nécessaire au départ
Parfois, c’est appréciable qu’un ingénieur puisse faire quelque chose d’exceptionnel, mais ce qui compte vraiment, c’est l’ingénieur qui trouve souvent des solutions ordinaires et simples, même si elles paraissent difficiles à atteindre au départ
En regardant le ballet, on entend souvent « ça a l’air vraiment facile ! », mais en réalité ils se sont entraînés des dizaines de milliers de fois pour que cela paraisse si facile
J’ai toujours le plus grand respect pour ceux qui savent résumer quelque chose de complexe de manière vraiment simple. Avec la clarté des exemples du K&R C, mais avec des commentaires un peu plus soignés
La question « peut-on comprendre le code d’un seul coup d’œil, et l’onboarding de nouveaux ingénieurs est-il facile ? » n’est pas aussi simple qu’elle en a l’air. On ne sait pas clairement si « nouveau » désigne quelqu’un avec 0, 10 ou 30 ans d’expérience. La « lisibilité » aussi, même si elle semble évidente pour certains, se déploie en réalité sur un spectre allant de 0 à l’infini. Les équations de Maxwell sont parfaitement limpides pour certains et totalement opaques pour d’autres. Donc quand on dit « le code doit être facile à lire », je me demande toujours : facile à lire pour qui ?
Un code lisible est un code qui réduit au minimum la charge cognitive pour son lecteur. C’est aussi l’objectif des abstractions en couches et des design patterns. Bien sûr, cela dépend de l’expertise du lecteur visé et de sa familiarité avec la base de code, donc il y a une part de subjectivité. Mais rejeter la lisibilité au motif qu’elle est subjective, c’est aller un peu loin. On ne peut pas dire que Ulysse de Joyce et The Cat in the Hat de Seuss sont également faciles à lire
Je ne suis pas d’accord avec l’affirmation selon laquelle « la lisibilité n’est pas un concept ». Un code illisible est un code que personne ne peut lire, pas même son auteur (ou une IA). Et un code que seul son auteur peut lire n’est pas non plus un code facile à lire
Les équations de Maxwell étaient réellement difficiles à l’époque, mais la forme que nous connaissons aujourd’hui est le résultat d’un travail de reformulation, notamment par Heaviside, qui les a rendues plus lisibles
Je pense que la « lisibilité locale » d’une partie du code a peu d’importance. Si des patterns sont appliqués de manière cohérente dans l’ensemble de la base de code, alors même s’ils sont un peu complexes, le résultat global peut rester tout à fait lisible. Une complexité temporaire est acceptable si elle n’affecte pas la qualité globale du code
La lisibilité vise en général à réduire la complexité accidentelle. Une notation médiocre peut rendre difficile la compréhension, qu’il s’agisse d’équations de type scénario de film ou d’algorithmes complexes. Au fond, à la question « pour qui le code doit-il être lisible ? », je répondrais qu’il doit l’être pour un ingénieur familier du problème métier mais qui n’a pas encore vu ce code précis. C’est comparable à un article académique, qui doit être lisible pour le groupe de chercheurs concerné. Résumé de No Silver Bullet
Je pense que la métaphore selon laquelle « un ingénieur au mauvais goût est comme une boussole cassée qui finit toujours par indiquer la mauvaise direction » décrit bien l’essentiel. Ce type de personne, « cassée de façon prévisible », peut être filtré en entretien. Le plus dangereux, c’est plutôt la « boussole partiellement cassée ». En apparence, elle semble parfois tourner correctement, alors qu’en réalité elle dévie toujours exactement de 127 degrés
Ce genre d’article mélange souvent deux problèmes distincts. D’abord, il existe des décisions objectivement mauvaises, indépendamment du goût ou des principes — par exemple, une recherche en O(n) dans une liste contre une recherche en O(1) dans un dictionnaire. Il y a bien des cas où l’avantage technique est clair et démontrable. Ensuite, tout le reste relève de compromis. Utiliser map-reduce ou une boucle classique, considérer la performance, la lisibilité, la compatibilité, etc. : dès lors qu’il y a une raison, peu importe que ce soit différent de ce que j’aurais fait. Le problème, c’est quand la décision est objectivement mauvaise ou quand le compromis lui-même n’a même pas été envisagé. Là, on entre dans le domaine de la maintenance, et selon le contexte — performances, fréquence d’exécution, etc. — on peut décider de ne pas y toucher. Tant que le « pourquoi » de cette décision est clair, je l’accepte. Je ne sais pas vraiment si cela mérite d’être appelé du « goût »
Le problème de ce texte, c’est qu’il traite de manière trop décontextualisée l’idée que « chacun valorise des choses différentes ». En pratique, un ingénieur devrait être capable de sentir quelles valeurs sont les plus importantes pour un problème donné, c’est-à-dire quelles sont les contraintes fortes. Ce qui reste comme degrés de liberté une fois ces contraintes posées, c’est cela qu’on peut appeler du « goût ». Pour prendre une analogie artistique, c’est la part où subsistent des contraintes ou des libertés supplémentaires, au-delà des matériaux et des dimensions imposés. Le bon goût en ingénierie logicielle ressemble, à mes yeux, à une recherche de minimalisme esthétique alliée à un maximum d’autodiscipline. Les vrais cas de « mauvais goût », pour moi, sont ceux où l’on enfreint un principe sans aucune raison. Très souvent, on y confond la simplicité avec la familiarité
La section « valeurs » de l’article peut être reliée aux propriétés de l’architecture logicielle décrites dans la thèse de doctorat de Roy Fielding. Cette thèse est surtout célèbre pour REST, mais c’est en réalité une réflexion plus large et plus solide sur l’architecture logicielle. Elle aide à penser dans le cadre de plusieurs « propriétés architecturales » — extensibilité, lisibilité, maintenabilité, etc. — et, personnellement, j’aimerais insister aussi sur l’importance de bien comprendre les « contraintes architecturales »
Une ingénierie sérieuse (Principled engineering) devrait aller de soi. Par-dessus cela, on peut avoir bon ou mauvais goût. Mais l’inverse n’est pas vrai. Si l’ingénierie elle-même est mauvaise, le goût n’a plus de sens. Le mauvais goût peut nuire à l’efficacité de l’ingénierie, mais il ne rend pas l’ingénierie impossible en soi. L’ingénierie sert fondamentalement de support au goût. Par exemple, même quelque chose d’ingéniéré à la perfection n’a aucune valeur si personne n’en a besoin ni n’en veut
Le mauvais goût finit par nous conduire vers une situation d’incertitude (X) que nous cherchons justement à éviter. À mes yeux, le bon goût consiste finalement à préparer la base de code à l’incertitude du futur, en lui donnant des fondations solides et des garde-fous. C’est ainsi qu’on évite de se mettre en danger
C’est vraiment bien.
L’article original est bien, mais les commentaires sont eux aussi vraiment excellents.
Quand on parle de goût, cette vidéo TED de Torvalds me vient à l’esprit :
https://www.ted.com/talks/linus_torvalds_the_mind_behind_linux
À partir de 14:20, le bon goût vu à travers la manière d’implémenter le code de suppression d’une entrée dans une linked list
Même une « décision objectivement mauvaise » évoquée dans un commentaire sur Hacker News (par ex. une recherche en O(n) dans une liste vs une recherche en O(1) avec un dictionnaire) peut devoir être tranchée différemment selon le contexte.
S’il n’y a qu’une seule recherche à effectuer, le coût de construction d’une table de hachage peut être plus élevé qu’une recherche en O(n) dans une liste.
C'est un bon commentaire.