Vous écrivez pour être lu

Ego driven developpement

Non, réduire et condenser votre code ne fait pas de vous un meilleur développeur.

Ecrire en une ligne ce que vous faisiez habituellement en 3 grace à la dernière astuce à la mode sur Twitter n’est en aucun cas un gage d’amélioration.

Vous savez, ce fameux poste Twitter avec des flammes 🔥🔥🔥

Cette ligne de 30 caractères condensée à l’extrême qui vous semble astucieuse et fait probablement votre fierté échouera certainement à remplir l’une des qualités fondamentales de toutes ligne de code : être explicite.

De nos jours, les développeurs Web se targuent d’être des artisans profitant de l’aura élogieuse qu’évoque cette dénomination relativement pompeuse … mais loin d'un sobriquet, nous sommes avant tout des auteurs !

La programmation est un métier d’écriture et votre code sera lu bien plus souvent qu’il ne sera écrit, cette unique et simple raison justifie d’apporter un soin particulier à la lisibilité de votre code, la concision ne sera jamais synonyme de qualité car votre interlocuteur n’est pas une machine.

Tant qu’une IA n’aura pas remplacée le métier de développeur le code que vous produirez sera irrémédiablement destiné à être lu par un être humain.

Lu, compris, et exploité dans le temps.

Un code lisible favorisera la compréhension, simplifiera les codes reviews, améliorera la détection des bugs et enfin permettra la refactorisation et l’amélioration.

Partant de ce constat, le soin et la lisibilité que vous apportez à votre code deviendra un facteur déterminant de sa longévité.

Alors ne soyez pas avare en lignes, écrivez, exprimez vous à travers votre code, aussi verbeux soit-il et gardez cette simple maxime en tête : votre code n’a pas besoin d’être dense pour être performant et intelligent.

Le code moche fonctionne

Pourquoi écrivons-nous du code ?

Nous écrivons du code pour répondre à la problématique de quelqu’un et non pour être beau et élégant, c’est ici que réside toute l’ironie de notre profession : le code moche fonctionne et génère de l’argent.

En réalité, il peut même être inévitable, voire pertinent, de produire du code jetable dans certaines situations spécifiques.

Votre client s’en fiche que votre PHPStan soit au level 9

Vous évoluez peut-être dans un secteur ultra concurrentiel où produire rapidement est une question de survie, où cette fameuse fonctionnalité qu’exige un client important est une prérogative essentielle pour récupérer une part de marché et stabiliser votre chiffre d’affaires.

Alors soit, il faut produire, et vite.

Cela dit, gardez cette seule chose en tête, le code que vous écrivez à la va-vite aujourd'hui constituera un héritage à maintenir dans les années à venir … faire fonctionner du code en production ne sera jamais une finalité en soi, tout juste un indicateur de performance pour votre équipe.

Cette application que vous développez hâtivement aura-t-elle une architecture suffisamment solide pour envisager et accueillir des évolutions futures à moins qu'elle ne soit nullement stratégique ou même destinée à mourir rapidement ?

Justifier un manque de soin par l’urgence de la situation n’est pas professionnel et pourrait même se retourner contre vous quand l’entreprise sera face à son propre héritage et dans l'impossibilité de faire évoluer son produit.

Ce n’est que du code

Certains me reprocheront probablement l’utilisation d’adjectif comme moche ou propre pour qualifier le code, ces mots peuvent être stigmatisants voire intimidants pour des jeunes développeurs.

Respirez un grand coup, prenons un peu de recul : ce n’est pas grave, le code … n’est que du code !

Ne jugeons le code que pour ce qu’il est, soit une longue série d’instructions pour une machine, ce ne sont que des lignes sur vos écrans, vous n’êtes pas marié à votre code, il n’est pas une extension de vous-même … il est important, voire vital, de s’en détacher !

Ne jugez pas les développeurs, mais jugez le code … et riez-en !

Le code que vous produisez en entreprise est avant toute chose une propriété collective, il appartient à l’équipe et non à un développeur en particulier. Le cas contraire serait d’ailleurs symptomatique d’un problème de partage de connaissances et potentiellement dangereux pour la pérennité de votre application.

Le pair programming, les codes reviews … toutes ces pratiques favorisent le partage des responsabilités et doivent être encouragées.

J’ai moi-même écrit du code moche et j’en écrirais encore probablement longtemps … tout le code sortant de mon clavier aujourd'hui me semblera bien moche, ou inadéquat, un jour ou l’autre.

Pourtant, à un moment donné de la vie de ces applications, leurs codes étaient convenables et ont su générer du bénéfice, répondant aux besoins de mon client.

Quand je recroiserai dans quelques années le chemin d’une ancienne application, je regarderai ce vieux code avec de la sympathie, je me demanderai à quel point j’ai pu être idiot d’imaginer ce pattern, cette solution … et je rigolerai probablement de tout ce code désuet.

Alors plutôt que de vous blâmer de vos erreurs passées prenez plaisir à constater votre progression et n'ayez pas peur d'admettre que ce code, qui était autrefois source de satisfaction, est simplement dépassé.

C’est quoi du code lisible ?

La réponse à cette question sera influencée par plusieurs critères : la compétence et la sensibilité des développeurs constituant votre équipe ainsi que par le niveau de qualité adéquate à obtenir.

Votre code n'a pas besoin d'être parfait, qu'importe ce que cela puisse vouloir dire, car vous ne développez probablement pas des fusées, tout du moins en PHP.

Fuyez toute tendance narcissique à rendre votre code compliqué

Des ouvrages comme le Clean Code de Robert c. Martin ou le Refactoring de Martin Fawler restent encore aujourd'hui des références dès lors qu'on s'intéresse à la qualité logicielle, bon nombre des chapitres de ces deux ouvrages se concentrent sur le style de votre code en présentant des patterns améliorant la lisibilité de ce dernier.

Pourquoi la longueur d'une ligne à de l'importance ? Pourquoi doit-on limiter les arguments d'une méthode ? C'est quoi un niveau d'abstraction ?

Tous ces questionnements dont les réponses peuvent parfois nous paraître évidentes méritent d'être explorées et présentées sans ambiguïté, il sera bien plus intéressant de comprendre en quoi une ligne de 120 caractères est problématique plutôt que d'installer un linter dans votre IDE vous imposant cette limite.

Comprenez pourquoi une règle existe et vous pourrez l'appliquer ou même la contourner.

Dans l'ouvrage "TDD, Clean Code et autres pratiques essentielles" la notion de lisibilité peut être résumée en ces quelques critères :

• La complexité du code est en adéquation avec sa richesse fonctionnelle ?
• Le code est-il explicite, les intentions évidentes ?
• Le code répète-t-il de la logique métier ?
• Le code est-il ouvert à la modification ?

Un code lisible sera donc un code peu complexe, limitant ses responsabilités, que l'on peut parcourir en diagonale tout en saisissant ses intentions ... et bien sûr normé et respectant ses propres conventions.

Ces contraintes exigent un véritable effort de conception, mais bien souvent en programmation, le seul moyen d'aller vite, sera d'y d'aller correctement.

Le code propre semble toujours avoir été écrit par quelqu'un qui s'en soucie ~ Michael Feathers

Automatisez, tout, tout le temps

Établissez des règles de manière collégiale au sein de votre équipe et assurez-vous qu’elles soient comprises de tous, une règle dont le bénéfice n’est pas clair ne sera jamais mise en pratique.

Avoir un code uniforme est extrêmement important pour créer une code base qui soit commune, habituelle, dans laquelle vous ne serez pas perdu ou choqué par la tournure des phrases de l'un de vos collègues.

Cette uniformisation doit, impérativement, être automatisée.

Ne perdez pas du temps dans vos codes reviews à jouer au policier traquant le saut de ligne en trop ou l’accolade au mauvais endroit.

Une code review doit être propice aux dialogues, au partage de connaissance, à la compréhension d’une solution à un problème commun. L’automatisation devient tout bonnement essentielle, profitez d'une code review pour vous concentrer sur le fond et non le style.

Soulignez de manière laconique une erreur de style n’est pas un dialogue, c’est une injonction. Ces remarques sont désagréables et n’apportent aucune plus-value à la review, de plus, elles créeront des tensions inutiles au sein de votre équipe tout en démultipliant les temps de code review avec des allers-retours inutiles.

Il existe des conventions de nommages pour les commentaires de code review limitant les incompréhensions et favorisant la collaboration, utilisez-les !

Conclusion

Cet article n'apportera pas de réponse magique à la question "c'est quoi du beau code ?" tout simplement car aucune réponse absolue ne serait véritablement satisfaisante, ceux qui voudront vous faire croire le contraire manqueront de professionnalisme.

La beauté du code reste subjective et propre à vos habitudes de programmation, Il sera essentiel de rester pragmatique dans votre approche et de viser une qualité proportionnelle à la criticité de votre application.

La qualité seule n'existe pas, elle exige un contexte pour prendre forme.

Vous serez incapable d'écrire du code de qualité si vous n'êtes pas en mesure de décrire les critères déterminants de votre application, des normes comme l'ISO 25010 peuvent vous aider à identifier les éléments essentiels de votre application.

Certains principes de qualité logicielle seront toutefois relativement immuables comme conserver des méthodes courtes, respecter le principe de responsabilité unique, limiter la complexité logarithmique de vos méthodes ... nous avons rapidement présenté quelques ouvrages dans cet article vous permettant d'approfondir ces connaissances.

Produire un code lisible sera un chemin de croix plein d'incertitude et de refactorisation mais gardez en tête que la qualité est une affaire collective et qu'une équipe cherchant à s'améliorer sera la base du succès et de la durabilité de vos projets.

Les bons développeurs écrivent du code que les humains peuvent comprendre ~ Martin Fowler

Mathieu De Gracia

Des fois, mon chat code à ma place 🐱