On nous l’a tous répété : "Écris du Clean Code."
Et honnêtement, je suis tombé dans le piège comme beaucoup.
Je croyais que plus mon code était "propre", plus j’étais un bon développeur.
J’avais tort. Pas complètement, mais assez pour perdre beaucoup de temps.
Quand le pseudo Clean Code devient une obsession
Au début, tout allait bien. J’écrivais du code clair, bien indenté, avec des noms de variables explicites.
Mais plus j’essayais d’appliquer à la lettre certains exercices de pseudo Clean Code, plus mon code devenait abstrait et difficile à suivre.
Je voulais tout factoriser, tout généraliser.
Et à force, mon code est devenu si "propre" qu’il en était illisible.
Dans un petit projet, ça reste gérable.
Mais dans un vrai projet professionnel, avec des dizaines de fichiers et des centaines de lignes de code, ça devient vite un cauchemar à maintenir.
Le principe DRY mal appliqué
Le principe DRY (Don't Repeat Yourself) est expliqué dans le livre Clean Code de Robert C. Martin, que je recommande vivement à ceux qui ne l’ont pas encore lu.
Il encourage à éviter la duplication, ce qui paraît logique.
Le problème, c’est que beaucoup de développeurs, moi inclus, l’ont mal interprété.
Prenons un cas concret. Supposons qu’on développe une application de gestion de comptes utilisateurs :
// Version simple
function createUser(name, email) {
const user = { name, email, createdAt: new Date(), active: true };
console.log("User created:", user);
return user;
}
() {
admin = { name, email, : (), : , : };
.(, admin);
admin;
}




Commentaires