Qu'est-ce que le « bon goût » en génie logiciel ?

Par Sean Goedecke

Qu'est-ce que le « bon goût » en génie logiciel ? par Sean Goedecke

Le goût technique est différent des compétences techniques. Vous pouvez être très compétent sur le plan technique, mais avoir mauvais goût, ou être moins compétent, mais avoir bon goût. Comme le goût en général, le goût technique précède parfois vos capacités : tout comme vous pouvez distinguer un bon plat d'un mauvais sans savoir cuisiner, vous pouvez savoir quel type de logiciel vous aimez avant d'avoir les compétences nécessaires pour le créer. Vous pouvez développer vos compétences techniques par l'étude et la répétition, mais le bon goût se développe d'une manière plus mystérieuse.

Voici quelques indicateurs du goût en matière de logiciels :

• Quel type de code vous « semble beau » ? Quel type de code vous « semble laid » ?
• Quelles décisions de conception vous semblent vraiment bonnes, et lesquelles vous semblent simplement correctes ?
• Quels problèmes logiciels vous dérangent vraiment, au point que vous vous en préoccupez en dehors du travail ? Quels problèmes pouvez-vous simplement ignorer ?

Je pense que le goût est la capacité à adopter l'ensemble des valeurs d'ingénierie qui correspondent à votre projet actuel.

Pourquoi le goût est-il différent de la compétence ?

Les indicateurs ci-dessus ne font-ils pas simplement partie de la compétence ? Par exemple, un code n'est-il pas beau s'il est bon ? Je ne pense pas.

Prenons un exemple. Personnellement, je trouve que le code qui utilise map et filter est plus élégant que celui qui utilise une boucle for. Il est tentant de penser que j'ai tout simplement raison sur un point d'ingénierie. Par exemple, map et filter impliquent généralement des fonctions pures, qui sont plus faciles à comprendre, et ils évitent toute une catégorie de bogues d'itérateur off-by-one. J'ai l'impression qu'il ne s'agit pas d'une question de goût, mais d'un cas où j'ai raison et où les autres ingénieurs ont tort.

Mais bien sûr, c'est plus compliqué que cela. Les langages comme Golang ne contiennent pas du tout map et filter, pour des raisons de principe. L'itération avec une boucle for est plus facile à comprendre du point de vue des performances et plus simple à étendre à d'autres stratégies d'itération (comme prendre deux éléments à la fois). Je ne me soucie pas autant de ces raisons que des raisons en faveur de map et filter - c'est pourquoi je n'écris pas beaucoup de boucles for - mais il serait beaucoup trop arrogant de ma part de dire que les ingénieurs qui préfèrent les boucles for sont simplement moins compétents. Dans de nombreux cas, ils ont des capacités techniques que je n'ai pas. Ils se soucient simplement de choses différentes.

En d'autres termes, notre désaccord se résume à une différence de valeurs. J'ai écrit à ce sujet dans Je ne sais pas comment créer des logiciels et vous non plus. Même si les grands débats techniques ont des réponses définitives, aucun ingénieur logiciel en activité n'est en mesure de connaître ces réponses, car une carrière ne permet d'acquérir qu'une expérience limitée. Nous nous appuyons tous, au moins en partie, sur notre expérience personnelle : sur notre ensemble particulier de valeurs d'ingénierie.

Qu'est-ce que le goût technique ?

Presque toutes les décisions en génie logiciel sont des compromis. Il est rare de devoir choisir entre deux options dont l'une est clairement meilleure que l'autre. Au contraire, chaque option a ses avantages et ses inconvénients. Il faut souvent faire des compromis difficiles entre différentes valeurs techniques : au-delà d'un certain point, il n'est par exemple plus possible d'améliorer facilement les performances sans nuire à la lisibilité.

Remarque : Bien sûr, ce n'est pas toujours vrai. Il existe des changements gagnant-gagnant qui permettent d'améliorer simultanément plusieurs valeurs généralement opposées. Mais la plupart du temps, nous ne sommes pas dans cette situation.

Comprendre vraiment ce point est (à mon avis) le meilleur indicateur de maturité en génie logiciel. Les ingénieurs immatures sont rigides dans leurs décisions. Ils pensent qu'il est toujours préférable de faire X ou Y. Les ingénieurs matures sont généralement prêts à considérer les deux côtés d'une décision, car ils savent que les deux côtés présentent des avantages différents. L'astuce consiste non pas à décider si la technologie X est meilleure que Y, mais si les avantages de X l'emportent sur ceux de Y dans ce cas particulier.

En d'autres termes, les ingénieurs immatures sont trop inflexibles quant à leurs goûts. Ils savent ce qu'ils aiment, mais ils confondent cette préférence avec une position d'ingénierie fondée sur des principes. Qu'est-ce qui définit les goûts d'un ingénieur particulier ?

À mon avis, vos goûts en matière d'ingénierie sont composés de l'ensemble des valeurs d'ingénierie que vous jugez les plus importantes. Par exemple :

La résilience. Si un composant de l'infrastructure tombe en panne (un service cesse de fonctionner, une connexion réseau devient indisponible), le système reste-t-il fonctionnel ? Peut-il se rétablir sans intervention humaine ?

La vitesse. Quelle est la vitesse du logiciel par rapport à la limite théorique ? Le travail effectué dans le chemin chaud est-il strictement nécessaire ?

Lisibilité. Le logiciel est-il facile à comprendre d'un seul coup d'œil et à prendre en main pour les nouveaux ingénieurs ? Les fonctions sont-elles relativement courtes et bien nommées ? Le système est-il bien documenté ?

Exactitude. Est-il possible de représenter un état invalide dans le système ? Dans quelle mesure le système est-il verrouillé par des tests, des types et des assertions ? Les tests utilisent-ils des techniques telles que le fuzzing ? Dans les cas extrêmes, le programme a-t-il été validé par des méthodes formelles telles que Alloy ?

Flexibilité. Le système peut-il être facilement étendu ? Est-il facile d'y apporter des modifications ? Si je dois modifier quelque chose, combien de parties différentes du programme dois-je modifier pour y parvenir ?

Portabilité. Le système est-il lié à un environnement opérationnel particulier (par exemple, Microsoft Windows ou AWS) ? Si le système doit être redéployé ailleurs, cela peut-il se faire sans travaux d'ingénierie importants ?

Évolutivité. Si le trafic augmente de 10 fois, le système va-t-il s'effondrer ? Et s'il augmente de 100 fois ? Le système doit-il être surdimensionné ou peut-il évoluer automatiquement ? Quels goulots d'étranglement nécessiteront une intervention technique ?

Vitesse de développement. Si je dois étendre le système, en combien de temps cela peut-il être fait ? La plupart des ingénieurs peuvent-ils y travailler ou faut-il faire appel à un expert du domaine ?

Il existe de nombreuses autres valeurs techniques : élégance, modernité, utilisation de l'open source, coût financier du fonctionnement du système, etc. Toutes ces valeurs sont importantes, mais aucun ingénieur ne les considère toutes de la même manière. Vos préférences sont déterminées par les valeurs que vous considérez comme les plus importantes. Par exemple, si vous accordez plus d'importance à la vitesse et à l'exactitude qu'à la vitesse de développement, vous préférerez probablement Rust à Python. Si vous privilégiez l'évolutivité à la portabilité, vous serez probablement favorable à un investissement important dans les particularités et les outils de votre hébergeur (par exemple AWS). Si vous privilégiez la résilience à la vitesse, vous serez probablement enclin à répartir votre trafic entre différentes régions. Et ainsi de suite.

Remarque : Comme je l'ai dit plus haut, différents projets exigeront évidemment un ensemble de valeurs différentes. Mais les ingénieurs qui travaillent sur ces projets devront tout de même fixer des limites, et ils s'appuieront sur leurs propres goûts pour le faire.

Il est possible de décomposer ces valeurs de manière plus fine. Deux ingénieurs qui accordent tous deux une grande importance à la lisibilité peuvent être en désaccord, car l'un privilégie les fonctions courtes et l'autre les piles d'appels courtes. Deux ingénieurs qui accordent tous deux une grande importance à l'exactitude peuvent être en désaccord, car l'un privilégie les suites de tests exhaustives et l'autre les méthodes formelles. Mais le principe est le même : il existe de nombreuses valeurs d'ingénierie auxquelles on peut s'intéresser, et comme elles sont souvent en tension, chaque ingénieur est obligé d'en prendre certaines plus au sérieux que d'autres.

Comment identifier le mauvais goût

J'ai dit que toutes ces valeurs sont importantes. Malgré cela, il est possible d'avoir mauvais goût. Dans le contexte du génie logiciel, avoir mauvais goût signifie que vos valeurs préférées ne correspondent pas au projet sur lequel vous travaillez.

La plupart d'entre nous ont déjà travaillé avec des ingénieurs de ce type. Ils arrivent sur votre projet en prônant quelque chose (méthodes formelles, réécriture en Golang, méta-programmation Ruby, déploiement interrégional, etc.) parce que cela a bien fonctionné pour eux dans le passé. Que cela convienne ou non à votre projet, ils vont le défendre, car c'est ce qu'ils aiment. Avant même de vous en rendre compte, vous vous assurez que votre tableau de bord de mesures internes affiche une fiabilité à 99,999 %, au prix de le rendre incompréhensible pour tout ingénieur junior.

En d'autres termes, la plupart des mauvais goûts proviennent d'un manque de flexibilité. Je me méfierai toujours des ingénieurs qui justifient leurs décisions en disant « c'est la meilleure pratique ». Aucune décision d'ingénierie n'est la « meilleure pratique » dans tous les contextes ! Vous devez prendre la bonne décision pour le problème spécifique auquel vous êtes confronté.

Une conséquence intéressante de cela est que les ingénieurs ayant mauvais goût sont comme des boussoles cassées. Si vous êtes au bon endroit, une boussole cassée indiquera toujours le nord. Ce n'est que lorsque vous commencez à vous déplacer que la boussole cassée vous induira en erreur. De même, de nombreux ingénieurs ayant un mauvais goût peuvent être très efficaces dans un domaine particulier où leurs préférences correspondent aux besoins du projet. Mais lorsqu'ils changent de projet ou d'emploi, ou lorsque la nature du projet change, tout s'écroule immédiatement. Aucun emploi ne reste le même longtemps, en particulier en ces temps troublés post-2021.

Comment identifier le bon goût

Le bon goût est beaucoup plus difficile à cerner que les compétences techniques. En effet, contrairement aux compétences techniques, le bon goût est la capacité à sélectionner les bonnes valeurs d'ingénierie pour le problème technique particulier auquel vous êtes confronté. Il est donc beaucoup plus difficile de déterminer si quelqu'un a bon goût : vous ne pouvez pas le tester avec des problèmes fictifs ou en posant des questions techniques. Il faut un vrai problème, avec tout son contexte réel complexe.

Vous pouvez savoir si vous avez bon goût si les projets sur lesquels vous travaillez sont couronnés de succès. Si vous ne contribuez pas de manière significative à la conception d'un projet (peut-être que vous ne faites que du travail administratif), vous pouvez savoir si vous avez bon goût si les projets dont vous approuvez les décisions de conception sont couronnés de succès, et si ceux dont vous désapprouvez les décisions sont difficiles. Il est important de disposer d'un ensemble de projets de différents types. S'il s'agit d'un seul projet, ou du même type de projet à plusieurs reprises, vous êtes peut-être simplement doué pour cela. Même si vous travaillez sur de nombreux types de projets différents, cela ne garantit pas que vous ayez bon goût dans les domaines que vous connaissez moins bien.

Remarque : Cela dit, je pense que le bon goût est en quelque sorte transférable. Je n'ai pas beaucoup d'expérience personnelle en la matière, c'est pourquoi je le mentionne dans une note de bas de page, mais si vous êtes flexible et attentif aux détails dans le domaine A, vous serez probablement flexible et attentif aux détails dans le domaine B.

Comment développer un bon goût ? C'est difficile à dire, mais je recommanderais de travailler sur des projets variés, en prêtant attention à ceux (ou aux parties de ceux-ci) qui sont faciles et à ceux qui sont difficiles. Il faut privilégier la flexibilité : essayez de ne pas vous forger d'opinions universelles trop tranchées sur la bonne façon d'écrire des logiciels. J'ai acquis mon bon goût assez lentement. Mais je ne vois pas pourquoi vous ne pourriez pas l'acquérir rapidement. Je suis sûr qu'il existe des prodiges dont le bon goût dépasse leur expérience en programmation, tout comme il existe des prodiges dans d'autres domaines.

Source : "What is "good taste" in software engineering?"

Et vous ?

Pensez-vous que ces affirmations sont crédibles ou pertinentes ?
Quel est votre avis sur le sujet ?

Voir aussi :

L'importance de la vertu dans le développement logiciel, par sean goedecke

Pourquoi vous ne devriez pas supprimer des fonctionnalités : Lettre d'amour d'un développeur au code « impopulaire », par Kush Creates

Les types d'ingénieurs logiciels en tant que joueurs de football, par Mensur Durakovic