Il y a deux grandes écoles chez les développeurs.
Ceux qui parlent d’architecture hexagonale, de clean code, de patterns élégants, de séparation stricte des responsabilités.
Et ceux qui livrent.
Je caricature volontairement. Mais le débat existe.
Et je le dis haut et fort : je suis un mauvais dev.
5 ans chez Epitech m’ont appris à coder, mais je n’aime pas. Donc je ne suis pas le meilleur.
Pourtant, je couche la plupart de vos devs car cette faiblesse est mon plus grand atout pour mes clients.
Le fantasme du code parfait
On a tous croisé ce profil :
- 14 couches d’abstraction,
- 12 interfaces pour une seule implémentation,
- une architecture “future proof”,
- zéro feature visible côté client.
Techniquement, c’est impressionnant.
Conceptuellement, c’est propre.
Mais pendant ce temps-là, le client attend toujours que le bouton fonctionne.
Le client ne voit pas :
- ton injection de dépendances raffinée,
- tes design patterns bien placés,
- tes noms de variables exemplaires.
Il voit :
“Est-ce que ça marche ?”
À l’inverse : le cow-boy du code
Et puis il y a l’autre profil.
Celui qui écrit vite.
Parfois sale.
Parfois redondant.
Mais fonctionnel.
Le produit sort.
Le client est content.
Le business avance.
Et souvent, c’est ce code-là qui fait rentrer l’argent.
La vérité est entre les deux
Dire que seul le résultat compte serait faux.
La dette technique existe. Elle est réelle. Elle coûte cher.
Mais se cacher derrière “l’architecture parfaite” pour retarder la livraison, c’est aussi une forme d’évitement.
La loi de Pareto (que j’affectionne depuis mon adolescence) est utile ici :
20 % d’effort bien placé produisent 80 % de la valeur.
Les 80 % d’effort supplémentaires pour rendre le code “académiquement pur” ne produisent pas toujours 80 % de valeur supplémentaire.
Parfois, ils produisent 5 % de confort intellectuel.
Ce que le client achète vraiment
Un client n’achète pas :
- un pattern,
- une structure élégante,
- un repository bien organisé.
Il achète :
- une solution à un problème,
- un gain de temps,
- une réduction de coût,
- un avantage concurrentiel.
L’architecture est un moyen.
Pas une finalité.
Mais attention : “fonctionnel” n’est pas une excuse
Le discours inverse est tout aussi dangereux.
“Ça marche” n’est pas un argument suffisant si :
- personne ne peut maintenir le code,
- chaque modification casse autre chose,
- la scalabilité est impossible,
- le refactoring devient hors de prix.
Le code jetable en production est une bombe à retardement.
La vraie maturité consiste à savoir où mettre l’effort.
Une règle simple
Avant d’ajouter une couche d’abstraction, pose-toi trois questions :
- Est-ce que ce besoin existe vraiment aujourd’hui ?
- Est-ce que ça simplifie la maintenance future ?
- Est-ce que le client en tirera une valeur mesurable ?
Si la réponse est non aux trois…
Tu es peut-être en train de coder pour toi, pas pour le produit.
Ce que j’ai appris avec le temps
Un bon développeur n’est pas celui qui écrit le code le plus élégant.
C’est celui qui sait :
- livrer vite quand il faut,
- structurer quand c’est nécessaire,
- simplifier au lieu de complexifier,
- arbitrer entre vitesse et propreté,
- et surtout stopper son onanisme architectural.
Le code parfait n’existe pas.
Le code utile, oui.
Et dans un projet :
l’utilité doit toujours passer avant l’ego technique.
Arrêtez de réinventer la roue.
Et par pitié, arrêtez de réinventer la hache qui va couper du bois pour réinventer cette foutue roue.
Pissez du code qui tourne, pas du code qui brille
