Principes de conception, patterns structurels et bonnes pratiques pour construire des applications durables. SOLID, clean architecture, design patterns, injection de dépendances : les fondations qui distinguent un code maintenable d'un code qui résiste au
Le hub complet : 4 familles, 20 principes, 16 articles d'approfondissement. Une carte pour s'orienter dans ce qui distingue un code maintenable d'un code qu'on subit.
Un token API qui peut tout faire alors qu'il sert à lire trois fichiers. Un utilisateur Postgres qui peut DROP la base alors qu'il ne fait que des SELECT. Un conteneur Docker qui tourne en root sans aucune raison. Le principe de moindre privilège existe pour transformer ces accidents en non-événements.
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.
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.
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.
