Principes de conception au quotidien
Acronymes de survie et gestes quotidiens de qualité.
Objectifs
À la fin de cette leçon, vous saurez :
- appliquer DRY, KISS, YAGNI avec discernement ;
- nommer, limiter les effets de bord, gérer les erreurs explicitement ;
- reconnaître la sur-ingénierie.
Les trois acronymes de survie
DRY — Don't Repeat Yourself : chaque connaissance vit à un seul endroit.
// ❌ le taux TVA vit dans 4 endroits
// ✅
const TAUX_TVA = 0.20;
function ttc(ht) { return ht * (1 + TAUX_TVA); }
Attention : DRY parle de connaissances, pas d'apparences. Deux boucles similaires qui évolueront pour des raisons différentes ne doivent PAS être fusionnées artificiellement.
KISS — Keep It Simple : la solution simple qui marche bat l'élégante qui échoue.
Besoin : compter les clics sur un bouton.
KISS : un compteur en mémoire.
Sur-ingénierie : un service d'analytics + queue Redis + dashboard.
YAGNI — You Aren't Gonna Need It : n'écrivez pas ce dont vous n'avez pas encore besoin. Le paramètre mode, la configuration optionnelle, « ça servira peut-être » → supprimez jusqu'à preuve du besoin réel.
Les gestes quotidiens
// Noms explicites > commentaires
const d = new Date(u.c); // ❌
const dateCreation = new Date(user.createdAt); // ✅
// Constantes > valeurs magiques
if (age >= 18) ... // ❌ 18 c'est quoi ?
const AGE_MAJEURITE = 18; // ✅
// Erreurs explicites, jamais avalées
try { await sauvegarder(); }
catch (e) { /* rien */ } // ❌ le bug devient invisible
catch (e) { logger.error(e); throw e; } // ✅ journalisé ET propagé
// Effets de bord localisés
// Une fonction qui calcule ne modifie rien ; une qui modifie ne se cache pas.
La Law of Demeter
Ne parlez qu'à vos voisins immédiats.
const ville = commande.client.adresse.ville; // ⚠️ chaîne fragile
const ville = commande.villeDeLivraison(); // ✅ la commande répond
Chaque . supplémentaire crée un couplage au chemin interne d'un autre objet : changer la structure casse tous les appelants. Une méthode intermédiaire absorbe le changement localement.
Sur-ingénierie : le piège du débutant enthousiaste
Symptômes :
- abstractions sans deuxième implémentation ;
- configuration là où une constante suffit ;
- design patterns plaqués « pour apprendre » ;
- couches qui ne font que relayer.
Un design pattern n'est pas automatiquement une amélioration.
La règle : introduire une abstraction quand la DOULEUR apparaît (duplication réelle, besoin réel de substitution), pas par anticipation. Vous refactorerez vers le pattern en quelques minutes quand il sera justifié — votre historique Git rend cette évolution sûre.
Exercice
- Classez : « je crée un AbstractFactoryFactory pour deux types de notifications » — quel principe bafoué ?
- Trouvez trois valeurs magiques dans votre projet todo et extrayez-les.
- Un try/catch vide existe-t-il chez vous ? Corrigez-le.
Résumé
- DRY sur les connaissances ; KISS par défaut ; YAGNI contre l'anticipation.
- Noms clairs, constantes nommées, erreurs journalisées puis propagées.
- L'abstraction suit la douleur, elle ne la précède pas.
Correction disponibleCherchez d’abord par vous-même.Voir la correction
Correction
Réponses détaillées
Question 1. YAGNI (besoin non prouvé) et KISS (complexité injustifiée). Deux types de notifications = un objet de configuration ou deux fonctions ; une usine à usines arrive à trois implémentations réelles et documentées.