Der nachfolgende Text wurden mit KI erstellt und kann Fehler enthalten. Fehler gefunden? Bei GitHub editieren

Folge 226 - Theorie des Aufräumens - Kent Beck’s “Tidy First?” mit Marco Emrich 2/2

Wichtige Keytakeaways

Verhaltensänderungen und Strukturänderungen sollten strikt in separaten Pull-Requests behandelt werden, um Verwirrungen zu vermeiden und Reviews zu erleichtern.
Code-Aufräumen ist eine kontinuierliche Aktivität und sollte nicht auf später verschoben werden, sondern gezielt in den Arbeitsalltag integriert werden.
Die ökonomische Optionstheorie bietet eine saubere Erklärung für Management, warum Refactoring nicht zu technischer Schönheit führt, sondern Risikomanagement darstellt.
Wenn Code wirr ist und sowohl Verhaltens- als auch Strukturänderungen vermischt sind, ist das beste Vorgehen oft, den Code wegzuwerfen und neu zu schreiben.
Preparatory Refactoring vor neuen Features spart oft Zeit bei der Implementierung, da die Basis bereits optimal vorbereitet ist.
Codequelle wird nie wirklich “fertig”, sondern wird kontinuierlich an neue Erkenntnisse und Anforderungen angepasst.

Sollten Verhaltensänderungen und Strukturänderungen in separaten Pull-Requests behandelt werden?
Wie entwirrt man Code, der bereits vermischt Verhaltens- und Strukturänderungen enthält?
Welche Batch-Größe ist optimal für Pull-Requests – viele kleine oder wenige große?
Wann sollte Code aufgeräumt werden: vorher, nachher, später oder nie?
Wie lässt sich Refactoring wirtschaftlich rechtfertigen und gegenüber Management erklären?
Warum ist die Optionstheorie aus der Finanzwirtschaft ein besseres Erklärmodell als der Begriff “Technical Debt”?

Tidy First: Ein Sammlung von Pattern, bei dem Code vor einer neuen Implementierung gezielt aufgeräumt wird, um die anstehende Verhaltensänderung zu erleichtern.
Preparatory Refactoring: Die Praxis, Code strukturell zu verbessern, bevor neue Features oder Bugs implementiert werden, um die technische Grundlage optimal vorzubereiten.
Trunk-Based Development: Ein Versionskontroll-Ansatz, bei dem Entwickler direkt auf dem Hauptbranch arbeiten statt Pull-Requests zu nutzen, was schnelleres Feedback ermöglicht.
Technical Debt: Ein Modell zur Beschreibung von Kosten minderwertigen Codes, wobei schlechte Architektur wie finanzielle Schulden zinsen muss, wird durch Optionstheorie ersetzt.
Entwirren (Untangle): Der Prozess, vermischte Verhaltens- und Strukturänderungen in separaten Git-Commits oder Pull-Requests wieder zu trennen und zu ordnen.
Optionstheorie: Ein Finanzkonzept, das auf Software übertragen wird, um zu zeigen, dass sauberer Code eine wertvolle Option schafft, die zukünftige Änderungen günstiger macht.