Parent : [[INDEX-IA]]

Code — Lire et débugger : flux de données, hypothèses, bisect mental

Pattern — Lire du code inconnu : chercher le flux de données, pas la structure

Problème : Lire un codebase inconnu fichier par fichier prend des heures pour une compréhension superficielle.

Solution : Tracer le chemin d'une donnée réelle de l'entrée à la sortie. Trouver le point d'entrée principal, suivre une seule variable clé jusqu'à sa mutation finale. Ignorer les helpers et utils dans un premier passage.

Exemple : Dans une API inconnue : trouver le premier router.post('/...'), suivre le body jusqu'à la DB. Tout le reste est secondaire.

Pattern — Détecter un bug sans exécuter : chercher les hypothèses implicites

Problème : Relire du code ligne par ligne sans méthode ne trouve pas les bugs, ça les confirme.

Solution : Identifier toutes les hypothèses que le code fait sans les vérifier : "cet array n'est jamais vide", "cette clé existe toujours", "cette fonction retourne toujours un string". Concentrer l'attention sur les boundary conditions : index 0, liste vide, null, string vide, concurrence.

Exemple : user.address.city.toLowerCase() — trois hypothèses non vérifiées. Bug garanti en prod dès qu'un user n'a pas d'adresse.

Pattern — Détecter la source d'un bug : bisect mental

Problème : Débugger en lisant tout le code depuis le début est O(n), inefficace pour des bases larges.

Solution : Binary search mentale : trouver le point médian entre "l'entrée est correcte" et "la sortie est incorrecte", tester si l'état intermédiaire est correct. Couper la moitié saine, répéter. 5 itérations localisent un bug dans 100 fonctions.

Exemple : API retourne un mauvais total → est-ce le calcul en DB ou en application ? Logger la valeur brute de la DB. Si correcte → bug applicatif. Si incorrecte → bug SQL ou données.

Pattern — Lire un PR inconnu efficacement

Problème : Lire un diff ligne par ligne noie le reviewer dans le bruit et rate les vrais risques.

Solution : Commencer par les fichiers de config/schema/migration. Puis les interfaces publiques. Puis les tests. Lire le code d'implémentation en dernier. Un PR sans nouveaux tests sur un chemin critique = red flag immédiat.

Exemple : Migration DB dans un PR → regarder le fichier migration en premier. Si elle est irréversible (DROP COLUMN) sans feature flag → bloquer avant tout le reste.