Developpement

“Lisez la doc.” Mais quelle doc ? Celle écrite il y a 2 ans et obsolète depuis 18 mois ? Voici comment créer une documentation que les développeurs vont réellement lire et maintenir. Le problème : Doc obsolète ou inexistante Symptômes classiques # README.md (Last updated: 2021) ## Setup Run `npm install` (Mais le projet utilise pnpm depuis 2023) Ou pire : // Fichier: user.service.ts (500 lignes) // Commentaire: Aucun // README: "Le code se documente lui-même" Résultat : ...

Un bon développeur qui met 2 semaines à être productif = 2 semaines perdues + frustration. Voici comment passer à 2 jours avec un onboarding structuré. Le coût d’un mauvais onboarding Situation classique Jour 1 : Setup machine (bloqué sur accès) Jour 2 : Setup encore (doc obsolète) Jour 3 : Premier build (fail, dépendances) Jour 4 : Essayer de comprendre archi Jour 5 : Première PR (rejected, standards) ... Jour 10 : Enfin productif Coût : ...

“On doit changer ce endpoint mais 500 clients l’utilisent.” Le versioning d’API résout ce problème. Voici les stratégies qui fonctionnent vraiment en production. Le problème : Breaking changes Scénario classique // V1 API (1000 clients utilisent ça) GET /api/users/123 { "id": 123, "name": "Alice", "email": "alice@example.com" } // V2 : On veut séparer prénom/nom GET /api/users/123 { "id": 123, "firstName": "Alice", // Breaking change! "lastName": "Smith", "email": "alice@example.com" } // Résultat : 1000 clients cassés Besoin : Faire évoluer l’API sans casser l’existant. ...

Code review : rituel quotidien qui peut faire progresser l’équipe… ou créer de la frustration. Voici comment en faire un outil de croissance plutôt qu’un goulot d’étranglement. Le problème : Code Review frustrantes Symptômes classiques Pour l’auteur : 09h00 : Crée PR 16h30 : Pas de review Lendemain 14h : Enfin review 16h00 : Corrige commentaires Lendemain 11h : 2ème review avec nouveaux comments ... 5 jours pour merger 200 lignes Pour le reviewer : ...

“Il faut tout réécrire !” Non. Voici comment améliorer progressivement une codebase legacy sans Big Bang rewrite (qui échoue 80% du temps). Le mythe de la réécriture La proposition classique "Ce code est pourri, on va tout réécrire en 6 mois." Réalité : 6 mois → 18 mois Budget x3 Features manquantes Bugs nouveaux Parfois : Abandon du projet Exemples célèbres d’échecs : Netscape (réécriture → mort de l’entreprise) Basecamp (réécriture abandonnée) Strangler Fig Pattern : La solution Principe Remplacer progressivement l’ancien système par du nouveau code, fonctionnalité par fonctionnalité. ...

Vous en avez marre des merge conflicts monstres ? Des feature branches qui durent 3 semaines ? Des hotfixes qui cassent tout ? Il existe une alternative plus simple : le Trunk-Based Development. Le problème avec Git Flow Git Flow : Le standard qui ne scale pas ┌─────────┐ │ master │──────────────────────────── └─────────┘ merge merge │ ┌────▼────┐ │ develop │─────────────────── └─────────┘ merge merge │ ┌────▼────────┐ │ feature/123 │───────── └─────────────┘ Problèmes réels : ...

WebAssembly (Wasm) promet des performances natives dans le navigateur. Après l’avoir utilisé en production sur plusieurs projets, voici ce qui fonctionne vraiment et ce qui relève du marketing. WebAssembly en 2 minutes Qu’est-ce que c’est ? WebAssembly est un format binaire exécutable dans les navigateurs modernes, offrant des performances proches du code natif. ┌─────────────┐ │ Rust/C/C++ │ │ Go, etc. │ └──────┬──────┘ │ Compile ┌──────▼──────┐ │ .wasm │ ← Binaire compact └──────┬──────┘ │ Load ┌──────▼──────┐ │ Browser │ ← Exécution rapide └─────────────┘ Promesses marketing vs Réalité Marketing : “Wasm est 20x plus rapide que JavaScript !” ...

GraphQL fait beaucoup parler depuis quelques années, présenté comme le successeur de REST. Mais est-ce vraiment le cas ? Après avoir implémenté les deux approches en production, voici un guide pragmatique pour faire le bon choix. La promesse GraphQL vs la réalité terrain Ce qu’on vous vend : “Plus d’overfetching/underfetching” “Un seul endpoint pour tout” “Les clients demandent exactement ce dont ils ont besoin” La réalité en production : Complexité de mise en cache accrue N+1 queries si pas bien géré Courbe d’apprentissage pour l’équipe Coût de monitoring et debugging plus élevé Quand REST est le meilleur choix 1. APIs publiques et third-party REST excelle pour les APIs publiques car : ...

Stratégies du livre “En quête d’expérience”, chapitre “Apprendre en continu”. “React 19, Astro, Bun, Deno 2.0, HTMX…” Comment suivre sans devenir fou ? Réponse : Vous ne pouvez pas tout suivre. Voici comment prioriser. Le mythe de la course à la nouveauté FOMO tech : Dev stressé : - Nouveau framework chaque mois - "Je dois tout apprendre !" - Burnout en 6 mois Réalité : Dev efficace : - Master fundamentals (80% valeur) - Learn new tech si besoin job (20%) - Ignore hype passagère La matrice d’apprentissage Quadrant 1 : Urgent + Important Apprendre maintenant : - Tech utilisée au job actuel - Gaps blocking progression - Certifications requises promotion Exemple : Team migre vers TypeScript → Apprendre TS maintenant (not optional) Quadrant 2 : Pas urgent + Important Investissement long-terme : - Fundamentals (algorithms, architecture) - Soft skills - Domain knowledge (finance, health, etc.) Exemple : System design → Pas urgent, mais critique pour senior+ Quadrant 3 : Urgent + Pas important Distractions déguisées : - Hype du moment (souvent) - Tech cool mais pas utilisée - Frameworks nouveaux sans adoption Exemple : Framework JS #247 cette année → Wait & see si adoption réelle Quadrant 4 : Ni urgent ni important Ignore complètement : - Tech obsolètes - Sujets hors carrière path - Rabbit holes inutiles Plan formation efficace (5-7h/semaine) Lundi-Vendredi (1h/jour) : ...

Inspiré du livre “En quête d’expérience”, chapitre “Pivoter intelligent”. “J’ai 8 ans en Java, je veux passer à Rust. Je recommence junior ?” Non. Voici comment transitionner intelligemment. Les transitions les plus courantes Frontend → Backend (+15-25% salaire) Skills transférables : HTTP/REST APIs (côté client → côté serveur) Databases (queries → schema design) Authentication (consommer → implémenter) Gap à combler (3-6 mois) : Server-side architecture Databases (SQL approfon di) Security best practices Infrastructure basics Roadmap : ...