Le vrai problème

La plupart des devs savent écrire du code. Peu savent le lire.

Pourtant, un développeur passe en réalité beaucoup plus de temps à lire du code existant qu’à en écrire de nouveau. Comprendre un codebase inconnu, c’est la compétence quotidienne numéro 1 — et elle s’apprend rarement en cours.

Un dev avec impact comprend rapidement n’importe quel codebase, qu’il l’ait écrit ou non. Il suit les flux, repère les patterns, et anticipe les effets de bord avant même d’avoir modifié une ligne.

---

Les entry points : par où commencer

Face à un codebase inconnu, la première erreur c’est de se perdre dans les utilitaires ou les helpers. Commence toujours par les entry points — les portes d’entrée du système.

Pour une app web :

• index.ts / main.ts / app.ts — l’amorçage
• Les routes ou les contrôleurs — ce que le système fait
• Le package.json — les dépendances révèlent les intentions

---

Suivre le flux d’exécution

Une fois l’entry point trouvé, suis le chemin critique — la séquence d’appels pour la fonctionnalité principale.

Exemple concret : dans une API REST, une requête POST /orders :

Route handler → validation → service → repository → base de données

Tu n’as pas besoin de comprendre tout le code. Tu as besoin de comprendre ce chemin-là d’abord.

Technique pratique : utilise les breakpoints ou ajoute des console.log temporaires aux intersections clés pour confirmer ta compréhension avant de faire confiance à ta lecture statique.

---

Repérer les patterns

Le code est rarement original. La plupart des codebases utilisent un sous-ensemble de patterns répétitifs. Quand tu en reconnais un, tu économises l’effort cognitif de le redécouvrir.

Les patterns les plus fréquents en JS/TS :

Pattern	Ce qu’il signale
Factory	Création d’objets avec logique
Repository	Abstraction de la source de données
Observer / EventEmitter	Découplage entre producteur et consommateur
Middleware chain	Transformation séquentielle (Express, Koa)
Strategy	Comportement interchangeable

---

Anticiper les effets de bord

C’est là que les devs intermédiaires se brûlent. Une modification “simple” casse quelque chose d’inattendu parce qu’ils n’ont pas anticipé les effets de bord.

Ce qu’il faut chercher avant de modifier :

1. Qui appelle cette fonction ? — cherche les références (Cmd+Shift+F sur le nom)
2. Est-ce qu’elle mute un état global ? — méfie-toi des variables module-level, des singletons, des stores
3. Est-ce qu’elle a des effets asynchrones ? — les Promises non-awaited, les callbacks, les events

// ⚠️ Ce code a un effet de bord silencieux
function updateUser(user: User) {
  user.updatedAt = new Date(); // mutation de l'objet original
  return db.save(user);
}

// ✅ Version sans effet de bord
function updateUser(user: User) {
  const updated = { ...user, updatedAt: new Date() };
  return db.save(updated);
}

---

Exercice pratique

Prends un repo open source que tu utilises (React, Express, Prisma…) et :

1. Localise l’entry point principal
2. Choisis une feature connue (ex: express.get())
3. Suis le call stack jusqu’à la logique core sans regarder la doc
4. Note les patterns que tu reconnais