Etwas übernehmen, das jemand anderes gebaut hat
Jedes geerbte System sieht schlechter aus, als es ist — aus demselben Grund, aus dem jede fremde Stadt schlecht geplant wirkt.
Früher oder später erben Sie etwas: eine Codebasis, eine Automatisierung, eine Tabelle, von der drei Abteilungen abhängen. Wer sie gebaut hat, ist weg oder beschäftigt; sie funktioniert, und niemand kann sagen, warum.
Der Drang zum Neuschreiben ist fast immer falsch
Fremde Arbeit sieht schlecht aus, weil man alle Narben sieht und keinen der Gründe. Die merkwürdige Bedingung mitten in einer Funktion ist keine Nachlässigkeit; sie ist die Lösung für ein Kundenproblem von 2023, das niemand notiert hat.
Neuschreiben wirft diese undokumentierten Gründe weg und entdeckt sie einzeln, Vorfall für Vorfall, wieder. Setzen Sie sich eine Regel: kein Neuschreiben, bevor Sie drei kleine Änderungen erfolgreich gemacht haben. Dann verstehen Sie es entweder gut genug für ein sauberes Neuschreiben, oder Sie merken, dass es in Ordnung ist.
Finden Sie heraus, was tragend ist
In jedem geerbten System leistet ein kleiner Teil die eigentliche Arbeit und ein großer ist Dekoration: alte Experimente, tote Pfade, ungenutzte Funktionen. Von innen sehen sie gleich aus.
Zwei billige Wege, sie zu unterscheiden. Sehen Sie, was sich am häufigsten ändert — häufig bearbeiteter Code ist der Ort, an dem das Geschäft wirklich wohnt. Und sehen Sie, was am häufigsten läuft. Alles, was ein Jahr lang weder bearbeitet noch ausgeführt wurde, ist ein Löschkandidat, und das Löschen ist der schnellste Weg, den Rest verständlich zu machen.
Finden Sie die Person, die sich erinnert, bevor Sie sie brauchen
Fast immer ist noch jemand da, der beim Bau in der Nähe war — nicht unbedingt die Autorin. Eine Person aus dem Support, die den Vorfall erinnert, eine Kollegin, die geprüft hat, die Kundin, die die seltsame Anforderung stellte.
Sprechen Sie in Ihrer ersten Woche mit ihnen, solange Ihre Fragen noch naiv und billig sind — nicht im dritten Monat, wenn Sie feststecken. Dreißig Minuten dann sparen später Tage, und die Erinnerung wird mit jedem Wartemonat schlechter.
Machen Sie eine kleine Änderung und liefern Sie sie aus
Fremden Code zu lesen lehrt erstaunlich wenig; ihn zu ändern lehrt alles. Nehmen Sie etwas trivial Kleines und bringen Sie es ganz bis live.
Sie lernen, was Sie wirklich wissen mussten: wie gebaut wird, was kaputtgeht, wenn Sie es anfassen, ob die Tests etwas bedeuten, wer es bemerkt. Das ist die echte Karte, und sie steht in keinem Dokument. Schreiben Sie auf, was Sie bei dieser ersten Änderung gelernt haben — Sie sind die einzige Person, die dieses System je mit frischen Augen sieht, und dieser Blick ist binnen eines Monats weg.
Häufig gestellte Fragen
Soll ich ein geerbtes System neu schreiben?
Nicht zuerst. Fremde Arbeit sieht schlecht aus, weil man ihre Narben sieht und keinen Grund — die merkwürdige Bedingung ist meist eine undokumentierte Korrektur. Erst drei kleine Änderungen erfolgreich machen.
Wie erkenne ich, welche Teile zählen?
Was sich am häufigsten ändert und was am häufigsten läuft. Häufig bearbeiteter Code ist der Ort des Geschäfts; was ein Jahr weder bearbeitet noch ausgeführt wurde, ist ein Löschkandidat.
Was tue ich in der ersten Woche?
Die Person finden, die beim Bau dabei war — nicht unbedingt die Autorin — solange die Fragen noch naiv sind, und eine trivial kleine Änderung bis live bringen. Dann aufschreiben, was Sie gelernt haben.
