Fremden Code schnell lesen: eine Technik, kein Talent

Erster Tag in einem fremden Repository, kein Kontext, und niemand hat Zeit für eine Einführung. Der übliche Reflex ist, oben anzufangen und zu lesen: Ordner für Ordner, Datei für Datei, bis das Bild sich fügt. Nach drei Tagen hat man viel gesehen und wenig verstanden.

Der Fehler liegt nicht im Tempo. Er liegt in der Annahme, dass Verstehen durch Lesen entsteht. Eine Codebasis mit dreihunderttausend Zeilen passt nicht in einen Kopf und muss es auch nicht. Was hineinpasst, ist eine Karte.

Code liest man nicht, man befragt ihn

Der Unterschied ist der zwischen einer Stadt, die man Straße für Straße abgeht, und einer, in der man nach dem Weg fragt. Professionelles Lesen ist eine Folge von Fragen, von denen jede das Gebiet verkleinert.

Nicht: was steht hier. Sondern: wo werden Entscheidungen getroffen, wohin fließen die Daten, was fasst hier niemand freiwillig an. Alles verstehen zu wollen ist kein Ziel. Es ist der Verzicht darauf, eines zu haben.

Daraus folgt eine Reihenfolge, und die Reihenfolge ist der eigentliche Inhalt dieser Technik.

Erstens: Grenzen, nicht Inhalte

Vor der ersten Zeile Code steht die Struktur. Ordner, Module, Abhängigkeiten zwischen den Bauteilen. Im iOS-Umfeld heißt das wörtlich: die Paketbeschreibung und die Projektdatei werden vor dem Code gelesen.

Das kostet eine halbe Stunde und liefert die Karte der Bezirke. Wie viele Module gibt es, wer hängt von wem ab, gibt es überhaupt Grenzen oder ist alles ein einziges Ziel. Diese halbe Stunde entscheidet, ob die nächsten Tage in einer Struktur stattfinden oder in einer Fläche.

Zweitens: die Punkte, an denen sich die App zusammensetzt

Danach die Einstiegspunkte: wo die Anwendung startet, wo Abhängigkeiten verdrahtet werden, wo die Navigation entschieden wird. Diese Stellen sind aufschlussreich, weil sie zeigen, was die Architektur über sich selbst behauptet.

Oft ist genau hier der erste Widerspruch zu finden. Ein Projekt, das saubere Schichten deklariert, aber im Startpfad zwei Dutzend Singletons anlegt, hat seine Antwort schon gegeben. Man muss dafür keinen Feature-Code gelesen haben.

Drittens: die Historie statt des Codes

Der unterschätzteste Schritt. Bevor ich mich in eine merkwürdige Stelle vertiefe, frage ich die Versionsgeschichte.

Welche Dateien werden am häufigsten geändert: das ist der Schwerpunkt der Codebasis, unabhängig davon, was die Ordnerstruktur nahelegt. Häufige Änderungen bedeuten, dass hier das Produkt lebt.

Wer eine seltsame Zeile geschrieben hat und in welchem Zusammenhang: die Antwort auf das Warum steht öfter in einer Commit-Nachricht als im Code. Und eine Folge von Einträgen wie "fix", "fix again", "really fix" markiert einen Sumpf zuverlässiger als jede Dokumentation. Diese Stellen sind später die teuersten, und man kennt sie, bevor man sie angefasst hat.

Viertens: ein einziger senkrechter Schnitt

Jetzt erst Code, und zwar entlang einer einzelnen Funktion, vom Antippen bis zur Netzwerkschicht und zurück. Ein ehrlicher Schnitt durch alle Schichten lehrt mehr über die Muster des Projekts als das waagerechte Lesen von zehn Schichten, weil die übrigen Funktionen fast sicher genauso gebaut sind.

Was dabei sichtbar wird, ist die Hausordnung: wie Fehler behandelt werden, wo Zustand liegt, ob es eine Konvention gibt oder drei. Ab dem zweiten Schnitt lernt man kaum noch etwas Neues, und das ist das Zeichen, mit dem Lesen aufzuhören.

Werkzeuge, die zum Lesen gehören

Der Debugger ist kein Prüfmittel, sondern ein Leseinstrument. Aber er beantwortet Fragen, er stellt keine: Ein Haltepunkt ist erst dann sinnvoll, wenn man eine Vermutung hat, die er bestätigen oder widerlegen soll. Deshalb steht er hier und nicht am Anfang. Ein Durchlauf mit angehaltener Ausführung ersetzt eine Stunde Nachverfolgen mit den Augen, sobald man weiß, wo man anhält.

Vorhandene Tests liest man als Absichtserklärung: Sie zeigen, was den Autoren wichtig genug war, um es abzusichern. Das ist eine andere Information als die, ob der Code funktioniert.

Und der beste Weg, das eigene Verständnis zu prüfen, ist ein selbst geschriebener Test auf ein Modul, das man zu verstehen glaubt. Läuft er nicht durch, war die Annahme falsch. Billiger kommt man an diese Rückmeldung nicht.

Aufschreiben, sonst verdunstet es

Verständnis, das nicht notiert wird, ist nach einer Woche weg. Was ich mitschreibe, ist aber kein Exzerpt, sondern eine Liste von Vermutungen: das Netzwerk läuft anscheinend vollständig über diese eine Stelle; dieses Modul sieht tot aus, prüfen; hier scheinen zwei Konventionen zu kollidieren.

Vermutungen haben den Vorteil, dass sie sich erledigen lassen. Jede wird später bestätigt oder verbrennt, und was übrig bleibt, ist eine Karte, die stimmt. Ein Exzerpt dagegen bleibt so lange richtig, wie niemand es prüft.

Warum das kein Talent ist

Wer schneller in eine Codebasis findet, liest nicht schneller. Er erkennt mehr wieder. Neun von zehn Dingen sind bekannte Muster, und die kosten kein Nachdenken: ein Koordinator, eine selbstgebaute Abhängigkeitsauflösung über globale Instanzen, eine Netzwerkschicht mit dem üblichen Zuschnitt. Die Aufmerksamkeit bleibt für den Rest übrig.

Das ist der Grund, warum die Fähigkeit übertragbar ist und keine Begabung. Die Musterbibliothek wächst mit jedem Projekt, die Reihenfolge der Fragen lässt sich übernehmen, und die Disziplin, nicht alles zu lesen, ist eine Entscheidung.

Für Auftraggeber folgt daraus etwas Praktisches: Wer sagt, er brauche einige Tage, um etwas Belastbares über eine Codebasis zu sagen, ist nicht langsam, sondern ehrlich. Wer eine Diagnose nach einer Stunde verspricht, verkauft ein Horoskop. Was in diesen Tagen tatsächlich geprüft wird, habe ich an anderer Stelle beschrieben: was ich mir in einer fremden Codebasis zuerst ansehe.

Was diese Reihenfolge kostet

Diese Reihenfolge fühlt sich zu Beginn unproduktiv an. Man hat einen halben Tag investiert und noch keine einzige Funktion gelesen, während jemand, der sofort im Feature-Code anfängt, schon etwas erklären kann. Dass dieser Vorsprung später verschwindet, sieht man erst später.

Der zweite Preis: Die Karte ist bewusst unvollständig. Ich weiß nach dieser Prozedur, wie das Projekt gebaut ist, und nicht, was in den meisten seiner Dateien steht. Wer Vollständigkeit erwartet, bekommt sie nicht, und in manchen Situationen ist das das falsche Angebot.

Wo die Technik nicht trägt

Sie setzt voraus, dass das Projekt sich übersetzen und starten lässt. Eine Codebasis, die nicht baut, ist ein anderes Genre: Dort geht es zuerst darum, überhaupt einen laufenden Zustand herzustellen, und das Lesen beginnt danach.

Und sie ist schwächer in einer Umgebung, für die man keine Musterbibliothek hat. Der erste große Einstieg in ein fremdes Paradigma dauert länger als der hundertste im vertrauten, weil dort das Wiedererkennen fehlt, das die Technik trägt. Das ist keine Schwäche der Methode, sondern ihre Voraussetzung.

Wenig lesen, richtig fragen

Schnell zu lesen heißt, wenig zu lesen und in der richtigen Reihenfolge zu fragen. Struktur vor Inhalt, Historie vor Vermutung, ein senkrechter Schnitt statt zehn waagerechter, und alles aufschreiben, was noch eine Vermutung ist.

Was daran wie Erfahrung aussieht, ist zum größten Teil Verzicht: die Bereitschaft, den größten Teil einer Codebasis nie gelesen zu haben und trotzdem zu wissen, wie sie funktioniert.