Avision über die Neustrukturierung von Quellcode 6 Vorurteile gegenüber Code Refactoring

Wächst eine Anwendung, wird der Code meist irgendwann unübersichtlich. Das Code Refactoring, also „Aufräumen“ des Quellcodes, kann dabei durchaus eine Alternative gegenüber einer Neuentwicklung sein. Sechs Vorurteile entkräftet der IT-Dienstleister Avision.

Anbieter zum Thema

PresseBox - unn | UNITED NEWS NETWORK GmbH

Insider Research

Windhoff Group

Avision Europe GmbH

Bei der Modernisierung von Anwendungen favorisieren mittlerweile viele Unternehmen die komplette Neuentwicklung einer Software. Dies hängt laut dem IT-Dienstleister Avision auch damit zusammen, dass Refactoring mit einigen Vorurteilen zu kämpfen hat. Dabei sei die Neustrukturierung des Quellcodes eine wirkungsvolle Methode zur Optimierung von Anwendungen.

Die Refaktorisierung dient dazu, bereits geschriebenen Code zu vereinfachen – und das kann sowohl historisch gewachsene als auch völlig neue Applikationen betreffen. Durch Optimierung wird der Code auch für neu hinzugekommene Entwickler verständlicher und lässt sich einfacher erweitern.

Doch führten – meist unbegründete – Bedenken dazu, dass Unternehmen auf Refactoring verzichten oder eine falsche Erwartungshaltung annähmen. Avision will deshalb sechs gängige Vorurteuke über die Code-Neustrukturierung entkräften.

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.

Softwarecode müsse nicht nur funktionieren, sagt Nadine Riederer, CEO bei Avision. „Er muss auch gut lesbar und verständlich sein, denn nur dann lässt er sich effizient erweitern“. Refactoring beginne deshalb am besten schon im Kleinen und sei integraler Bestandteil der kontinuierlichen Entwicklung. „Kostspielige und langwierige Refaktorisierungsarbeiten sind dann hinfällig“, unterstreicht Riederer.

(ID:46063024)