Inspecter une base de code inconnue
Utilise IBM Bob pour comprendre rapidement une application inconnue, notamment son objectif, la structure du projet, l'architecture, le tech stack, les composants clés, la couverture de tests et le modèle de déploiement. Sans dépendre d'une documentation obsolète ni attendre tes coéquipiers.
Se rendre productif dans une base de code inconnue implique généralement des heures de lecture de code, de recherche de documentation et de questions aux coéquipiers. Dans ce tutoriel, tu utilises Bob en mode Ask pour interroger systématiquement la base de code Galaxium Travels et en extraire une image complète de l'application : son objectif et son architecture, le tech stack, les composants clés, la couverture des tests unitaires et d'intégration, et le modèle de déploiement. Tu passes ensuite en mode Agent pour sauvegarder tout ce que Bob a découvert dans une référence Markdown persistante que toute ton équipe peut utiliser.
Galaxium Travels est une application intentionnellement complexe, de style réel, avec un frontend React, un backend Python FastAPI et un service d'inventaire Java Spring Boot. Cela en fait un candidat idéal pour ce workflow.
La sortie de Bob varie selon l'état actuel de la base de code. Considère les exemples de ce tutoriel comme des points de départ représentatifs, pas comme des transcriptions exactes. Utilise-les pour calibrer tes propres prompts et affiner les résultats.
Fonctionnalités clés que tu vas apprendre
- Mode Ask : Explorer et analyser le code sans que Bob ne modifie aucun fichier.
- Mode Agent : Laisser Bob écrire des fichiers de façon autonome pour conserver les artefacts générés dans ton projet.
- Context mentions : Référencer des fichiers
et dossiers spécifiques avec
@pour donner à Bob un périmètre d'analyse précis. /init: Initialiser le contexte du projet pour que Bob comprenne les conventions de la base de code avant de commencer à poser des questions.
Prérequis
Pour suivre ce tutoriel, tu as besoin des éléments suivants :
- Bob IDE installé.
- Git installé localement.
- Maîtrise des bases de Bob. Si tu es nouveau sur Bob, commence par le tutoriel de démarrage rapide.
Configurer ton workspace
Cloner le dépôt Galaxium Travels
Dans ton terminal, clone le dépôt d'exemple :
git clone https://github.com/IBM/galaxium-travels.gitOuvrir le projet d'exemple
Dans le Bob IDE, ouvre le dossier galaxium-travels que tu viens de cloner. Si Bob te
demande « Do you trust the authors of the files in the folder? », clique sur Yes, I trust
the authors.
Ouvrir l'interface de chat de Bob
Si l'interface de chat n'est pas déjà ouverte, clique sur l'icône Bob dans la barre de navigation ou utilise le raccourci Option + Command + B (Mac) ou Ctrl + Alt + B (Windows).
Initialiser le contexte du projet
Bob est en mode Agent par défaut au démarrage. Avant de changer de mode, exécute la
commande /init pour que Bob lise le projet et génère les fichiers de contexte AGENTS.md
qu'il utilise dans les interactions suivantes.
/initSi l'approbation automatique est désactivée, Bob demande la permission de lire des fichiers
et d'écrire les fichiers AGENTS.md. Approuve chaque demande. Bob crée un AGENTS.md à
la racine et un dossier .bob/ avec une configuration spécifique à chaque mode.
Vérifie le AGENTS.md généré pour confirmer que Bob a correctement identifié la structure
multi-services du dépôt.
Passer en mode Ask
Sélectionne Ask dans le sélecteur de mode sous le champ de saisie du chat, ou tape
/ask pour changer de mode. Le mode Ask est strictement en lecture seule. Bob analyse
les fichiers mais ne peut rien créer ni modifier, ce qui en fait le bon mode pour tout
le travail d'exploration de ce tutoriel.
Comprendre l'objectif de l'application et la structure du projet
Commence par la question la plus large : que fait cette application, et comment est
organisée la base de code ? Bob lit la structure du projet et les fichiers clés, comme
README.md, package.json, requirements.txt, les fichiers de build et autres fichiers
de configuration. Bob produit un résumé concis sans que tu aies à parcourir manuellement
chaque répertoire.
En mode Ask, saisis le prompt suivant :
What is the purpose of this application? Describe the project structure,
the high-level architecture, and the main responsibilities of each top-level
directory.Bob lit l'arborescence de fichiers et les points d'entrée clés, puis produit une sortie qui comprend :
- L'objectif de l'application
- Les responsabilités des répertoires de premier niveau
- Un résumé du contenu de chaque répertoire de premier niveau
- Un diagramme d'architecture de haut niveau
Analyser le tech stack
Une fois la structure de haut niveau clarifiée, approfondis les technologies exactes utilisées. Ce prompt est utile quand tu dois comprendre les outils de build, évaluer les choix de dépendances ou estimer la portée des mises à jour.
En mode Ask, saisis le prompt suivant :
Analyze the tech stack for the entire application. For each service, list the
programming language, runtime version requirements, framework, key libraries,
database, and build/test tooling.Bob inspecte les fichiers de dépendances et de configuration de chaque service, puis produit une sortie qui comprend :
- Une analyse détaillée du tech stack pour chaque service
- L'identification du framework de tests end-to-end
- Les outils supplémentaires du stack CI/CD et des scripts de déploiement
- Un diagramme « Stack at a Glance » qui résume visuellement le tech stack sur tous les services et couches
Cartographier les composants clés
Comprendre le tech stack te dit ce qu'utilise une base de code ; comprendre les composants clés te dit comment elle fonctionne. Ce prompt demande à Bob de tracer les frontières des composants et les flux de données sur les trois services, ce qui est particulièrement utile avant d'effectuer des modifications qui traversent les frontières des services.
En mode Ask, saisis le prompt suivant avec des context mentions pour pointer Bob vers les fichiers les plus pertinents :
Identify the key components of this application and explain how they interact.
Reference @booking_system_frontend/src/services,
@booking_system_backend/server.py,
@booking_system_backend/services,
@booking_system_backend/models.py,
and @booking_system_inventory_hold_service/src/main/java/com/galaxium/holdservice.
Describe the component responsibilities, the data flow for the booking
lifecycle, and any cross-service contracts I need to know before modifying
the codebase.Bob trace la chaîne d'interaction et produit une sortie qui contient :
- Les responsabilités détaillées du frontend, de l'API backend, de la couche base de données et du service hold Java
- Un diagramme des deux flux du cycle de vie de réservation avec les interactions des composants annotées
- Un résumé des cinq contrats inter-services à connaître avant d'apporter des modifications
- Une carte d'interaction des composants
Évaluer la couverture des tests unitaires
Avant d'ajouter des fonctionnalités ou de refactoriser, tu dois savoir ce que couvre la suite de tests existante et où se trouvent les lacunes. Ce prompt demande à Bob de lire les fichiers de tests et de produire une évaluation de la couverture sans exécuter les tests.
En mode Ask, saisis le prompt suivant :
Analyze the unit test suites across all three services. Reference
@booking_system_backend/tests,
@booking_system_inventory_hold_service/src/test,
and @booking_system_frontend/src.
For each service, describe what is tested, which testing framework is used,
what the test structure looks like, and identify any obvious gaps where
critical logic appears to be untested.Bob lit les fichiers de tests et produit une analyse détaillée de la suite de tests qui comprend :
- Le framework de tests, les classes testées, le nombre de tests par classe et ce qui est vérifié par classe pour chaque service
- Les lacunes critiques dans les tests
- La couverture de tests manquante pour la logique métier critique
Évaluer la couverture des tests d'intégration et end-to-end
Les tests unitaires indiquent si les composants individuels fonctionnent en isolation ; les tests d'intégration et end-to-end indiquent si les services fonctionnent correctement ensemble. C'est particulièrement important pour Galaxium Travels, car le flux de confirmation de réservation s'étend sur les trois services.
En mode Ask, saisis le prompt suivant :
Analyze the end-to-end and integration test coverage. Reference
@tests_e2e and any cross-service test fixtures you can identify.
Describe which cross-service flows are covered, which are not, what test
infrastructure is required to run the suite, and what the tests assert
at the boundary level.Bob lit la suite de tests end-to-end et génère une analyse détaillée de la couverture qui comprend :
- L'infrastructure de tests et les prérequis pour exécuter la suite
- Les smoke tests
- Les décisions clés en matière d'infrastructure
- Les flux inter-services couverts et non couverts
- Les assertions des tests au niveau des frontières
Examiner le modèle de déploiement
Comprendre comment une application est déployée (ses plateformes cibles, la stratégie de conteneurisation et l'automatisation de l'infrastructure) est indispensable avant de rejoindre un projet comme contributeur ou avant d'exécuter l'application ailleurs que sur ton ordinateur.
En mode Ask, saisis le prompt suivant :
Analyze the deployment model for this application. Reference
@docker-compose.yml, @deployment_scripts, @terraform, @.github/workflows,
and the deployment documentation in @docs.
Describe the supported deployment targets, how each service is containerized,
what infrastructure is provisioned, and how CI/CD is configured.Bob lit les artefacts de déploiement et produit une analyse du modèle de déploiement. L'analyse comprend :
- Les cibles de déploiement prises en charge
- La stratégie de conteneurisation pour chaque service
- Les détails de provisionnement de l'infrastructure
- Les workflows CI/CD
- Les contraintes et lacunes clés du déploiement
Sauvegarder tes résultats dans le dépôt
L'analyse produite en mode Ask n'existe que dans la session de chat. Passe en mode Agent pour demander à Bob d'écrire un document de référence d'onboarding persistant dans le dépôt, afin que les futurs contributeurs puissent bénéficier de ce travail.
Passer en mode Agent
Sélectionne Agent dans le sélecteur de mode, ou tape /agent dans le champ de
saisie du chat.
Créer la référence d'onboarding
Demande à Bob de consolider tout ce qu'il a découvert dans un seul fichier Markdown. Bob dispose du contexte complet de la conversation et synthétise les résultats sans relire tous les fichiers.
Create a file called docs/ONBOARDING.md.
Create one section for each of these topics:
1. Application overview: purpose, project structure, high-level architecture, and the main responsibilities of each top-level directory.
2. Tech stack analysis, including a "Stack at a Glance" diagram.
3. Key components and their interactions, including a component interaction map.
4. Unit test coverage analysis.
5. End-to-end test coverage analysis.
6. Deployment model analysis.
Populate each section with everything you discovered in this session.
Use clear headings, Mermaid diagrams, and tables where appropriate. Keep the tone concise and technical.Bob écrit le fichier. Si l'approbation automatique est désactivée, clique sur Approve
quand Bob demande la permission d'écrire docs/ONBOARDING.md.
Vérifier la sortie
Ouvre docs/ONBOARDING.md dans l'éditeur pour confirmer que le document contient tout
le contenu que tu t'attends à voir. Tu peux aussi demander à Bob de le prévisualiser :
Show me a preview of docs/ONBOARDING.mdBob affiche le Markdown dans l'interface de chat. Vérifie le contenu pour sa précision et son exhaustivité avant de faire un commit.
Committer le fichier
Utilise ton workflow Git préféré pour committer docs/ONBOARDING.md dans ton dépôt.
Le document est désormais disponible pour chaque contributeur et pour Bob lui-même lors
des sessions futures.
Résolution des problèmes
L'analyse de Bob est superficielle ou manque des services
Par défaut, Bob lit la structure du projet et une sélection de fichiers clés. Si la sortie manque d'un service ou est moins détaillée que prévu, ajoute des context mentions explicites pour affiner le focus de Bob.
Par exemple, si le service hold Java n'est pas reflété dans l'analyse du tech stack,
ajoute @booking_system_inventory_hold_service/pom.xml au prompt :
Analyze the tech stack for @booking_system_inventory_hold_service/pom.xml
and add the Java hold service to the tech stack summary you produced earlier.Bob ne trouve pas les fichiers de tests
Si Bob signale qu'il ne trouve pas les fichiers de tests, utilise une context mention pour pointer directement vers les répertoires de tests :
Analyze the test coverage in @booking_system_backend/tests and
@tests_e2e. List every test file and summarize what each one covers.L'analyse de déploiement de Bob omet une cible
Les artefacts de déploiement AWS, IBM Cloud et local sont répartis dans plusieurs répertoires de premier niveau. Si le résumé de déploiement de Bob est incomplet, indique-lui les répertoires spécifiques :
Review @deployment_scripts/aws, @terraform, @deployment_scripts/ibm, and
@.github/workflows. Update the deployment model summary to include all three
deployment targets./init génère un AGENTS.md vide ou incorrect
À la racine du workspace, la commande /init construit le contexte du projet en lisant
des fichiers d'ancrage comme README.md, package.json, requirements.txt, pom.xml,
Makefile et des manifestes similaires. Si aucun de ces fichiers n'existe à la racine,
ou si la racine du workspace est définie sur un sous-répertoire, Bob ne voit qu'une
partie du projet et génère un AGENTS.md incomplet ou incorrect.
Si le AGENTS.md généré ne reflète pas la structure multi-services, vérifie les points
suivants :
- Racine du workspace : Confirme que
galaxium-travels/, et non un sous-répertoire commebooking_system_backend/, est ouvert comme racine du workspace. Les trois répertoires de services doivent être visibles au premier niveau. - Fichiers d'ancrage manquants : Si la racine ne contient pas de
README.mdni d'autre manifeste,/initn'a pas grand-chose à lire. Ajoute unREADME.mdà la racine avec une brève description du projet, puis relance/init.
Après avoir corrigé la racine, relance /init pour régénérer les fichiers AGENTS.md.
Standardiser le comportement de Bob
Standardisez le comportement de Bob dans votre équipe en utilisant des fichiers de règles au niveau du projet qui indiquent à Bob de documenter son code et de se souvenir de ses actions précédentes.
Générer des diagrammes d'architecture
Utilise IBM Bob pour analyser la base de code Galaxium Travels et générer des diagrammes de classes UML Mermaid, des diagrammes de séquence et des diagrammes de cas d'utilisation. Apprends à utiliser les mentions de contexte en mode Ask pour explorer le code et le mode Agent pour enregistrer les résultats dans ton dépôt.