# ✨ Design by Simplicity — Simple > Complexe **Design by Simplicity** = privilégier la **solution la plus simple** qui résout le problème. Complexité uniquement si nécessaire. > **"Simplicity is the ultimate sophistication."** — Léonard de Vinci --- ## 🎯 Le principe > 💡 **L'invariant** : "La meilleure solution est la plus simple qui fonctionne." --- ## 🧠 Pourquoi c'est crucial ? Complexité inutile : - ❌ **Maintenance cauchemar** (plus de code = plus de bugs) - ❌ **Onboarding difficile** (courbe d'apprentissage) - ❌ **Vélocité réduite** (changements lents) - ❌ **Over-engineering** (résoudre des problèmes inexistants) Simplicité : - ✅ **Maintenance facile** (moins de code = moins de bugs) - ✅ **Onboarding rapide** (code compréhensible) - ✅ **Vélocité élevée** (changements rapides) - ✅ **Focus sur la valeur** (pas de gold plating) --- ## 📊 Échelle de complexité --- ## 🔍 Exemple concret : Feature Flags ### ❌ Over-engineered (complexe sans raison) ```ts // Solution complexe dès le début interface IFeatureFlagProvider { isEnabled(flag: string, context: FlagContext): Promise; } class LaunchDarklyProvider implements IFeatureFlagProvider { async isEnabled(flag: string, context: FlagContext): Promise { const client = await this.initClient(); return client.variation(flag, context, false); } } class DatabaseProvider implements IFeatureFlagProvider { async isEnabled(flag: string, context: FlagContext): Promise { const config = await this.db.query( "SELECT * FROM feature_flags WHERE name = ?", [flag] ); return this.evaluate(config, context); } } class FeatureFlagService { constructor( private providers: IFeatureFlagProvider[], private cache: ICache, private metrics: IMetrics ) {} async isEnabled(flag: string, context: FlagContext): Promise { // Cache check const cached = await this.cache.get(`flag:${flag}`); if (cached !== null) return cached; // Try providers in order for (const provider of this.providers) { try { const result = await provider.isEnabled(flag, context); await this.cache.set(`flag:${flag}`, result, 60); this.metrics.increment("feature_flag.check", { flag, result }); return result; } catch (error) { this.metrics.increment("feature_flag.error", { flag }); continue; } } return false; } } ``` **Problèmes** : - 100 lignes de code pour 0 usage - 3 providers différents (besoin ?) - Cache, metrics, fallback (nécessaire ?) - Temps de dev : 1 semaine --- ### ✅ Simple (commence minimal) ```ts // V1: Simple object const FEATURE_FLAGS = { NEW_CHECKOUT: true, DARK_MODE: false, BETA_FEATURE: false, }; function isEnabled(flag: keyof typeof FEATURE_FLAGS): boolean { return FEATURE_FLAGS[flag]; } // Usage if (isEnabled("NEW_CHECKOUT")) { // ... } ``` **Bénéfices** : - 10 lignes de code - 0 dépendance - Temps de dev : 5 minutes - **Suffit pour 99% des cas de départ** --- ### 🔄 Évolution si besoin prouvé ```ts // V2: Si besoin de config dynamique // (après avoir mesuré que hardcoded ne suffit plus) const flags = await fetch("/api/flags").then((r) => r.json()); function isEnabled(flag: string): boolean { return flags[flag] ?? false; } ``` **Quand complexifier ?** : - ✅ Besoin de A/B testing par user - ✅ Besoin de rollout progressif (5% → 50% → 100%) - ✅ Multiple environnements (dev/staging/prod) **Quand NE PAS complexifier ?** : - ❌ "Au cas où on en aurait besoin un jour" - ❌ "C'est une bonne pratique" - ❌ "J'ai vu ça chez Google" --- ## 🛠️ Principes KISS ### KISS = Keep It Simple, Stupid ``` 1. Résoudre le problème ACTUEL, pas futur 2. Commencer par la solution la plus simple 3. Complexifier seulement si besoin prouvé 4. Supprimer le code inutile ``` --- ### YAGNI = You Aren't Gonna Need It ``` ❌ "On va ajouter un système de plugins au cas où" ✅ "On ajoutera des plugins quand on aura 2 cas d'usage" ❌ "Préparons pour 10M users dès maintenant" ✅ "Optimisons quand on atteindra 100k users" ``` --- ### Occam's Razor (Rasoir d'Ockham) ``` Entre 2 solutions qui marchent, choisir la plus simple. Solution A: 500 lignes, 3 dépendances Solution B: 50 lignes, 0 dépendance → Choisir B (si elle résout le problème) ``` --- ; } class EmailChannel implements INotificationChannel {/* ... */} class SmsChannel implements INotificationChannel {/* ... */} class PushChannel implements INotificationChannel {/* ... */} class NotificationService { constructor(private channels: INotificationChannel[]) {} async sendToAll(message: Message, recipient: Recipient) { await Promise.all( this.channels.map(c => c.send(message, recipient)) ); } }`, description: "Système générique pour envoyer... juste des emails" }, problem: "100 lignes de code pour 1 seul cas d'usage (email)", solution: "Commencer simple, abstraire si 2e cas apparaît", goodExample: { code: `// V1: Juste email (besoin actuel) async function sendEmail(to: string, subject: string, body: string) { await emailClient.send({ to, subject, body }); } // V2 (si besoin SMS apparaît): ALORS abstraire interface INotificationChannel {/* ... */}`, description: "Abstraire quand 2e cas d'usage apparaît" } }, { title: "Configuration excessive", badExample: { code: `// Config pour TOUT { "app": { "name": "MyApp", "version": "1.0.0", "port": 3000, "host": "localhost", "cors": { "enabled": true, "origins": ["*"], "methods": ["GET", "POST"] }, "cache": { "enabled": true, "ttl": 3600, "maxSize": 1000 }, // ... 50 autres options } }`, description: "50 options configurables 'au cas où'" }, problem: "Complexité de config, options jamais utilisées, bugs de config", solution: "Seulement ce qui DOIT varier entre environnements", goodExample: { code: `// Config minimale (ce qui varie vraiment) { "DATABASE_URL": "postgres://...", "REDIS_URL": "redis://...", "PORT": 3000 } // Reste en hardcode (defaults sensibles) const CORS_ORIGINS = ['*']; const CACHE_TTL = 3600;`, description: "Config pour ce qui varie, constantes pour le reste" } }, { title: "Framework maison pour 1 projet", badExample: { code: `// "On va créer notre propre framework MVC" class Router {/* 500 lignes */} class Controller {/* 300 lignes */} class Model {/* 400 lignes */} class View {/* 200 lignes */} class Middleware {/* 300 lignes */} // 1700 lignes de framework // Pour 1 projet avec 10 endpoints`, description: "Réinventer Express/Fastify" }, problem: "Maintenance éternelle, bugs, features manquantes", solution: "Utiliser un framework mature", goodExample: { code: `import express from 'express'; const app = express(); app.get('/users', getUsers); app.post('/users', createUser); // ... 8 autres routes // 20 lignes de code au lieu de 1700`, description: "Utiliser l'existant, focus sur la valeur métier" } } ]} /> --- ## 🧪 Checklist simplicité ### Avant d'écrire du code ``` ❓ Quel est le problème EXACT à résoudre ? ❓ Quelle est la solution LA PLUS SIMPLE ? ❓ Cette complexité résout un problème réel ou imaginé ? ❓ Ai-je BESOIN de cette abstraction maintenant ? ``` --- ### Pendant le code review ``` ✅ Ce code est-il lisible par un junior ? ✅ Peut-on supprimer des lignes sans perdre de valeur ? ✅ Les abstractions sont-elles justifiées par 2+ cas d'usage ? ✅ Y a-t-il du code "au cas où" ? ``` --- ### Refactoring existant ``` 🔍 Quelles abstractions ne servent qu'à 1 cas ? 🔍 Quel code n'est jamais exécuté ? (dead code) 🔍 Quelles configs ne varient jamais ? 🔍 Quelles dépendances sont inutiles ? → Supprimer tout ça ``` --- 500ms OU traffic > 1000 req/s OU données rarement changent", explanation: "Besoin prouvé par metrics", }, { key: "Cache simple", value: "Si besoin : Map en mémoire (20 lignes). Pas Redis tout de suite.", explanation: "Commencer simple, complexifier si Map insuffisant", }, ], explanation: "Ne pas optimiser sans metrics. Commencer simple.", }, { id: "auth-system", title: "Système d'authentification", context: "MVP avec 10 users. Options : Auth0 (payant), custom JWT, sessions.", questions: [ "Quelle solution pour MVP ?", "Évolution ?", "Critères de choix ?", ], solution: [ { key: "MVP", value: "Sessions simples (express-session). 10 lignes de code.", explanation: "10 users = complexité inutile", }, { key: "Scaling", value: "Si > 1000 users : JWT. Si besoin SSO : Auth0.", explanation: "Complexifier quand le besoin apparaît", }, { key: "Auth0 direct ?", value: "NON pour MVP. Coût $ + lock-in. Overkill pour 10 users.", explanation: "YAGNI : pas de solution enterprise pour MVP", }, { key: "Principe", value: "Commencer simple (sessions), migrer si besoin prouvé", explanation: "Évolution incrémentale basée sur données", }, ], explanation: "Adapter la complexité au stade du projet.", }, ]} /> --- 3", }, ], }, { question: "Pourquoi la simplicité est importante ?", options: [ { text: "Ça fait moins professionnel", isCorrect: false, explanation: "Au contraire, simplicité = sophistication", }, { text: "Maintenance facile, moins de bugs, vélocité élevée", isCorrect: true, explanation: "Exact ! Moins de code = moins de problèmes", }, { text: "C'est obligatoire en Agile", isCorrect: false, explanation: "Pas une obligation Agile, mais un principe d'ingénierie", }, ], }, ]} /> --- ## 🗺️ Carte mentale de synthèse --- ## 🚀 Résultat attendu En maîtrisant Design by Simplicity, tu deviens capable de : - **Résister** à la tentation de l'over-engineering - **Commencer** simple, complexifier seulement si besoin prouvé - **Supprimer** du code inutile sans regret - **Évaluer** la complexité : nécessaire ou accidentelle ? Et surtout : Tu cesses de coder pour des problèmes imaginés. **Tu codes pour des problèmes réels.** La meilleure solution est la plus simple qui fonctionne. La sophistication ultime, c'est la simplicité.