Les 20 principes de code qui font la différence entre un projet qu'on garde et un projet qu'on jette
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.
Le Briefing Dev - les ressources et actus de la semaine, droit dans ta boîte chaque vendredi gratuitement.
La plupart des projets ne meurent pas d'un manque de fonctionnalités. Ils meurent parce que personne n'arrive plus à modifier le code sans casser autre chose. Tu as déjà vu un repo où chaque pull request prend une journée, où corriger un bug en crée deux, où ajouter un bouton demande de comprendre quatorze fichiers.
Toi, tu sens que quelque chose cloche. Tu lis des articles sur SOLID, sur DRY, sur KISS, et chaque principe semble évident en lecture. Pourtant ton code continue de devenir illisible mois après mois.
Le problème n'est pas que tu ne connais pas les principes. C'est que personne ne te les a présentés comme un système cohérent. Ils sont éparpillés sur des dizaines d'articles, présentés comme des règles isolées, sans hiérarchie ni mode d'emploi. Résultat : tu en appliques deux ou trois au hasard, tu en oublies dix autres, et tu finis par penser que le code propre est une question de talent.
Cet article est le hub que j'aurais voulu lire en reconversion. Une vue d'ensemble structurée des 20 principes de code que tout dev devrait connaître, regroupés en 4 familles, avec un article dédié pour chacun. Tu peux le lire de bout en bout, ou t'en servir comme table des matières pour explorer ce qui te concerne maintenant.
Ce qui suit, en clair
Si tu débutes, lis la famille Fondamentaux en premier. C'est le socle.
Si tu travailles déjà sur des projets orientés objet, attaque SOLID.
Si ton code marche mais devient pénible à maintenir, regarde côté Discipline.
Et si tu te perds dans des refactos ou des optimisations sans fin, la famille Pragmatique est faite pour toi.
Fondamentaux
Cinq principes qui sont à la programmation ce que la grammaire est à l'écriture. Tant qu'ils ne sont pas intégrés, le reste ne tient pas.
DRY, Don't Repeat Yourself
Quand une règle métier est dupliquée dans cinq fichiers, chaque modification devient une chasse au trésor. DRY n'est pas une obsession de la déduplication, c'est un outil pour éviter que ton code te trahisse à chaque évolution.
KISS, Keep It Simple
Tout le monde dit préférer le code simple. Pourtant, la complexité s'accumule à chaque sprint. KISS est une discipline qui demande plus de retenue que d'intelligence. C'est ce qui distingue un dev expérimenté d'un dev qui veut prouver qu'il l'est.
YAGNI, You Aren't Gonna Need It
Le code que tu n'écris pas est souvent le meilleur. YAGNI te protège des systèmes ultra-flexibles que personne n'utilise, des abstractions prématurées, et de la fatigue qui vient d'avoir codé trois fois trop.
Separation of Concerns
Le fichier qui gère à la fois la requête HTTP, la validation, l'accès base de données et l'envoi d'email existe dans tous les projets. La séparation des préoccupations est ce qui permet de ne pas en arriver là, sans tomber dans l'excès inverse.
Single Source of Truth
Le prix du produit affiché sur la fiche n'est pas le même que dans le panier. L'utilisateur est connecté ici mais déconnecté là. Ces bugs viennent presque toujours d'une violation du principe de source unique de vérité.
SOLID
Cinq lettres pour cinq principes qui structurent la conception orientée objet depuis vingt ans. Ce n'est pas un dogme académique, c'est le socle que toutes les équipes sérieuses appliquent.
Les cinq lettres de SOLID forment un ensemble. Je les traite dans un article unique parce qu'elles ne prennent leur sens que rassemblées. SRP isole les responsabilités, OCP rend le code extensible sans le modifier, LSP garantit que les sous-classes ne trahissent pas leurs parents, ISP évite les interfaces fourre-tout, et DIP inverse les dépendances pour les pointer vers l'abstrait plutôt que vers le concret.
SOLID : SRP, OCP, LSP, ISP, DIP
Tour d'horizon complet des cinq principes avec exemples concrets. Si tu fais de l'orienté objet en PHP, Java, Python, TypeScript ou C#, c'est un passage obligé. Tu trouveras aussi des contre-exemples : SOLID mal appliqué fait plus de dégâts que pas appliqué du tout.
Discipline
Cinq principes qui ne s'inventent pas en écrivant. Ce sont des réflexes qu'on adopte en se confrontant à de vrais projets, et qui transforment une base de code subie en base de code tenue.
Law of Demeter
Quand un changement dans une classe lointaine casse trois fichiers que tu pensais indépendants, le problème n'est pas la malchance. C'est la loi de Déméter qui a été ignorée. Le principe : ne parle qu'à tes amis directs, pas aux amis de tes amis.
Tell Don't Ask
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 : ne pas demander, dire.
CQS, Command Query Separation
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. CQS existe pour rendre ce genre de scène impossible.
Composition over Inheritance
Tu avais conçu une belle hiérarchie de classes. Six mois plus tard, il faut ajouter une fonctionnalité qui ne rentre plus dans le moule. Ce blocage n'a rien d'exceptionnel, et la solution existe depuis trente ans : composer plutôt qu'hériter.
Least Privilege
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. Le principe de moindre privilège transforme tes accidents en non-événements.
Pragmatique
Cinq principes qui te protègent de toi-même. Tous les pièges qu'on découvre en cours de carrière : factoriser trop tôt, optimiser sans mesurer, surprendre les futurs lecteurs.
Fail Fast
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. Fail Fast empêche ces histoires de se répéter.
Boy Scout Rule
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. L'article explique comment l'appliquer sans devenir insupportable.
Rule of Three
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.
Principle of Least Astonishment
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 : ne pas surprendre celui qui lit ou utilise ton code.
Optimisation prématurée
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. C'est exactement ce que Donald Knuth dénonçait en 1974.
Par où commencer selon ton niveau
La pire approche, c'est de vouloir tous les appliquer en même temps. Tu vas paralyser ton écriture de code et tu vas finir par les abandonner. Voici un ordre de découverte qui marche, testé en formation auprès de personnes en reconversion et de développeurs juniors.
Si tu débutes le développement
Commence par DRY, KISS, YAGNI. Ces trois principes vont t'éviter 80 % des erreurs de débutant. Ne te lance pas tout de suite dans SOLID, c'est prématuré tant que tu n'as pas écrit plusieurs centaines de lignes d'orienté objet. Pour cadrer ta progression globale, notre formation Algorithmique et logique de programmation pose les bases avant tout principe avancé.
Si tu fais déjà de l'orienté objet
Attaque SOLID. C'est dense, mais ça transforme ta manière d'écrire des classes. Si tu travailles avec PHP, notre formation PHP orienté objet applique ces principes sur des cas concrets. Pour ceux qui font du Java, Les fondamentaux de la programmation Java et POO couvre le terrain équivalent.
Si ton code marche mais devient pénible à maintenir
Tu es au bon endroit pour la famille Discipline. Loi de Déméter, Tell Don't Ask, CQS et Composition over Inheritance vont t'expliquer pourquoi tes refactos prennent toujours plus de temps que prévu.
Si tu travailles sur du legacy ou en équipe
Boy Scout Rule, Rule of Three et Principle of Least Astonishment sont tes meilleurs alliés. Ils t'évitent les pull requests trop ambitieuses et les refactos qui partent dans tous les sens. La famille Pragmatique entière est faite pour les contextes où le code n'est jamais écrit depuis zéro.
Les pièges à éviter quand on découvre ces principes
J'ai vu suffisamment d'apprenants tomber dans les mêmes pièges pour les lister ici. Les connaître à l'avance change tout.
Vouloir les appliquer tous, tout le temps
Ces principes ne sont pas des règles à cocher. Ils s'arbitrent entre eux. DRY te pousse à factoriser, Rule of Three te dit d'attendre. YAGNI te dit de ne rien anticiper, OCP te dit de concevoir pour l'extension. La maturité, c'est de savoir lequel s'applique quand.
Les transformer en dogme
Le pire usage de SOLID que je connaisse, c'est celui qu'on impose en review sans comprendre le contexte du code. Un principe mal appliqué fait souvent plus de mal qu'aucun principe.
Les lire sans coder
Lire un article sur DRY ne te fait pas comprendre DRY. Tant que tu ne l'as pas appliqué sur un vrai projet, et surtout tant que tu n'as pas vécu une fois ce qu'il évite, le principe reste une formule creuse. Chaque article de cette série contient des exemples concrets. Code-les.
Les utiliser pour juger les autres
Un junior qui découvre SOLID a souvent envie de dire à tout le monde que leur code viole SRP. C'est humain, mais c'est contre-productif. Ces principes sont des outils pour soi, pas des armes pour les autres.
Ce qu'il faut retenir
Les 20 principes de cette série couvrent les fondamentaux du code maintenable. Tu n'as pas besoin de tous les maîtriser tout de suite. Tu as besoin de savoir qu'ils existent, et d'aller chercher le bon au bon moment.
Le vrai indicateur de progrès n'est pas combien de principes tu connais, c'est combien de fois par semaine tu te retrouves à dire : ah oui, c'est exactement le piège que ce principe décrivait.
