Bestehende Anwendungen lesen, verstehen und anpassen

Die meisten Entwickler:innen verbringen die Mehrzahl ihrer Arbeitszeit nicht mit dem Schreiben von neuem Code, sondern mit dem Lesen, Verstehen und Anpassen von bestehendem Code. Die Faustregel: 90 % lesen, 10 % schreiben. Trotzdem wird Code-Lesen in der Ausbildung selten gelehrt – diese Lektion schließt die Lücke.

Du lernst hier einen systematischen Workflow zum Einarbeiten in fremde Codebasen, die Strategien Top-Down und Bottom-Up, das Erkennen von Code-Smells und die Kunst, ohne alles kaputt zu machen kleine Änderungen vorzunehmen. In der IHK-Klausur taucht das unter Rahmenplan B1e auf.

1) Warum ist Code-Lesen so wichtig?

Wer in einem Job anfängt, sieht meist Code, der über Jahre gewachsen ist. Originalentwickler sind weg, Doku ist halbherzig, Architektur-Entscheidungen wirken seltsam. Das ist normal. Die Skills zum Umgang damit:

Pragmatismus: kein Code ist perfekt. Akzeptier den Status quo bevor du ihn ändern willst.
Geduld: verstehen vor ändern. Wer ändert ohne zu verstehen, verursacht meist neue Bugs.
Werkzeug-Kompetenz: IDE, Git, Debugger sind deine Karten in einer fremden Stadt.
Detektiv-Mentalität: Hinweise sammeln, Hypothesen testen.

2) Der 5-Schritte-Workflow zum Einarbeiten

Wenn du in einer neuen Codebase landest, geh nicht direkt in die Code-Dateien. Erst der strukturierte Überblick. Klick durch die 5 Phasen:

Workflow zum Einarbeiten in fremden Code

Überblick

Starten

Einstieg finden

Datenfluss

Klein ändern

Phase 1: Überblick verschaffen

Bevor du Code öffnest: Lies die README. Schau dir die Verzeichnisstruktur an (tree -L 2 auf der Konsole oder im File-Explorer). Welche Technologien? Welche Frameworks? Wo sind src/, test/, Konfiguration? Wie alt ist das Projekt? Wer hat zuletzt commitet (git log)? Welche Dokumente liegen herum (CONTRIBUTING.md, ARCHITECTURE.md)?

Wer diesen Workflow ignoriert und sofort in main.java springt, verliert Zeit. Der Überblick spart Stunden – manchmal Tage. In großen Codebasen (10.000+ Dateien) ist Schritt 1 oft mehrere Stunden Arbeit. Investiere sie.

3) Top-Down vs. Bottom-Up

Zwei fundamentale Strategien zum Verstehen von Code:

Zwei Lese-Strategien

Top-Down

Beginnt beim Einstiegspunkt: main(), Controller-Endpunkt, UI-Handler.

Folgt Aufrufketten in die Tiefe.

Gut, wenn man eine konkrete Feature-Frage hat: „Wie funktioniert Login?"

Risiko: man verliert sich in tiefen Aufrufen.

Bottom-Up

Beginnt bei Basis-Klassen: Datenmodellen, Utilities, Repositories.

Baut Verständnis schichtweise auf.

Gut für Architektur-Verständnis und Refactoring-Vorbereitung.

Risiko: lange bis ein konkretes Feature klar wird.

In der Praxis wechselt man oft zwischen beiden – „Sandwich"-Ansatz wie bei Integration-Tests (K52 L2). Für konkrete Bug-Fixes meist Top-Down (von der Symptom-Stelle nach hinten). Für größere Refactorings eher Bottom-Up.

4) Werkzeuge zum Code-Lesen

Die IDE ist deine wichtigste Waffe. Diese Funktionen solltest du blind bedienen können:

IDE-Befehle zum Code-Lesen

Aktion	Was es macht	Shortcut
Go to Definition	Wo ist diese Methode/Klasse definiert?	Ctrl+Click / F12
Find Usages	Wo wird diese Methode aufgerufen?	Alt+F7 (IntelliJ)
Call Hierarchy	Ganzer Aufruf-Baum: wer ruft wen?	Ctrl+Alt+H
Type Hierarchy	Vererbungs-Hierarchie einer Klasse.	Ctrl+H
Global Search	Stichwort in allen Dateien suchen.	Ctrl+Shift+F
Bookmarks	Wichtige Stellen markieren.	F11
Git Blame	Wer hat diese Zeile wann geändert?	per Plugin
Debugger	Code Zeile für Zeile durchlaufen.	F8/F9

Der Debugger ist das mächtigste Werkzeug zum Verstehen. Setz einen Breakpoint, lass das Programm dorthin laufen, schau die Variablen an. So lernst du in 5 Minuten mehr als beim reinen Lesen in einer Stunde. Vgl. L1 IDEs.

5) Code-Smells erkennen

Wenn du Code liest, achte auf Warnzeichen – „Smells" im Sinne von Martin Fowler. Sie zeigen Stellen, die problematisch sein können:

Typische Code-Smells

Long Method

Methoden mit 200+ Zeilen. Mehrere Verantwortungen vermischt. Aufteilen.

God Class

Eine Klasse macht alles. „Manager", „Handler", „Util" sind verdächtige Namen.

Magic Numbers

if (status == 7) ohne Erklärung. In benannte Konstanten umwandeln.

Duplikate

Gleicher Code an mehreren Stellen. DRY („Don't Repeat Yourself") verletzt.

Tote Pfade

If-Zweige, die nie erreicht werden. Auskommentierter Code. Weg damit.

Lange Parameterlisten

Methode mit 8 Parametern? Vermutlich macht sie zu viel.

Shotgun Surgery

Einfache Änderung erfordert Edits in 20 Dateien. Kopplung zu hoch.

Feature Envy

Eine Methode greift mehr auf eine fremde Klasse zu als auf eigene. Falsch platziert.

Smells sind Hinweise, keine Beweise für schlechten Code. Manchmal hat eine 500-Zeilen-Methode einen guten Grund (z.B. generierter Code). Aber wenn du als Neuling auf viele Smells stößt, weißt du: hier wird's anstrengend, plane Pufferzeit.

6) Sichere Änderungen vornehmen

Du hast Code verstanden, willst etwas ändern. Wie ohne Schaden? Die Profi-Reihenfolge:

Tests laufen lassen. Bevor du irgendwas tust: alle Tests grün? Wenn nicht, hat das Projekt schon Probleme, die nicht von dir kommen.
Test fürs neue Verhalten schreiben. Bevor du den Code änderst, einen Test, der zeigt: so soll es sein. Vgl. TDD K52 L5.
Minimal-Änderung. So wenig wie möglich ändern. Eine Sache pro Commit. Wenn du dabei „nebenbei" 5 andere Dinge fixen willst – nicht, das blockt den Review.
Tests erneut laufen. Alle grün? Sonst zurücksetzen.
Commit mit klarer Nachricht. Conventional Commits: fix: rabatt-berechnung bei null-werten. Vgl. K54 Git.
Pull Request öffnen. Code-Review von Kollege ist unverzichtbar.

7) Refactoring – Code verbessern, ohne Verhalten zu ändern

Wenn du Code änderst ohne neue Funktion einzuführen, ist es Refactoring. Definition (Fowler): „The process of restructuring existing code without changing its external behavior."

Wichtige Refactorings, die jede moderne IDE automatisch ausführen kann:

Klassische Refactorings

Rename

Variable / Methode / Klasse umbenennen, alle Verwendungen mit.

Extract Method

Block aus langer Methode in eigene Methode mit sprechendem Namen.

Extract Variable

Komplexen Ausdruck in eine benannte Variable auslagern.

Inline Method

Umgekehrt: triviale Methode direkt am Aufruf einsetzen.

Move Method

Methode in eine andere Klasse verschieben.

Replace Magic Number

7 → MAX_RETRY_COUNT als Konstante.

Extract Class

Aus einer God-Class zwei Klassen mit klaren Verantwortungen.

Pull Up / Push Down

Methode in Eltern-Klasse heben oder in Kind-Klasse senken.

Wichtig: Tests müssen vorher und nachher gleich grün sein. Wer Refactoring ohne Tests macht, ist mutig (oder unvorsichtig). Die IDE-Refactorings sind sicher – die machen es richtig. Vorsicht bei manuellen Massen-Änderungen.

8) Das Boy-Scout-Prinzip

Robert Martin („Uncle Bob") formulierte den Boy Scout Rule: „Always leave the campground cleaner than you found it." Übertragen auf Code: jede Datei, die du anfasst, ein bisschen besser hinterlassen.

Boy-Scout-Prinzip in Aktion

Wichtig: kleine Verbesserungen, nicht riesige Refactor-Sessions. Wer alle 6 Monate ein „Refactoring-Sprint" macht, scheitert oft. Wer bei jeder Datei 1 % besser wird, transformiert die Codebase über Monate spürbar. Diese Disziplin trennt Senior- von Junior-Entwicklung.

9) Anti-Patterns beim Code-Lesen

„Das war schon so" – tolerieren statt fragen. Wenn du nicht verstehst warum Code so ist, frag jemanden. git blame und Slack-Kollege.
„Rewrite from scratch." Eine alte Bibel der Software: niemals komplett neu schreiben. Joel Spolsky hat dazu einen berühmten Artikel. Inkrementell verbessern ist fast immer besser.
Massen-Refactor in einem PR. 50 Dateien geändert, niemand kann reviewen. Atomare Commits, kleine PRs.
„Ich lese erst alles" vor dem ersten Commit. Geht in 100k-Codebases nicht. Lerne genug für die Aufgabe.
Code löschen ohne Verstehen. Auskommentierter Code könnte ein vergessenes Feature sein. Erst git log, dann löschen.

10) Praxis-Beispiel: ein Bug fixen

Du wirst dem Team neu zugeteilt. Erster Ticket: „Bei Login mit leerem Username crashed die App." Wie gehst du vor?

Reproduzieren. App starten, Bug nachstellen. Fehlermeldung notieren.
Stack-Trace lesen. Welche Datei, welche Zeile? Dort einen Breakpoint setzen.
Top-Down folgen. Wer ruft die crashende Methode auf? Wo kommt der leere Username her?
Erwartetes Verhalten klären. Was soll passieren? Validierung im Frontend? Im Backend? Beide?
Test schreiben. „Login mit leerem Username gibt 400 zurück, nicht 500."
Minimal-Fix. Nullcheck oder Validierung. Eine Sache, eine PR.
Andere Bugs nicht fixen. Auch wenn du sie siehst – eigene Tickets aufmachen.

Zusammenfassung

Code-Lesen macht 90 % der Arbeit aus. 5-Schritte-Workflow: Überblick (README, Struktur) → App starten → Einstiegspunkt finden → Datenfluss folgen → klein ändern. Top-Down (Einstieg → tief) vs. Bottom-Up (Basisklassen → hoch). IDE-Werkzeuge: Go-to-Definition, Find-Usages, Call-Hierarchy, Debugger. Code-Smells: Long Method, God Class, Magic Numbers, Duplikate. Refactoring: Verhalten gleich halten, Tests grün. Boy-Scout-Rule: jede Datei 1 % besser hinterlassen. Niemals komplett neu schreiben. Nächste Lektion: Linter und Formatter.