- In einer großen Codebase zu arbeiten, gehört zu den schwierigsten Aufgaben für Software-Engineers. Solche Erfahrungen lassen sich nur schwer in persönlichen Projekten oder Open-Source-Projekten sammeln
- Millionen von Codezeilen, 100–1000 Engineers, die gleichzeitig daran arbeiten, und eine Codebase, die mindestens 10 Jahre alt ist
- Das erfordert eine eigene Fähigkeit, den über Zeit gewachsenen Zustand und die Komplexität zu verstehen
Der größte Fehler ist mangelnde Konsistenz
- Der häufigste Fehler besteht darin, die bestehende Codebase zu ignorieren und die eigene Funktion einfach umzusetzen. Dadurch geht Konsistenz verloren und das Chaos in der Codebase nimmt zu
- Oft wird unabhängig implementiert, um die Interaktion mit der bestehenden Codebase zu minimieren, den eigenen sauberen Code zu bewahren und vorhandenen "Legacy"-Code zu vermeiden
- Konsistenz reduziert die Komplexität der Codebase und erleichtert künftige Verbesserungen
- Wenn man zum Beispiel einen API-Endpunkt implementiert, ist es wichtig, das bestehende Authentifizierungsverfahren zu übernehmen. So kann man sich sicher durch das Minenfeld der Codebase bewegen
- Ohne konsistente Muster muss jeder Code manuell aktualisiert werden, was mit der Zeit immer schwieriger wird
Weitere wichtige Punkte
- Verstehen, wie der Service tatsächlich genutzt wird
- Die wichtigsten API-Endpunkte mit der häufigsten Nutzung und die wichtigen Pfade (
hot path) identifizieren
- Änderungen an häufig genutztem Code mit besonderer Vorsicht behandeln
- Die Bedeutung von Tests und Monitoring
- In großen Projekten lassen sich nicht alle Zustände testen, daher werden nur die wichtigsten Pfade getestet
- Code defensiv schreiben und sich auf schrittweise Rollouts sowie Monitoring verlassen
- Zurückhaltend beim Hinzufügen von Abhängigkeiten
- Abhängigkeiten verursachen Sicherheitsprobleme und erhöhen die Wartungskosten
- Wenn sie unbedingt nötig sind, vertrauenswürdige Abhängigkeiten auswählen
- Code vorsichtig, aber aktiv entfernen
- Produktionsdaten analysieren, um Aufrufe sicher zu entfernen, und danach den Code löschen
- Das Entfernen unnötigen Codes erleichtert die Wartung der Codebase
- Das ist eine der wertvollsten Arbeiten in großen Codebases
- Mit kleinen PRs arbeiten und Änderungen, die den Code anderer Teams betreffen, zuerst angehen
- So können Domain-Experten Probleme erkennen und Incidents verhindern
Warum sind große Codebases wichtig?
- Der Wert großer Codebases
- Die meisten Tech-Unternehmen erwirtschaften ihre Umsätze mit großen Codebases
- An einer "Legacy Codebase" zu arbeiten, bedeutet die eigentliche Arbeit des Unternehmens zu machen
- Vor dem Aufteilen muss man sie verstehen
- Um eine große Codebase aufzuteilen, muss man zuerst ihre Gesamtfunktionsweise ausreichend verstehen
- Ohne dieses Verständnis ist ein groß angelegtes Redesign unmöglich
Zusammenfassung
- Große Codebases haben einen wichtigen geschäftlichen Wert
- Das Wichtigste ist, Konsistenz zu bewahren
- Vor der Implementierung neuer Funktionen den bestehenden Code untersuchen und vorhandenen Mustern folgen
- Wenn man bestehenden Mustern nicht folgt, sollte es dafür einen sehr guten Grund geben
- Verstehen, wie der Code in der Produktionsumgebung tatsächlich verwendet wird
- Da sich nicht alle Fälle testen lassen, nicht übermäßig auf Tests verlassen, sondern auf Monitoring und schrittweise Rollouts setzen
- Chancen zum Entfernen von Code aktiv nutzen, aber vorsichtig vorgehen
- In kleinen PRs arbeiten, damit Domain-Experten sie prüfen können
8 Kommentare
Konsistenz ist zwar wichtig, aber deshalb Verbesserungen am Code aufzuschieben oder bestehende falsche Muster zu wiederholen, ist auch kein guter Ansatz … ein schwieriges Problem. Denn wenn man nur auf Konsistenz achtet, kann es am Ende so aussehen, als würde man immer wieder dieselben technischen Schulden anhäufen.
Vor allem anderen sollte man die Codierungsregeln einhalten.
Besonders die Einrückungsregeln ...
Arbeiten Sie in einer Domäne, in der sich kein Tooling einsetzen lässt, das Fehler automatisch erkennt …? seufz
Ja … wein
Ich werde für euch weinen … schluchz schluchz
Die Größe eines Projekts != seine Reife
Ich stimme zu, dass Konsistenz sehr wichtig ist, aber ich denke, man sollte das nicht als Vorwand nutzen, die Priorität für Verbesserungen an der Codebasis niedrig anzusetzen.
Da ein Projekt immer lebt und wächst, kostet es später umso mehr Zeit und Aufwand, das Versäumte wieder aufzuholen, wenn man Verbesserungen nicht zum richtigen Zeitpunkt umsetzt.
Dem stimme ich ebenfalls zu. Ich arbeite auch an einem über 20 Jahre alten Projekt, und es gibt wirklich viele Bereiche, die im Vergleich zu heute noch sehr unausgereift sind.
Konsistenz hat zwar den Vorteil, das Verständnis des Codes zu verbessern, aber strukturelle Grenzen führen auch zu funktionalen Grenzen und bremsen dadurch die Weiterentwicklung des Dienstes. Deshalb denke ich, dass manchmal auch ein mutiger, grundlegender Umbau nötig ist.
Hacker-News-Kommentar
Wenn eine bestehende Codebasis inkonsistent ist, ist es wichtig, neue Vorgehensweisen einzuführen, zu dokumentieren und Feedback einzuholen. Man sollte sich bemühen, die Konsistenz mit dem bestehenden Code zu wahren.
Man sollte die Tools der bestehenden Codebasis verwenden, auch wenn es mehr Spaß machen kann, eine neue Codebasis aufzubauen.
Um eine große Codebasis aufzuteilen, muss man sie zuerst verstehen; wenn ein unerfahrenes Team das versucht, ist die Wahrscheinlichkeit des Scheiterns hoch.
In großen Codebasen gibt es viele Versuche, wahllos Verbesserungen vorzunehmen.
Es ist schwierig, die Weiterentwicklung einer Codebasis aufrechtzuerhalten.
Wenn eine Codebasis groß ist und Personal fehlt, dauert es lange, bis neue Leute produktiv werden.
Eine Codebasis sauber zu halten bedeutet, nur das Minimum an Arbeit zu erledigen, das nötig ist, um Features auszuliefern.
Konsistenz ist nicht das Wichtigste; es ist besser, Teile der Codebasis zu verbessern.
Die Aussage "Mangel an Konsistenz ist ein fataler Fehler" ist zu 100 % richtig.
Drei Maximen für Engineers: