Un code parfait est aussi subjectif qu’une table parfaite

– Une solution disponible qui fonctionne à 50%
résout davantage de problèmes et survit plus longtemps
qu’une solution qui fonctionne à 99% mais qui n’existe pas encore,
parce qu’elle est constamment en train d’être peaufinée.

– Tu n’es pas là pour écrire du code,
tu es là pour livrer des produits.

Ces deux citations ne sont pas de moi, mais de mon héro des TI.

J’ai peu de modèles dans la vie en général – dans mon domaine professionnel, encore moins. Je parle ici de vrais modèles, pas ceux qu’on idolâtre aveuglément ou dont on respecte simplement le succès… mais ceux qui forgent notre mentalité et notre vision: ceux qui changent notre personnalité… Je peux respecter des gens comme Steve Jobs ou Mark Zuckerberg, mais prétendre qu’ils m’inspirent au quotidien serait faux.

Par contre, Joel Spolsky m’inspire vraiment.

Pour le décrire brièvement, il a d’abord travaillé chez Microsoft sur des produits comme Excel et Visual Basic. Il a aussi co-fondé le très utile et populaire Stack Overflow et plus récemment, Trello. Son blog perso, Joel on software est une mine d’or.

Avec une touche bien personnelle, ce billet sera teinté de deux de ses articles, soit celui du programmeur Duct-Tape ainsi que des Choses à ne pas faire, Partie 1.

Abordons maintenant le titre un peu saugrenu de ce billet. En quoi un code peut-il se comparer à une table de cuisine? Et en quoi ces deux-là peuvent-ils être subjectifs!? J’ai choisi ce titre pour deux raisons: la première pour faire une analogie concrète d’un domaine abstrait, la seconde pour entrer dans le vif du sujet – qu’il n’y a pas, à mon sens, de code universellement « bon ».


Un collègue me mentionnait que la programmation était en quelque sorte une forme d’art, car possédant une bonne part de créativité. Étrange aux premiers abords, mais tellement vrai quand on y songe! Demandez à dix programmeurs différents d’écrire la même fonctionnalité et aucune ne sera identique. Mieux encore: demandez au même programmeur de développer la même fonctionnalité dix fois, à intervalles de deux mois (et sans pouvoir reprendre son code précédent)… le résultat sera différent chaque fois. Il y aura bien une syntaxe reconnaissable, une structure similaire… mais le résultat final sera pourtant toujours différent.

Car en effet, le code, c’est de l’art. C’est subjectif dans la mesure où le développeur dispose de créativité lorsqu’il crée son code. Appelons cela l’inspiration de l’instant. Il reste soumis à certaines balises, allant de brèves spécifications initiales (le code doit simplement faire X, Y et Z) à toute une nomenclature de développement (les fichiers doivent être classés comme ceci, nommés comme cela et contenir X à cet endroit) mais la part de créativité d’un développeur transparaîtra inévitablement. En quelque part: son style, sa signature… son oeuvre. Et pourtant, même Picasso ne reproduisait jamais la même toile.

Partant de ce fait, il ne faut pas se surprendre que les uns n’aiment pas « raboter » les tables des autres.

Demandez à n’importe quel programmeur de modifier un code existant de 80 fichiers ayant chacun 800 lignes de codes… tôt ou tard il vous arrivera avec ces deux énoncés, probablement dans cet ordre:

  1. l’ancien développeur est un incompétent et son code est pourri
  2. il vaut mieux repartir de zéro

Mon héro, Joel Spolsky, explique ce syndrome de cette façon:

La raison pour laquelle ils croient que l’ancien code
est pourri vient d’une loi fondamentale de la programmation:
Il est plus difficile de lire du code que d’en écrire.

Ce qui est vrai. En jardon du métier, ça s’appelle le reverse-engineering. C’est effectivement long et chiant à faire, surtout quand 6 ou 7 fichiers différents impactent le petit bout de code qu’on désire comprendre ou modifier.

Néanmoins, M. Spolsky suggère fortement de ne pas céder à la tentation de tout refaire. Car en pensant mieux refaire, rien ne garanti que l’intention se concrétisera.

Pourquoi? Parce qu’en bout de ligne, un code parfait est aussi subjectif qu’une table parfaite.

Ce que j’entends par là est qu’il y a relativement peu de spécifications absolument nécessaires dans la réalisation d’une table de cuisine:

  • qu’elle soit plane et droite
  • qu’elle soit assez grande pour accueillir le repas de X personnes
  • qu’elle soit assez solide pour s’appuyer dessus

À un niveau plus précis, on peut à la limite privilégier un matériau: bois, métal… ou même une forme: ronde ou rectangulaire… même si, déjà à ce stade, les choix sont en partie facultatifs.

Pour le reste, on tombe somme toute dans le subjectif, un certain degré de superflu: bleue ou rouge? Érable ou pin? Vernie ou non? Quant aux chaises: tissus ou cuir?

Que de discussions j’ai eu par le passé pour la gloire d’une accolade renvoyée ou non à la ligne, ou du préfixe à donner à une chaîne de caractères!

Conclusion: il devient vite impossible sinon prétentieux d’affirmer que c’est la table ronde, en érable vernie qui est « meilleure » que la rectangulaire en PVC bleue.

Si la table répond aux besoins initiaux, les caractéristiques de finitions (tant qu’elles n’ont pas été spécifiées en amont) sont à la discrétion de « l’artiste codeur » et sa liberté de créateur le justifie d’utiliser le tourne-vis étoile si bon lui semble.

Il vous reste, comme employeur ou client, de déterminer si vous préférez l’artiste peintre ou le technicien en peinture à numéros!

Laissez un commentaire