# 🌪️ Éviter le Chaos Technique — L'entropie guette toujours **Chaos technique** = dégradation naturelle de la qualité d'un système au fil du temps. **Entropie** croissante si aucune action pour l'en empêcher. > **Sans vigilance constante, tout système tend vers le désordre.** --- ## 🎯 Le principe ### Évolution naturelle d'un système sans discipline --- ### Système avec discipline anti-chaos > 💡 **L'invariant** : "Lutter contre l'entropie est un travail quotidien." --- ## 🧠 Pourquoi c'est crucial ? Sans discipline anti-chaos : - **Vélocité décroissante** (chaque feature plus lente) - **Bugs exponentiels** (complexité = surface d'erreur) - **Onboarding cauchemar** (nouveaux devs perdus) - **Réécriture inévitable** (coût massif) Avec discipline : - **Vélocité stable** (code maintenable) - **Bugs contrôlés** (simplicité = moins d'erreurs) - **Onboarding facile** (code lisible) - **Évolution fluide** (refactoring incrémental) --- ## 📊 Les 4 sources du chaos --- ## 🔍 Exemple concret : Évolution vers le chaos ### État initial : Code propre ```ts // V1: Simple et clair class UserService { constructor(private userRepo: IUserRepository) {} async createUser(data: CreateUserDto): Promise { const user = await this.userRepo.create(data); return user; } } ``` **État** : ✅ Propre, testable, clair. --- ### V5 : Premiers hacks ```ts // "Quick fix" pour feature urgente class UserService { constructor(private userRepo: IUserRepository) {} async createUser(data: CreateUserDto): Promise { const user = await this.userRepo.create(data); // TODO: Refactorer ça if (data.email.includes("premium")) { user.role = "PREMIUM"; } return user; } } ``` **État** : ⚠️ Dette technique mineure (TODO non traité). --- ### V10 : Dette accumulée ```ts // Hacks empilés class UserService { constructor( private userRepo: IUserRepository, private emailService: EmailService, // Nouveau couplage private stripeService: StripeService // Nouveau couplage ) {} async createUser(data: CreateUserDto): Promise { // Logique métier mélangée avec side effects const user = await this.userRepo.create(data); if (data.email.includes("premium")) { user.role = "PREMIUM"; // Side effect direct await this.stripeService.createCustomer(user); } // Email envoyé ici (devrait être séparé) await this.emailService.sendWelcome(user); // Analytics direct (couplage) analytics.track("user_created", { userId: user.id }); return user; } } ``` **État** : ❌ Multiples violations : - Single Responsibility violée - Couplage fort (Stripe, Email, Analytics) - Tests difficiles (dépendances multiples) --- ### V20 : Spaghetti complet ```ts // God class ingérable class UserService { // 15 dépendances constructor( private userRepo: IUserRepository, private emailService: EmailService, private stripeService: StripeService, private slackService: SlackService, private analyticsService: AnalyticsService // ... 10 autres ) {} async createUser(data: CreateUserDto): Promise { // 300 lignes de logique enchevêtrée // Validation inline if (!data.email || !data.name) throw new Error("Invalid"); // Business rules éparpillées if (data.email.includes("premium")) { // 50 lignes de logique premium } else if (data.referralCode) { // 40 lignes de logique referral } else if (data.companyId) { // 60 lignes de logique B2B } // Side effects partout await this.emailService.sendWelcome(user); await this.slackService.notify("#sales", "New user"); await this.stripeService.createCustomer(user); // Transactions manuelles try { await this.userRepo.create(user); } catch (error) { await this.rollback(); // Gestion d'erreur custom } return user; } // 20 autres méthodes mélangées async updateUser() { /* ... */ } async deleteUser() { /* ... */ } async sendPasswordReset() { /* ... */ } // ... } ``` **État** : 🔥 Chaos complet : - 300 lignes dans une méthode - 15 dépendances - Logique métier + side effects mélangés - Impossible à tester isolément - Modification = risque élevé de régression --- ## 🛡️ Stratégies anti-chaos ### 1. **Boy Scout Rule** > "Laisse le code plus propre que tu l'as trouvé." ```ts // AVANT (code legacy trouvé) function calc(x) { return x * 1.2 + 5; // Magic numbers } // APRÈS (amélioré en passant) const TAX_RATE = 1.2; const BASE_FEE = 5; function calculateTotal(amount: number): number { return amount * TAX_RATE + BASE_FEE; } ``` **Principe** : Micro-améliorations continues > refactoring massif. --- ### 2. **Refactoring incrémental** ```ts // Pas de Big Bang Rewrite // Découper UserService progressivement // Étape 1: Extraire la validation class UserValidator { validate(data: CreateUserDto): void { if (!data.email || !data.name) throw new Error("Invalid"); } } // Étape 2: Extraire les notifications class UserNotifier { async notify(user: User): Promise { await this.emailService.sendWelcome(user); await this.slackService.notify("#sales", "New user"); } } // Étape 3: Extraire la logique premium class PremiumUserService { async handlePremium(user: User): Promise { await this.stripeService.createCustomer(user); } } // UserService devient un orchestrateur class UserService { constructor( private userRepo: IUserRepository, private validator: UserValidator, private notifier: UserNotifier, private premiumService: PremiumUserService ) {} async createUser(data: CreateUserDto): Promise { this.validator.validate(data); const user = await this.userRepo.create(data); if (user.role === "PREMIUM") { await this.premiumService.handlePremium(user); } await this.notifier.notify(user); return user; } } ``` **Bénéfices** : - Chaque service testable isolément - Responsabilités séparées - Évolution sans risque --- ### 3. **Tests comme filet de sécurité** ```ts // Tests permettent le refactoring sans peur describe('UserService', () => { it('should create user', async () => { const userRepo = mock(); const service = new UserService(userRepo, ...); const user = await service.createUser({ email: 'test@test.com' }); expect(userRepo.create).toHaveBeenCalled(); expect(user).toBeDefined(); }); }); ``` **Règle** : Si pas de tests → refactoring = roulette russe. --- ### 4. **Code reviews systématiques** ``` Checklist review: ✅ Pas de duplication ? ✅ Responsabilités claires ? ✅ Testable ? ✅ Nommage explicite ? ✅ Complexité raisonnable ? ``` **But** : Détecter le chaos AVANT qu'il entre en prod. --- ### 5. **Métriques de qualité** ```bash # Complexité cyclomatique npx eslint --ext .ts --max-complexity 10 # Duplication npx jscpd src/ # Coverage npx jest --coverage ``` **Seuils** : - Complexité max : 10 - Duplication max : 5% - Coverage min : 80% --- --- ## 🧪 Plan d'action anti-chaos ### Phase 1 : Prévention (quotidien) ``` ✅ Boy Scout Rule à chaque commit ✅ Code review systématique ✅ Tests automatiques (CI/CD) ✅ Linter + formatter (automatique) ``` --- ### Phase 2 : Détection (hebdo) ``` ✅ Métriques de complexité ✅ Analyse de duplication ✅ Coverage report ✅ Tech debt review meeting ``` --- ### Phase 3 : Correction (sprint) ``` ✅ Refactoring incrémental (20% du sprint) ✅ Payer la dette ancienne (FIFO) ✅ Simplifier l'existant (pas que new features) ``` --- --- --- ## 🗺️ Carte mentale de synthèse --- ## 🚀 Résultat attendu En maîtrisant la lutte contre le chaos technique, tu deviens capable de : - **Maintenir** un code propre sur le long terme - **Détecter** la dette technique avant qu'elle explose - **Refactorer** sans peur (tests = filet) - **Prévenir** l'accumulation de complexité Et surtout : Tu cesses de subir la dégradation. **Tu maintiens l'ordre activement.** Sans vigilance, tout système tend vers le désordre. Avec discipline, le chaos est évitable.