Eine unbekannte Codebasis untersuchen
Verwende IBM Bob, um schnell eine unbekannte Anwendung zu verstehen – ihren Zweck, die Projektstruktur, Architektur, den Tech-Stack, wichtige Komponenten, Testabdeckung und das Deployment-Modell. Das gelingt dir ohne veraltete Dokumentation oder das Warten auf Kolleg*innen.
Produktiv in einer unbekannten Codebasis zu werden, bedeutet meist stundenlange Code-Lektüre, die Suche nach Dokumentation und das Nachfragen bei Kolleg*innen. In diesem Tutorial verwendest du Bob im Ask-Modus, um das Galaxium Travels-Repository systematisch zu untersuchen und ein vollständiges Bild der Anwendung zu erhalten: Zweck und Architektur, Tech-Stack, wichtige Komponenten, Unit- und Integrationstestabdeckung sowie das Deployment-Modell. Anschließend wechselst du in den Agent-Modus, um alles, was Bob herausgefunden hat, in eine persistente Markdown-Referenz zu speichern, die dein gesamtes Team nutzen kann.
Galaxium Travels ist eine absichtlich komplexe, real wirkende Anwendung mit einem React-Frontend, einem Python-FastAPI-Backend und einem Java-Spring-Boot-Inventarservice. Das macht sie zu einem idealen Kandidaten für diesen Workflow.
Die Ausgabe von Bob hängt vom aktuellen Zustand der Codebasis ab. Betrachte die Beispiele in diesem Tutorial als repräsentative Ausgangspunkte, nicht als exakte Protokolle. Nutze sie, um deine eigenen Prompts zu kalibrieren und die Ergebnisse zu verfeinern.
Wichtige Features, die du lernst
- Ask-Modus: Code erkunden und analysieren, ohne dass Bob Dateien verändert.
- Agent-Modus: Bob autonom Dateien schreiben lassen, um generierte Artefakte in deinem Projekt zu speichern.
- Context Mentions: Bestimmte Dateien und
Ordner mit
@referenzieren, um Bob einen genauen Analysebereich zu geben. /init: Projektkontext initialisieren, damit Bob die Konventionen der Codebasis kennt, bevor du Fragen stellst.
Voraussetzungen
Um dieses Tutorial abzuschließen, benötigst du Folgendes:
- Bob IDE installiert.
- Git lokal installiert.
- Grundlegende Vertrautheit mit Bob. Wenn du neu bei Bob bist, schließe zuerst das Quickstart-Tutorial ab.
Workspace einrichten
Galaxium Travels Repository klonen
Klone das Beispiel-Repository im Terminal:
git clone https://github.com/IBM/galaxium-travels.gitBeispielprojekt öffnen
Öffne in der Bob IDE den Ordner galaxium-travels, den du gerade geklont hast. Falls Bob
fragt „Do you trust the authors of the files in the folder?", klicke auf Yes, I trust
the authors.
Bob-Chat-Interface öffnen
Falls das Chat-Interface noch nicht geöffnet ist, klicke auf das Bob-Symbol in der Navigationsleiste oder verwende den Shortcut Option + Command + B (Mac) bzw. Ctrl + Alt + B (Windows).
Projektkontext initialisieren
Bob startet standardmäßig im Agent-Modus. Bevor du den Modus wechselst, führe den Befehl
/init aus, damit Bob das Projekt liest und die AGENTS.md-Kontextdateien generiert, die
es bei nachfolgenden Interaktionen verwendet.
/initFalls die automatische Genehmigung deaktiviert ist, fragt Bob um Erlaubnis, Dateien zu lesen
und AGENTS.md-Dateien zu schreiben. Genehmige jede Anfrage. Bob erstellt eine
AGENTS.md im Root-Verzeichnis und einen .bob/-Ordner mit moduspezifischer Konfiguration.
Überprüfe die generierte AGENTS.md, um zu bestätigen, dass Bob die Multi-Service-Struktur
des Repositories korrekt erkannt hat.
In den Ask-Modus wechseln
Wähle Ask im Moduswähler unterhalb des Chat-Eingabefelds oder tippe /ask, um
den Modus zu wechseln. Der Ask-Modus ist strikt schreibgeschützt. Bob analysiert Dateien,
kann aber nichts erstellen oder verändern – er ist damit der richtige Modus für alle
Erkundungsaufgaben in diesem Tutorial.
Zweck und Projektstruktur der Anwendung verstehen
Beginne mit der breitesten Frage: Was macht diese Anwendung, und wie ist die
Codebasis organisiert? Bob liest die Projektstruktur und wichtige Dateien wie
README.md, package.json, requirements.txt, Build-Dateien und andere
Konfigurationsdateien. Bob erstellt eine prägnante Zusammenfassung, ohne dass du
manuell jedes Verzeichnis durchsuchen musst.
Gib im Ask-Modus folgenden Prompt ein:
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 liest den Dateibaum und wichtige Einstiegspunkte und erstellt dann eine Ausgabe, die Folgendes enthält:
- Anwendungszweck
- Verantwortlichkeiten der Top-Level-Verzeichnisse
- Überblick über den Inhalt jedes Top-Level-Verzeichnisses
- High-Level-Architekturdiagramm
Tech-Stack analysieren
Mit klarer High-Level-Struktur kannst du tiefer in die verwendeten Technologien eintauchen. Dieser Prompt ist nützlich, wenn du Build-Tooling verstehen, Abhängigkeitsentscheidungen bewerten oder den Umfang von Upgrades einschätzen möchtest.
Gib im Ask-Modus folgenden Prompt ein:
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 untersucht die Abhängigkeits- und Konfigurationsdateien für jeden Service und erstellt eine Ausgabe, die Folgendes enthält:
- Detaillierte Tech-Stack-Analyse für jeden Service
- Identifikation des End-to-End-Test-Frameworks
- Weiteres Tooling aus dem CI/CD-Stack und Deployment-Scripts
- Ein „Stack at a Glance"-Diagramm, das den Tech-Stack aller Services visuell zusammenfasst
Wichtige Komponenten kartieren
Den Tech-Stack zu kennen, sagt dir, was eine Codebasis verwendet; die wichtigen Komponenten zu kennen, sagt dir, wie sie funktioniert. Dieser Prompt bittet Bob, die Komponentengrenzen und Datenflüsse über alle drei Services hinweg zu verfolgen – besonders nützlich, bevor du Änderungen vornimmst, die Service-Grenzen überschreiten.
Gib im Ask-Modus folgenden Prompt mit Context Mentions ein, um Bob auf die relevantesten Dateien zu verweisen:
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 verfolgt die Interaktionskette und erstellt eine Ausgabe, die Folgendes enthält:
- Detaillierte Verantwortlichkeiten von Frontend, Backend-API, Datenbankschicht und Java-Hold-Service
- Ein Diagramm der beiden Buchungslebenszyklus-Flows mit annotierten Komponenteninteraktionen
- Eine Zusammenfassung der fünf Cross-Service-Verträge, die du vor Änderungen kennen musst
- Eine Komponenteninteraktionskarte
Unit-Testabdeckung bewerten
Bevor du Features hinzufügst oder refaktorierst, musst du wissen, was die vorhandene Test-Suite abdeckt und wo die Lücken sind. Dieser Prompt bittet Bob, die Testdateien zu lesen und eine Abdeckungsbewertung zu erstellen, ohne die Tests auszuführen.
Gib im Ask-Modus folgenden Prompt ein:
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 liest die Testdateien und erstellt eine detaillierte Test-Suite-Analyse, die Folgendes enthält:
- Test-Framework, getestete Klassen, Anzahl der Tests pro Klasse und was pro Klasse geprüft wird – für jeden Service
- Kritische Testlücken
- Fehlende Testabdeckung für kritische Business-Logik
Integrations- und End-to-End-Testabdeckung bewerten
Unit-Tests zeigen, ob einzelne Komponenten isoliert funktionieren; Integrations- und End-to-End-Tests zeigen, ob die Services korrekt zusammenarbeiten. Das ist besonders wichtig für Galaxium Travels, da der Buchungsbestätigungsflow alle drei Services durchläuft.
Gib im Ask-Modus folgenden Prompt ein:
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 liest die End-to-End-Test-Suite und generiert eine detaillierte Abdeckungsanalyse, die Folgendes enthält:
- Testinfrastruktur und Anforderungen zum Ausführen der Suite
- Smoke-Tests
- Wichtige Infrastrukturentscheidungen
- Abgedeckte und nicht abgedeckte Cross-Service-Flows
- Test-Assertions auf Grenzebene
Deployment-Modell überprüfen
Zu verstehen, wie eine Anwendung deployed wird (Zielplattformen, Containerisierungsstrategie und Infrastrukturautomatisierung), ist unerlässlich, bevor du als Contributor onboardest oder die Anwendung außerhalb deines Laptops ausführst.
Gib im Ask-Modus folgenden Prompt ein:
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 liest die Deployment-Artefakte und erstellt eine Deployment-Modell-Analyse, die Folgendes enthält:
- Unterstützte Deployment-Ziele
- Containerisierungsstrategie für jeden Service
- Details zur Infrastrukturbereitstellung
- CI/CD-Workflows
- Wichtige Deployment-Einschränkungen und Lücken
Ergebnisse im Repository speichern
Die im Ask-Modus erstellte Analyse existiert nur in der Chat-Sitzung. Wechsle in den Agent-Modus, um Bob ein persistentes Onboarding-Referenzdokument ins Repository schreiben zu lassen, damit zukünftige Contributors von dieser Arbeit profitieren können.
In den Agent-Modus wechseln
Wähle Agent im Moduswähler oder tippe /agent im Chat-Eingabefeld.
Onboarding-Referenz erstellen
Bitte Bob, alles, was es herausgefunden hat, in einer einzigen Markdown-Datei zusammenzufassen. Bob hat den vollständigen Gesprächskontext und fasst die Ergebnisse zusammen, ohne alle Dateien erneut zu lesen.
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 schreibt die Datei. Falls die automatische Genehmigung deaktiviert ist, klicke auf
Approve, wenn Bob um Erlaubnis bittet, docs/ONBOARDING.md zu schreiben.
Ausgabe überprüfen
Öffne docs/ONBOARDING.md im Editor, um zu bestätigen, dass das Dokument alle
erwarteten Inhalte enthält. Du kannst Bob auch bitten, es zu zeigen:
Show me a preview of docs/ONBOARDING.mdBob rendert das Markdown im Chat-Interface. Überprüfe den Inhalt auf Richtigkeit und Vollständigkeit, bevor du commitest.
Datei committen
Verwende deinen bevorzugten Git-Workflow, um docs/ONBOARDING.md in dein
Repository zu committen. Das Dokument steht nun allen Contributors und Bob
selbst in zukünftigen Sitzungen zur Verfügung.
Fehlerbehebung
Bobs Analyse ist oberflächlich oder übersieht Services
Standardmäßig liest Bob die Projektstruktur und eine Auswahl wichtiger Dateien. Falls in der Ausgabe ein Service fehlt oder sie weniger detailliert als erwartet ist, füge explizite Context Mentions hinzu, um Bobs Fokus einzugrenzen.
Falls zum Beispiel der Java-Hold-Service nicht in der Tech-Stack-Analyse erscheint,
füge @booking_system_inventory_hold_service/pom.xml zum Prompt hinzu:
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 kann keine Testdateien finden
Falls Bob meldet, dass es keine Testdateien finden kann, verwende eine Context Mention, um direkt auf die Testverzeichnisse zu verweisen:
Analyze the test coverage in @booking_system_backend/tests and
@tests_e2e. List every test file and summarize what each one covers.Bobs Deployment-Analyse lässt ein Ziel aus
Die AWS-, IBM-Cloud- und lokalen Deployment-Artefakte sind über mehrere Top-Level-Verzeichnisse verteilt. Falls Bobs Deployment-Zusammenfassung unvollständig ist, verweise es auf die spezifischen Verzeichnisse:
Review @deployment_scripts/aws, @terraform, @deployment_scripts/ibm, and
@.github/workflows. Update the deployment model summary to include all three
deployment targets./init generiert eine leere oder fehlerhafte AGENTS.md
Im Workspace-Root liest der Befehl /init Ankerdateien wie README.md, package.json,
requirements.txt, pom.xml, Makefile und ähnliche Manifeste. Falls keine dieser
Dateien im Root vorhanden ist oder das Workspace-Root auf ein Unterverzeichnis gesetzt ist,
sieht Bob nur einen Teil des Projekts und generiert eine spärliche oder fehlerhafte
AGENTS.md.
Falls die generierte AGENTS.md die Multi-Service-Struktur nicht widerspiegelt,
überprüfe Folgendes:
- Workspace-Root: Bestätige, dass
galaxium-travels/– nicht ein Unterverzeichnis wiebooking_system_backend/– als Workspace-Root geöffnet ist. Alle drei Service-Verzeichnisse müssen auf der obersten Ebene sichtbar sein. - Fehlende Ankerdateien: Falls im Root kein
README.mdoder anderes Manifest vorhanden ist, hat/initwenig zu lesen. Füge einREADME.mdauf Root-Ebene mit einer kurzen Projektbeschreibung hinzu und führe/initerneut aus.
Nach dem Korrigieren des Roots führe /init erneut aus, um die AGENTS.md-Dateien
neu zu generieren.
Bobs Verhalten standardisieren
Standardisieren Sie Bobs Verhalten in Ihrem Team mithilfe von Regeldateien auf Projektebene, die Bob anweisen, seinen Code zu dokumentieren und sich an seine vorherigen Aktionen zu erinnern.
Architekturdiagramme generieren
Verwende IBM Bob, um die Galaxium Travels Codebasis zu analysieren und Mermaid UML-Klassendiagramme, Sequenzdiagramme und Use-Case-Diagramme zu generieren. Lerne, wie du Context Mentions im Ask-Modus verwendest, um Code zu erkunden, und den Agent-Modus, um die Ergebnisse in deinem Repository zu speichern.