Refactoring: Wann/Wie oft machen? Welche Gründe?

Ich mache mich grade ein bisschen über Refactoring schlau und dachte ich fage einfach mal die Programmierer:
In welchen Situationen ist es nötig und bringt es überhaupt was oder macht es mehr Arbeit als es nützt?
Wann sollte man es (laut Lehrmeineung/Theorie) machen und wie sieht es in der Praxis aus?
Müssen die Verursacher des zu verbessernden/neuzuschreibenden codes Überstunden schieben, oder wie läuft das?

Hallo Floste,
deine Fragen sind falsch gestellt. =) Das kommt immer auf den Anwendungsfall an. Es gibt Fälle da bringt Refactoring eine Menge und es gibt sicherlich auch Fälle in denen es nur minimale Qualitätsgewinne bringt (dann spart man sich das ganze).
Es bringt auf jeden Fall etwas, wenn du merkst, dass dein Design die Anforderungen nicht mehr abdecken kann. Dann sollte man refaktorieren. Es kann auch etwas bringen, wenn die die Beerbungshierarchie klarer gestalten willst, also bspw. um Redundanzen zu entfernen.
Bei uns ist Refactoring genau dann nötig, wenns nötig ist. 🙂 Optimalerweise sollte es nie nötig sein, denn dann hat man an irgendeiner Ecke nicht weit genug oder korrekt gedacht. Aus Erfahrung kann ich sagen...in Geschäftsanwendungen ist es eher selten notwendig, da die Anforderungen größtenteils von Anfang an klar sind. Bei der Frameworkentwicklung ist das bspw. anders...hier ergeben sich oft Anforderungen während der Entwicklung und dann kann es passieren, dass ein Refactoring Sinn macht.

my 2 cents

Hallo Floste,

erstmal etwas generelles zum Refactoring. Refactoring bezeichnet ganz allgemein einen Prozess, bei dem dein Programm softwaregestützt verändert wird. Zum Beispiel könnte es sein, dass dir auffält, dass ein Variablenname schlecht gewählt ist. Bevor du nun den Namen überall per Hand änderst kann das auch das Visual Studio für dich (Rechtsklick->Refactor->Umbenennen). Du könntest auch bei einer sehr lang geratenen Funktion Teile in andere Funktionen auslagern. Dazu wählst du den entsprechenden Quelltext aus und lässt ihn in eine neue Methode schreiben. Visual Studio erkennt dabei auch automatisch, welche Parameter für den Codeblock benötigt werden und passt die neu erstellte Funktion dahingehend an.
Du siehst also, dass das Thema Refactoring sich nicht um irgendwelche abstrakten Designtheorien dreht, sondern ganz praxisorientiert ist.

Gruß,
Romano

Hallo rzumbe,

Refactoring bezeichnet ganz allgemein einen Prozess, bei dem dein Programm softwaregestützt verändert wird.

Softwareunterstützung ist zwar praktisch, aber keineswegs eine Voraussetzung für Refactoring. Außerdem ist deine Definition viel zu allgemein, weil bei weitem nicht jede Veränderung des Code gleich Refactoring ist. Laut Wikipedia bezeichnet Refactoring die manuelle oder automatisierte Strukturverbesserung von Programm-Quelltexten unter Beibehaltung des beobachtbaren Programm-Verhaltens.

Du siehst also, dass das Thema Refactoring sich nicht um irgendwelche abstrakten Designtheorien dreht, sondern ganz praxisorientiert ist.

Auch das kann ich nicht unterschreiben. Natürlich sollte Refactoring einen praktischen Nutzen haben. Es ist aber durchaus sinnvoll das ganze auf Basis von sinnvollen Designtheorien zu betreiben. Das Programm einfach nur unter unter Beibehaltung des beobachtbaren Programm-Verhaltens zu verändern ist ja kein Selbstzweck, sondern es sollte ja auch eine tatsächlicher Verbesserung eintreten. Wie Wikipedia sagt: "Dabei sollen die Lesbarkeit, Verständlichkeit, Wartbarkeit und Erweiterbarkeit verbessert werden, mit dem Ziel, den jeweiligen Aufwand für Fehleranalyse und funktionale Erweiterungen deutlich zu senken."

Hallo Floste,

In welchen Situationen ist es nötig und bringt es überhaupt was oder macht es mehr Arbeit als es nützt?

das zuletzt gesagt wäre, dann auch schon eine erste Antwort auf deine Fragen.

Müssen die Verursacher des zu verbessernden/neuzuschreibenden codes Überstunden schieben, oder wie läuft das?

Refactoring wird man normalerweise nicht zum Selbstzweck betreiben, sondern um irgendwelche Einsparungen an anderer Stelle zu realisieren. Wenn der Code vertrackt genug ist, kann es sein, dass es schneller ist, den Code erst einem Refactoring zu unterziehen und erst dann eine Erweiterung vorzunehmen, statt die Erweiterung direkt im originalen Code vorzunehmen. Die Frage müsste also lauten, bekommen die Entwickler die Stunden frei, die sie durch Refactoring in der Summe letztendlich einsparen? Die Antwort ist: nein. 😃

herbivore

@marcelk:
Wenn man alle Zeit der Welt zum Design und der Weiterentwicklung von Software hat, dann braucht man Refactoring eher nicht.

Wenn man aber mit agilen Methoden und damit mit KISS arbeitet, wird es immer notwendig sein, die Sourcen zu refactorieren.
Hierbei sollte man allerdings wie herbivore schon sagte daran denken "Refactoring to Pattern" zu betreiben.

Bevor hier der Eindruck entsteht agile Methoden würden per seh also schlechten code bedeuten mal der Hintergrund dazu.

Bei agiler Entwicklung wird genau so viel geplant und entwickelt wie der Kunde haben will, nicht weniger aber eben auch nicht mehr.
Denn wer weiss schon was dem kunden als nächstes einfällt, und vor allem ob ihm was einfällt.

Warum soll ich ihm also eine 3-x Tier Anwendung mit Failsaveclustern entwickeln, wenn er "nur" eine Lagerverwaltung für ein einziges Lager haben will?
Wenn er dann aber im nächsten Schritt seine xyz angebunden haben will, kann/muss man den vorhandenen Code eben refactorieren um die neuen Vorgaben zu erfüllen.
Dies bezahlt der Kunde dann aber eben erst wenn die neuen Anforderungen entstehen, und nicht schon im ersten Schritt.

@Fzelle

Bin absolut bei dir. Ich kann nur nicht den Abschnitt in meinem Post finden, der sagt, dass Refactoring per se was schlechtes ist. Ich sagte nur, dass es im "Optimalfall" nicht notwendig ist. Wie oft tritt der Optimalfall ein? Richtig....so gut wie nie. Und deshalb ist Refactoring ja, wie ich auch geschrieben habe, sinnvoll zur Verbesserung der Codequalität.

Mag ja sein, dass ich schlecht programmiere oder Plane. Aber ich Refactor eigentlich andauernd.

Gerade bei Implementierung von Algorithmen überlege ich mir, wie ich das strukturiere und implementiere dann. Meistens finde ich aber nach der Implementierung, dass ein paar Methoden zu lang geworden sind, andere Klassen plötzlich doch ihren Aufgabenbereich etwas verschoben oder zwei Aufgaben übernommen haben. Dann gehe ich halt nochmal drüber und refactor.

Ist aber vielleicht auch eine Frage des Arbeitsstils. Auch wenn ich Texte verfasse schreibe ich erstmal ins Grobe den Inhalt und kümmer mich nachher um die Feinheiten, formuliere um, Zerteile Absätze etc. Also quasi Refactoring...
Andere (gerade ältere Semester, die ohne PC aufgewachsen sind) schreiben einen Text von oben nach unten runter.

Fazit: Wenn man die Pfadfinder-Regel nach CCD berücksichtigt (verlasse jeden Code immer ein Stück sauberer, als du ihn vorgefunden hast), refactored man andauernd. Wenn auch nur minimal.

Viele Grüße,
Uwe

Müssen die Verursacher des zu verbessernden/neuzuschreibenden codes Überstunden schieben, oder wie läuft das?

Wieso sollte er? In den meisten Fällen refaktorisiert man ja nicht weil Code schlecht ist, sondern weil er veränderten Anforderungen nicht mehr entspricht. Das hat (fast) nichts mit schlechtem Code zu tun, von daher ist Refactoring ein normaler Bestandteil der Evolution von Code.

Wobei leider die meisten Projektleiter eine falsche Auffassung von Refactoring haben und das eher mit "Bugfixen" gleichsetzen.

jm2c
david

in letzter zeit amche ich auch einiges in richtung frameworkupdate-refactoring.

wenn ich z.b. über code stolpere, das noch aus .net 1 beta stammt und ich eine methode sehe, die es damals einfach noch nciht gab und manuell ausimplementiert war, dann mach ich ein kurzes refactoring zu .net 3.5 bzw seit neuestem .net 4.0 code.

so werden aus 300 zeilen code nur noch eine zeile und die fehleranfälligkeit und der wartungsaufwand sinkt. (manchmal steigt dabei auch die performance, wenn man typsivherheit einbaut und die ganzen casts enfernt...oder wenn man ein gut gemeinten sortieralgorithmus durch den frameworkalgo ersetzt...)

@marcelk:

Aus Erfahrung kann ich sagen...in Geschäftsanwendungen ist es eher selten notwendig, da die Anforderungen größtenteils von Anfang an klar sind.

Das wäre schön, passiert aber wohl eher in Behörden.

Wir refactoren immer, wenn wir etwas sehen, dass schöner/lesbarer oder performanter gemacht werden kann. überstunden schieben muss man deswegen nicht - sonst würde ja niemand mehr refactoren 😉

Da wir TDD (soweit als möglich/sinnvoll) entwickeln, schreiben wir immer zuerst Code, der die zugehörigen Tests erfüllt und dann schauen wir den Code an, ob da noch etwas gemacht werden kann... Der Test ist ja vorhanden und so geht das ganz schnell und man weiss immer, wenn man etwas fehlerhaft refactored hat.

Wie hoch der Prozentsatz an Refacotring sein sollte in Bezug auf die gesamte Entwicklungszeit, kann ich dir leider nicht sagen (ich hab gemeint der liegt so bei 30% Refacotring vs 70% Implementation)