Refactoring? – Papperlapapp! Es läuft doch!

Das folgende Szenario erleben Softwareentwickler insbesondere zu Beginn ihrer Karriere häufig. Vielleicht hilft dir diese Geschichte, den Wert von Refactoring, TDD und Clean Code besser einschätzen zu können.

Eine vielleicht nicht ganz unbekannte Geschichte

Endlich geschafft! Du hast dich tagelang gequält und nun funktioniert endlich das Modul, das schon seit langem fertiggestellt sein sollte. Durch Versuch und Irrtum hast du viele Varianten durchgespielt. „Keine Zeit mehr für Aufräumarbeiten“ denkst du dir, checkst den Code ein und lieferst das Modul aus.

Die neue Klasse hat zwar 1000 Zeilen, ist zuständig für den Aufbau der Datenbankverbindung und weitere 100 Dinge aber was soll’s? Es läuft und Änderungen an diesem Modul sind sowieso unwahrscheinlich!

Zwei Jahre später ist es soweit. Der Kunde ruft an und fordert eine Anpassung in diesem Modul. „Sie hätten ein super System für die Verwaltung der Datenbasis des Moduls angeschafft und nun sollen die Daten nicht mehr nur von der Datenbank, sondern auch per Webservice geladen werden können.“

„Das sollte ja kein Problem sein!“ denkst du dir. Nach einem kurzen Blick auf die Klasse kommst du zum Entschluss, dass es wohl besser wäre, das Modul neu zu coden. Du teilst dem Kunden mit, dass die Änderung mehrere Tage Aufwand bedeutet und frühestens in einem Monat fertiggestellt werden kann…. Mist!

Was ist schiefgelaufen?

Ich denke es gibt in diesem Fall mehrere Aspekte die in Betracht gezogen werden sollten.

  • Unstrukturiertes Vorgehen: Die Lösung entsteht oft durch unkontrollierten Versuch und Irrtum, was bei neuen, eher unbekannten Anforderungen zwar häufig vorkommt, mit den geeigneten Hilfsmitteln und Methoden jedoch auch kontrollierter erfolgen kann.
  • Fehlendes Wissen: Entwickler wissen oft nicht, wie strukturelle Änderungen am Source Code kontrolliert und sicher durchgeführt werden können, ohne das beobachtbare Verhalten zu ändern.
  • Fehlendes Sicherheitsnetz: während der Implementierung erstellt der Entwickler keine Unit Tests, die wichtige Funktionen und Etappenziele absichern.
  • Zeitdruck: je näher der Abgabetermin rückt, desto geringer ist die Bereitschaft die „funktionierende“ Lösung nochmal zu ändern, um ein wartungsfreundlicheres Design zu erhalten.

Testgetriebene Entwicklung & kontinuierliches Refactoring können helfen

Das Kernproblem liegt darin, dass gerade junge Entwickler /-innen oft nicht wissen, wie  Software durch die richtige Methodik wartungsfreundlich bleibt.

Mit Testgetriebener Softwareentwicklung lassen sich kleine Schritte zum Ziel realisieren. Die Unit Tests beschreiben diese und dienen als Leitfaden. Sie können bei Bedarf wieder verworfen werden und helfen schließlich unbeabsichtigte Änderungen an wichtigen Funktionen bei „Aufräumarbeiten“ zu identifizieren.

Lasst uns daran arbeiten!

Wie gehst Du damit um? Ich würde mich über Kommentare freuen.