Depuis quelques années, j’utilise les mots suivants pour décrire mon mindset de développement :
« Je suis au maximum le principe KISS (Keep it simple, stupid), j’écris le code le plus direct possible et quand j’ai trop de “douleur” alors je refactor mon code et j’y ajoute le minimum de sophistication indispensable »
Ici j’utilise le mot “douleur” dans le sens de “a pain point” en anglais : quelque chose de casse-pieds, pénibilité, grosse difficulté…
Pendant la plus grande première partie de ma vie de développeur, j’ai essayé d’écrire le code le plus “propre” possible.
Cela passait par :
En résumé, un beau code était pour moi un code “intelligent” avec beaucoup de sophistication.
Il y a un peu moins de dix ans, j’ai commencé à prendre le chemin inverse, quand j’ai réalisé que je passais mon temps à chercher le code “parfait”.
Mon but était-il de faire du code ou de créer un produit rapidement tout en étant de qualité d’un point de vue fonctionnel ?
De 2007 à 2013 j’ai poursuivi la quête du Don’t repeat yourself, de « la balle d’argent » !
Influencé par Ruby On Rails, Django, mon rêve pour améliorer ma productivité était de générer automatiquement les applications à partir du modèle de données et des informations de paramétrages des UX.
Ce fut un échec, un Yak! perpétuel !
Je passais la majorité de mon temps à :
Je me suis trouvé de plus en plus dans des situations où je passais par exemple plus d’une semaine pour modifier un cas particulier d’un simple champ select html, chose qui m’aurait pris 30min sans framework, sans toutes les couches de magies.
À cela s’ajoute en équipe, les heures et les heures de trolls de choix de framework.
Chaque développeur a ses préférences, pour tel ou tel framework et tout cela est parfaitement argumentable, car ils ont tous des forces et faiblesses.
C’est suite à cette expérience que j’ai très peur de bâtir une application sur des solutions comme React Admin, Forest Admin si je sais que je vais devoir les adapter (solutions qui peuvent être très bien pour faire un POC ou un MVP), j’ai très peur de tomber dans un énorme Yak!.
Des rencontres, par exemples :
Ces deux dernières personnes m’ont poussé à réfléchir si je pouvais supprimer des couches, enlever des choses.
Il semble que la perfection soit atteinte non quand il n’y a plus rien à ajouter, mais quand il n’y a plus rien à retrancher. – Antoine de Saint-Exupéry
Depuis 15 ans, je suis très influencé par les 19 principes du Zen de Python, tout particulièrement :
- Préfère :
- l’explicite à l’implicite,
- le déroulé à l’imbriqué,
- Prends en compte la lisibilité.
- Mais, à la pureté, privilégie l’aspect pratique.
- Face à l’ambiguïté, à deviner ne te laisse pas aller.
Les choix minimalistes avec peu de sophistication du langage Go a conforté la direction KISS.
Depuis quelques années, j’essaie d’écrire un code le plus direct possible.
Mon objectif : diminuer au maximum ma charge cognitive.
J’essaie d’ajouter, une librairie, un service ou une couche d’abstraction uniquement si c’est nécessaire fonctionnellement ou si j’ai beaucoup de “douleur” avec la solution actuelle.
J’essaie de garder un code le plus flat possible (The art of avoiding nested code, Flat is better than nested, Avoid Indirection in Code for human readability)
J’essaie de découper mon code uniquement si j’ai trop de “douleur” ou si cela apporte de la valeur fonctionnelle, exemple :