Was ist „Refactoring“?

Das Thema „Refactoring“ spielt in der Soft­wareentwicklung und Softwareerneuerung eine wichtige Rolle. Es spornt IT-Unternehmen und IT-Entscheider dazu an, sich mehr damit zu befassen. Macht man sich auf die Suche nach Literatur und Informationen über dieses Thema, stellt man schnell fest, dass das Wort „Refactoring“ sehr generalistisch behan­delt wird und von Fachleuten verschieden definiert ist.

Allgemein versteht man unter Refactoring das Restrukturieren von Software-Code, wenn zum Beispiel durch Wartungen die Struktur der Software entartet ist und folglich weitere Änderun­gen schwierig macht. Mit einer kontinuier­lichen Restrukturierung kann Software leichter verständlich und leichter änderbar gemacht werden. Dabei muss drauf geach­tet werden, dass die Funktionalität beibe­halten wird und das Verhalten der Soft­ware angemessen bleibt. Dies sorgt für eine hohe Verständlichkeit und eine identi­fizierbare Verbindung zwischen Struktur und Funktion (Reißing, 1999).

Code-Smells

Mit Code-Smells oder Bad-Smells sind allgemein die Stellen in einer Software­struktur gemeint, die Programmierungs­fehler vorweisen oder nicht verständlich genug gestaltet worden sind. Diese Bad-Smells können in verschiedenen Formen im Programmcode auftauchen. Weshalb Martin Fowler einen Katalog in seinem Buch „Refactoring: Improving the Design of Existing Code“ erstellt hat, um Entwicklern einen Überblick darüber zu verschaffen. Im Folgenden werden einige wichtige Bad-Smells veranschaulicht und erklärt.

Ein Beispiel für Bad-Smells sind duplizierte Codes. Sollte eine Codestruktur mehrmals an verschiedenen Stellen im Quellcode vor­handen sein, redet man von einem „Duplicated Code“. Einem Entwickler muss hierbei immer klar sein, dass eine Software mit duplizierten Codes meistens besser ar­beitet, wenn diese überarbeitet und als ei­genständige Codes restrukturiert werden.

Probleme können auch entstehen, wenn bei komplexen Klassen oder in deren Instanzen, zu lange Codes geschrieben wer­den, auch bekannt als „Long Methods“. Sol­che Methoden benutzen oft nur wenige Teile des Codes, die aber durch Refactoring zu neuen Klassen oder als Subklassen defi­niert werden können. Mit Tools wie „Extract Method“ beispielsweise, lassen sich eben diese langen Methoden durch neue Methoden ersetzen (Fowler, 1999).

Technische Schulden

Technische Schulden entstehen meist, wenn ein Entwickler sich dafür entscheidet einfache und simple Codes für eine schnel­lere Entwicklung zulasten der Qualität zu verwenden (dirty hacks). Je öfter dies pas­siert, desto unwartbarer werden Teile des Sourcecodes und es steht eine Neuimple­mentierung an. Die verwendete Zeit um diese Fehler ausfindig zu machen und zu refaktorisieren nennt man in dem Fall „technische Schulden“. Mit dem richtigen Management und dem richtigen Zeitplan können diese Rückstände bei einem Update lokalisiert werde. Durch anschließendes Refactoring können diese neu­geschrieben und in kleinere Schulden um­gewandelt werden.

Anders als finanzielle Schulden, die unbedingt und sogar oft mit einem höheren Betrag in Form von Zinsen zurückgezahlt werden müssen, haben tech­nische Schulden den Vorteil, dass sie grundsätzlich nicht ganz beglichen werden müssen und eventuell auf eine neue Person übertragen werden können, zum Beispiel wenn ein neuer Entwickler für das Coding eingesetzt wird (Allman, 2012). Dennoch gibt es auch bei den technischen Schulden eine Zinszahlung, so werden mit zuneh­menden technischen Schulden Änderun­gen immer kostspieliger bis zu einem Zeit­punkt an dem die Prüfung der Änderung ei­nen mehrfachen Betrag der Änderung an sich verschlingt. Somit wird auch hierbei er­sichtlich, dass Refactoring im Lebenszyklus einer Software von hoher Bedeutung ist und diesem in IT-Unternehmen mehr Be­achtung geschenkt werden sollte.

Wann wird „Refactoring“ betrieben?

Refactoring ist ein laufender Prozess und ist essenziell für die Softwareentwicklung und die Softwarewartung. Sollten bei­spielsweise Klienten eine Einsicht in den Programmcode verlangen, um zu sehen, was das Entwicklerteam eigentlich macht, so kann man mit Refactoring die Software­codes verständlicher für den Auftraggeber gestalten. Der beste Zeitpunkt für eine Refactoring ist „immer“. Mit „immer“ ist jedoch nicht der ganze Arbeitsaufwand im Fokus gesetzt. Vielmehr ist es aber eine Aufgabe, die man durchgehend neben der Entwicklung bzw. der Wartung im Auge behalten muss. Gängig ist es beispielsweise nach einer Erweiterung einer Funktionali­tät (Refactoring ist nicht das Erweitern an Funktionalitäten) und deren Tests, noch­mals die Codes nach möglichen Verbesse­rungen bezüglich der Verständlichkeit zu durchforsten. So können strukturell kom­plizierte Codes schon während der Ent­wicklung mit kleinen Änderungen für eine langfristigere Lösung sorgen (Robinson, 2005).

Es gibt auch Situationen in denen es wenig Sinn macht Refactoring zu betreiben. Wenn ein neues Team die Entwicklung von einer bestehenden Software übernimmt, ist es meist eine mühsame Sache, sich mit dem geschriebenen Code vertraut zu ma­chen. Deshalb wird von Seiten der Ent­wick­ler oft gesagt, dass das Programm eine Refactoring braucht, nur weil sie den Code nicht vollständig verstehen. Deswegen sollte man auf keinen Fall wegen dem Vor­kommen von Komplikationen ein Pro­gramm neu schreiben, denn es besteht immer die Mög­lichkeit, das Code-Design so zu ändern, dass Fehler und Bugs beseitigt werden.

Fazit

Für Refactoring wird allen voran ein tüchtiges Entwickler-Team benötigt, das sich mit dem Quellcode auseinandersetzt und die fehlerhaften Stellen korri­giert. Refactoring ist ein laufender Prozess und darf deshalb nicht vernachlässigt werden. Deshalb wird es IT-Unternehmen empfohlen, sich mit dem Thema   gezielt zu befassen und mehr Zeit in die Sache zu in­vestieren. Martin Fowler, ein Vorreiter im Bereich „Refactoring“ verfasste einen Kata­log bezüglich Code-Smells. Diesen sollte sich jeder Entwickler anschauen , um sein Wissenspektrum zu erweitern, wie man diese identifiziert und passenden Lösungen findet. Fälschlicherweise wird der Begriff „Refactoring“ von vielen Entwicklern anders interpretiert und eingesetzt. Des­halb sollten Unternehmen in erster Linie herausfinden, was ihre Entwickler unter Refactoring verstehen und wie sie dieses Wissen in ihren Projekten einsetzen können.

 

Literatur

Allman, E. (2012). Managing technical debt. Communications of the ACM, 55(5), 50. https://dl.acm.org/citation.cfm?doid=2160718.2160733

Fowler, M. (1999). Refactoring: Improving the Design of Existing Code. In D. Wells & L. Williams (Hrsg.). Boston, MA, USA: Addison-Wesley Longman Publishing Co., Inc. https://doi.org/10.1007/3-540-45672-4_31

Reißing, R. (1999). Refactoring (Aktuelles Schlagwort). Informatik Spektrum, 22, 210–211.

Robinson, S. (2005, Juli 5). Refactoring optimal eingesetzt. Abgerufen von https://www.zdnet.de/39134584/refactoring-optimal-eingesetzt/