Refactoring ist keine Schönheitskur – Refactoring ist Software-Entwicklung
Leider sehen viele Entwickler das Thema “Refactoring” immernoch als sinnlose Strafarbeit. Dabei ist es Alltag. Software lebt – sie lebt von Anforderungen und die ändern sich fast täglich (ja das wurde sogar mehrfach bewiesen 
). Demnach ist es selbstverständlich das sich Eckpfeiler der Architektur verändern und die Implementierung umgeschmissen werden muss. Klassen werden umbenannt, erhalten neue Funktionalität, werden aufgeteilt oder einfach weggeschmissen. Für viele bedeutet das scheinbar ein harter Eingriff: Als würde man in eine Messi-Wohnung eindringen und den Müll entsorgen.
Selbst das schaffen von Strukturen wird als unnötige Zeitverschwendung angesehen. Dabei ist es unabdingbar in klaren Verhältnissen zu arbeiten. Das erleichtert den Alltag und ermöglicht es zu abstrahieren, komplexe Algorithmen zu entwickeln und Probleme genial zu lösen – oder noch besser: Excellent zu arbeiten.
Redet man schlecht über Handwerker dann sagt man ihnen häufig ungenaues arbeiten nach. Wie ist das wenn man zunächst vor seiner eigenen Tür kehrt? Das fängt für mich bei der Benennung von Klassen an und geht weiter über die Struktur wie Klassen physikalisch abgelegt werden. Für Microsoft Entwickler heißt das bspw. das die Struktur der Solution klar der Ordnerstruktur entspricht und noch abgefahrener: Ich setze voraus das Namensräume entsprechend angepasst werden und korrekt vergeben werden. Singular in allen Benennung. Einfache Prinzipien. Wer es schafft an solchen Grundlagen, Coding Guides und letzlich der Code Analyse vorbei zu arbeiten verdient mein Respekt und gleichzeitig vollstes Mißverständnis. Das ist ungefähr als würde man jeden Tag mit dem Auto rückwärts zur Arbeit zu fahren weil vorwärts der Standard ist.
Software Entwicklung ist eine Kunst, ja – eine Ingenieurskunst und keine Selbstverwirklichungskür. Die Kunst ist es für die Anforderungen des Kundens eine geeignet Architektur zu finden die auf Langzeit eine gute Flexibilität bietet, weiterverwendet werden kann und von den Kollegen gewartet werden kann. Daher ist ein Konsens wichtig, die Diskussion über Lösungsansätze und vor allem die Weiterentwicklung. Dazu gehört auch “Reflektion”: “Was habe ich geschafft, wo lagen die Probleme und was hätte besser laufen können?”. Ja, genau: Scrum.
Zusätzlich ist es wichtig kurzfristige Lösungsansätze im Keim zu ersticken oder schnellstmöglich wieder geradezurücken. Wenn sich jeder ein klein wenig an die eigene Nase greift wird die Ergebnis-Summe schon viel besser. Frei nach der Pfadfinderregel. Ist das Kind in den Brunnen gefallen und steckt man in einem “Brownfield” dann ist es meist schwer wieder herauszukommen. Das kann weitaus länger dauern wie man es sich erarbeitet hat.
Es gibt wenige Berichte und Artikel in den man von überzogener Qualitätssicherung in der Softwareentwicklung spricht und sehr selten lese ich Artikel mit Überschriften wie: “Wir verschwenden leider viel zu viel Zeit mit Bereinigung des Codes – lasst uns pragmatischer vorgehen.”. Nein im Gegenteil – und das sollte der Branche und jedem einzelnen zu denken geben.