Articles sur le développement, la formation, les bonnes pratiques et le retour terrain.
Retrouvez l'ensemble de nos publications, des plus récentes aux plus anciennes.
Tu écris une fonction, tu récupères trois champs d'un objet, tu fais un calcul, tu remets le résultat dans l'objet. Tu refais la même chose la semaine suivante avec un autre objet. Ce schéma a un nom, il a aussi un antidote.
Tu appelles une fonction qui ressemble à une lecture. Et au passage, elle modifie quelque chose. Trois mois plus tard, un bug arrive sans prévenir et personne ne sait par où commencer. Le principe Command Query Separation existe pour rendre ce genre de scène impossible.
Tu as appris à ne pas te répéter. Tu factorises dès que tu vois deux lignes similaires. Et six mois plus tard, ton abstraction te coûte plus cher que la duplication qu'elle remplaçait. La Rule of Three est ce qui sépare une bonne factorisation d'une fausse économie.
Tu passes deux heures à réécrire une boucle pour gagner trois millisecondes sur une page qui en met huit cents à charger à cause d'une requête SQL. Cette histoire revient toutes les semaines, et c'est exactement ce que Donald Knuth dénonçait en 1974.
Une fonction qui s'appelle getUser() ne devrait pas créer un utilisateur quand il n'existe pas. Un bouton "Annuler" ne devrait pas valider la modification. Ces situations existent partout, et elles violent toutes le même principe.
Une carte de métro pour t'orienter quand tu apprends Next.js. Pas une liste linéaire à cocher, mais quatre lignes parallèles que tu vas finir par croiser. Voici ce que chaque station veut dire, et dans quel ordre y passer.
Améliorer un peu le code à chaque passage paraît une idée simple. En pratique, c'est l'un des principes les plus mal compris, et l'un de ceux qui finissent le plus souvent en pull request bloquée pendant trois jours.
Comment distinguer une formation sérieuse d'une promesse vide quand presque tout peut être falsifié.
Un null qui traverse trois couches avant de provoquer un crash dans un endroit qui n'a rien à voir avec sa cause. Une donnée corrompue qui finit en base parce que personne ne l'a vérifiée à l'entrée. Le principe Fail Fast est ce qui empêche ces histoires de se répéter.
