Gains :
- Possibilité de mapper une base de code étranger couche par couche avec l'IA et de suivre une fonctionnalité de bout en bout
- Capacité à expliquer des fonctions complexes étape par étape et à surveiller le flux de données
- Possibilité de visualiser la description de l'IA comme une hypothèse et de vérifier les affirmations critiques dans le code
Les développeurs lisent le code plutôt que d’écrire du code. Lorsque vous démarrez un nouvel emploi, reprenez un service laissé par quelqu'un d'autre ou contribuez à une bibliothèque open source, votre première tâche est « que se passe-t-il ici ? est de trouver une réponse à la question. L’IA peut réduire cette tâche de découverte à quelques heures plutôt qu’à quelques semaines, mais seulement lorsqu’elle est utilisée avec les bonnes questions et un réflexe de vérification.
Dans cette unité, nous apprenons à utiliser l'IA comme un « guide de code » : cartographier une base de code étrangère, traduire une fonction complexe en langage simple, suivre un flux de données et comprendre comment utiliser une bibliothèque. La règle d’or ici est que l’explication de l’IA est une hypothèse ; vous le vérifiez avec le code lui-même.
Pourquoi l'annotation de code est-elle puissante mais risquée ?
Un LLM est très doué pour lire un morceau de code et le traduire en langage humain, par exemple « cette fonction actualise le jeton de session d'un utilisateur » ; parce qu’il a appris des modèles à partir de millions d’exemples similaires. C’est un énorme gain de temps, surtout avec des fonctions longues et imbriquées.
Voici le risque : le modèle indique parfois ce que le code semble faire, et non ce qu'il fait réellement. Si le nom de la variable est isAdmin mais que la logique interne est inversée, le modèle peut consulter le nom et extraire un résumé erroné. Par conséquent, avant de faire de cette déclaration la base de vos décisions critiques, vous devez vérifier visuellement le comportement allégué sur les lignes pertinentes. La description vous amène au bon endroit ; Le code a le dernier mot.
Attention : ne comptez pas le résumé « ce code fait X » d'IA comme une seule preuve dans une décision impliquant la sécurité ou le flux d'argent. Le résumé est une carte indiquant où chercher ; Vous donnez la confirmation dans le code.
Étapes pour mapper une base de code étranger
- Commencez au plus haut niveau. Tout d'abord, familiarisez-vous avec la structure des dossiers et les points d'entrée (principal, lancement d'application, routeur domestique). Demandez à l'IA "quelles sont les couches de l'application basées sur cette structure de répertoires ?" demander.
- Suivez une fonctionnalité de bout en bout. "Quels fichiers sont activés et dans quel ordre lorsque l'utilisateur se connecte ?" — regarder un seul flux est plus instructif que lire l'architecture entière.
- Localisez les termes. Demandez à l'IA des concepts spécifiques au projet ("tenant", "ledger", "job runner") et trouvez leurs équivalents dans le code.
- Vous avez simplifié la fonction complexe. Faites expliquer une longue fonction étape par étape, puis marquez ces étapes dans le code.
- Vérifier. Apportez un petit changement et effectuez des tests pour tester votre compréhension ; Le test vous indique immédiatement si votre compréhension est fausse.
Trois mini-étuis
Cas 1 — Le service hérité a été réduit de 2 jours à 3 heures. Un développeur a repris un service de rapprochement de paiements de 4 000 lignes auprès d'un collègue qui partait. L'IA a-t-elle résumé les modules et suivi un flux de paiement de bout en bout ? Il a personnellement vérifié deux fonctions critiques du code. La découverte, qui était estimée à 2 jours avec la « lecture aveugle » classique, a été réalisée en 3 heures environ avec la méthode d'IA vérifiée.
Cas 2 — Piège à nom trompeur. Une fonction s'appelait validateAndSave mais le résumé de l'IA disait "valide d'abord, puis enregistre". Lorsque le développeur est entré dans le code, il a vu que la sauvegarde avait été effectuée avant la vérification et que la vérification n'écrivait que dans le journal. C’était la véritable cause d’un ticket de bug en production. S'il n'y avait pas de validation dans le code, le faux résumé masquerait l'erreur.
Cas 3 — L'apprentissage des nouvelles bibliothèques est accéléré. L'équipe allait intégrer une bibliothèque de files d'attente de messages avec laquelle elle n'était pas familière. J'ai demandé à AI "comment configurer un consommateur dans cette bibliothèque, comment réessayer en cas d'erreur ?" Ils ont demandé et ont fait réaliser un échantillon ; Ensuite, ils ont comparé l'exemple avec la doc officielle et corrigé une différence (ancienne version API). Temps d’apprentissage réduit de moitié.
Quatre modèles copiables
Mappage de la base de code :
Vous trouverez ci-dessous la liste des répertoires/fichiers d'un projet. 1) Extraire les couches de l'application (entrée, logique métier, accès aux données, etc.). 2) Répertoriez le parcours de fichier possible d'une requête "{{example property}}". 3) Marquez les zones dont vous n'êtes pas sûr comme « doivent être vérifiées ». {{liste_répertoire}}
Description de la fonction (étape par étape) :
Divisez cette fonction en groupes de lignes et expliquez en turc simple ce que fait chaque groupe. Enfin : listez les entrées, les sorties, les effets secondaires (base de données/fichier/réseau) et les cas extrêmes possibles. Regroupez les comportements dont vous n'êtes pas sûr sous une rubrique SÉPARÉE « doit être vérifiée ».{{function}}
Suivi des flux de données :
D'où vient la valeur "{{variable/data}}", quelles transformations subit-elle, où est-elle écrite ? Créez une chaîne de flux en utilisant les noms de fonctions dans le code. Code associé : {{code_segments}}
Apprendre à utiliser la bibliothèque :
Je veux créer {{Purpose}} avec {{library}}. Donnez un exemple minimal et fonctionnel. Assurez-vous que chaque fonction que vous utilisez appartient réellement à cette bibliothèque ; si vous n'êtes pas sûr, cochez "vérifier à partir de la documentation officielle". Version : {{version}}.
Invite faible/Invite forte
Faible : "Expliquez ce code." (Que vous demandez-vous ? A quel niveau ? Que ferez-vous ?)
Strong : "Je reprends cette fonction et je vais y modifier la logique des nouvelles tentatives. Expliquez la fonction étape par étape, notamment en cas d'erreur, indiquez clairement combien de fois et à quel intervalle vous réessayez ; marquez les parties dont vous n'êtes pas sûr comme "doivent être vérifiées". [code]"
La version forte donne votre intention (je vais changer la logique de nouvelle tentative) et votre concentration ; de sorte que l'explication n'est pas un résumé général mais un guide utile.
Quête
L'IA fonctionne bien
Assurez-vous de vérifier
Résumé de l'architecture générale
Supprimer des calques
Séquence d'appel réelle
fonction complexe
Explication étape par étape
Logique inverse, effets secondaires
flux de données
Rédaction de la chaîne
Branches conditionnelles, chemins ignorés
Utilisation de la bibliothèque
Génération d'échantillons
Authenticité et version de l'API
Rien ne remplace la compréhension humaine
La description de l’IA ne remplace pas l’apprentissage ; ça l'accélère. Pour véritablement « posséder » une base de code, cela signifie en construire un modèle mental, et ce modèle ne s'adapte que lorsque vous lisez le code, apportez de petites modifications et voyez le résultat. Utilisez l’IA comme si un mentor vous disait « regardez ici, c’est important » – mais lisez où vous le voyez de vos propres yeux.
Astuce : Lorsque vous pensez comprendre une fonction, demandez à l’IA de « la résumer en une phrase » ; Comparez-le ensuite avec votre propre phrase. Si deux phrases se contredisent, soit vous, soit le modèle, avez manqué quelque chose – et vous le résolvez dans le code.
Erreurs courantes
- Considérez le résumé comme une preuve. Prendre une décision concernant le code sans vérifier la description, c'est tomber dans le piège des noms trompeurs.
- Coller des morceaux trop gros. Résumer 2 000 lignes à la fois donne des résultats superficiels et sujets aux erreurs ; diviser en morceaux.
- Sans préciser le but. Si vous ne dites pas « ce que vous allez faire », la description reste générale et ne se concentre pas sur votre activité.
- Ne pas valider l'instance de bibliothèque. Le modèle peut faire appel à une API obsolète ou inexistante ; Comparez avec le document officiel.
- Abandonner tout apprentissage. Travailler uniquement avec des résumés sans jamais lire la base de code vous laisse impuissant à la première vraie erreur.
En résumé
L'IA est un guide puissant pour explorer une base de code étrangère : cartographie l'architecture, simplifie les fonctions complexes, trace le flux de données, enseigne l'utilisation de la bibliothèque. Mais toute explication est une hypothèse. Expliquez clairement votre point de vue, décomposez-le, vérifiez dans le code et testez chaque affirmation critique que le modèle dit (et ne dit pas) "doit être vérifiée". Le guide est l’IA ; C'est vous qui lisez la carte et qui en portez la responsabilité.
Tâche de candidature
Choisissez un module que vous ne connaissez pas ou dont vous venez d'hériter. Tout d’abord, extrayez les couches et le parcours de fichiers d’une fonctionnalité avec le modèle « mappage de base de code ». Ensuite, expliquez étape par étape la fonction la plus critique de cette fonctionnalité à l'aide du modèle « Explication de fonction ». Enfin, vérifiez personnellement dans le code au moins deux assertions que le modèle a marquées comme « doivent être vérifiées » et notez si elles sont vraies ou fausses.
liste de contrôle
- [ ] Je traite la déclaration de l'IA comme une hypothèse et je la vérifie dans le code.
- [ ] Tout en expliquant le code, j'ajoute mon objectif et me concentre sur l'invite.
- [ ] Je résume la grande base de code en la divisant en parties.
- [ ] Je vérifie les affirmations critiques en ligne pour détecter les noms trompeurs/pièges à logique inverse.
- [ ] Je compare les exemples de bibliothèque avec la doc et la version officielles.
- [ ] J'utilise l'IA comme guide pour accélérer l'apprentissage, et non comme substitut à l'apprentissage.