Refactoring ohne RisikoVier Teams zeigen wie es geht

Die Refactoring-Falle

Jeder kennt das Problem: Die Codebasis braucht Aufmerksamkeit, aber das Refactoring wird aufgeschoben. Laut einer Microsoft-Studie von 2014 halten 76% der Entwickler es fuer wahrscheinlich, dass Refactoring subtil Bugs oder Regressionen einfuehrt. Eine CMU-Umfrage von 2022 zeigte, dass 71% der Senior-Practitioner grosse Refactorings durchfuehren wollten, aber es aufgrund der erwarteten Kosten nicht taten.

Der Kern des Problems ist eine rationale Risiko-Kalkulation: Der Schmerz des Refactorings ist unmittelbar und konkret, waehrend die architektonischen Vorteile spaeter und verteilt auftreten. Die Kalkulation aendert sich erst, wenn die Kosten der Aenderung selbst sinken.

Vier Teams, vier Loesungen

JetBrains dokumentiert in seinem Blog, wie vier Teams dieses Problem geloest haben:

Wiz arbeitet mit einem Millionen-Zeilen-Monorepo in Go. Mit GoLand konnten Refactoring-Operationen ueber den gesamten Codebase korrekt aufgeloest werden - unabhaengig von der Groesse der Aenderung.

IT Manufactory entwickelte mit IntelliJ IDEA und WebStorm eine Java/React-Plattform. Cross-Stack-Aenderungen, die frueher manuelle Verifikation ueber die gesamte Dependency-Kette erforderten, wurden zu einzelnen bestätigten Aktionen.

NutriAdmin migrierte von AngularJS zu modernem Framework mit WebStorm. Die statische Analyse fuer AngularJS machte eine kontinuierliche Modernisierung parallel zur Feature-Entwicklung moeglich.

SEOBUK PRESENT nutzt Rider fuer C# und Unity-Entwicklung mit Hardware-Integration. Project-weite Refactoring-Previews vor jedem Commit ermoeglichten eine Kultur kleiner, haeufiger Aenderungen.

Die Schluesselfaktoren

Alle Teams teilen zwei entscheidende Faehigkeiten: Die Sichtbarkeit der vollen Auswirkung einer Refactoring-Operation ueber den gesamten Codebase VOR dem Commit, und die Moeglichkeit, alles als einzelne Operation rueckgaengig zu machen, falls etwas schiefgeht.

Link: Original bei JetBrains