Thought Leadership
Refactoring ist eine wirkungsvolle Methode zur Optimierung von Anwendungen. Indem beim Refactoring die Struktur des Quellcodes vereinfacht wird, lässt er sich leichter lesen und verstehen – und die Anwendung kann dadurch unkomplizierter, schneller und kostengünstiger um neue Funktionen erweitert werden.
Allerdings halten sich hartnäckig einige irreführende Vorstellungen und Gerüchte über diese Methode. Das führt dazu, dass in vielen Fällen aufgrund unbegründeter Bedenken Abstand vom Refactoring genommen oder die Methode mit völlig falschen Erwartungen angegangen wird. Avision entzaubert sechs gängige, aber unwahre Mythen über Refactoring.
1. Refactoring macht alles besser.
Refactoring führt nicht zu einem fachlichen Bonus. Es geht dabei ausschließlich darum, den Sourcecode „aufzuräumen“ und dadurch seine Qualität zu verbessern. Die Nutzer der Anwendung bemerken dadurch keinerlei Effekte. Die fachliche Funktion der Applikation nach außen bleibt unverändert.
2. Refactoring macht alles schneller.
Das mag in vielen Fällen ein Nebeneffekt des Refactoring sein, aber beileibe nicht in allen. Manchmal kann eine Software durch die sauberere Programmierung des Codes sogar langsamer werden; etwa, weil im ursprünglichen, wild gewachsenen Sourcecode unkonventionelle Abkürzungen eingebaut waren.
3. Refactoring ist immer teuer.
Man kann auch in kleinen, kostengünstigen Schritten Refactoring betreiben oder nach dem so genannten Pfadfindermodus vorgehen („Hinterlasse den Campingplatz sauberer als du ihn vorgefunden hast“). Das heißt: Wann immer jemand gerade am Code arbeitet und eine Verbesserungsmöglichkeit feststellt, setzt er sie direkt um. So führen viele kleine Änderungen am Ende zu einem besseren Code.
4. Refactoring dauert immer lange.
Das stimmt nicht per se. So lässt sich das Refactoring als fester Bestandteil direkt in den Entwicklungsprozess integrieren. Das hat dann zur Folge, dass die Sourcecode-Qualität beständig hoch bleibt und das Refactoring dadurch weder lange dauert noch mit zu hohen Kosten verbunden ist.
5. Refactoring ist nur bei Altanwendungen nötig.
Es ist richtig, dass vor allem Altanwendungen einem Refactoring unterzogen werden. Aber auch bei Neuentwicklungen können sich Fehler im Code einschleichen. Programmieren die Entwickler unter Zeitdruck, treten häufig“ technische Schulden“ auf, die dann durch ein Refactoring beglichen werden müssen.
6. Refactoring eignet sich nur für große Anwendungen.
Refactoring kann unabhängig von der Größe einer Anwendung sinnvoll sein. Gerade kleine Applikationen stehen häufig nicht im Fokus der IT und erhalten nicht die erforderliche Aufmerksamkeit. Das hat zur Folge, dass ihr Code im Lauf der Zeit oft ganz besonders unübersichtlich und verzweigt wird.
„Bei Softwarecode kommt es nicht nur darauf an, dass er funktioniert. Er muss auch gut lesbar und verständlich sein, denn nur dann lässt er sich effizient erweitern“, sagt Nadine Riederer, CEO bei Avision. „Deshalb beginnt das Refactoring am besten schon im Kleinen und ist ein integraler Bestandteil der kontinuierlichen Entwicklung. Kostspielige und langwierige Refaktorisierungsarbeiten sind dann hinfällig.“
www.avision-it.de
