Refactoring
Refaktorisierung, wie es auf Deutsch heißt, beschreibt eine Methode um Software “schöner” zu machen. Jetzt fehlt nur noch die Definition von “schöner” und dieser Post ist fertig 
Das Problem von Improvisierungen ist, dass diese meist länger leben als sie sollten. Jeder hat bestimmt schonmal daheim ein Brett irgendwo untergelegt und wollte das “später” dann mal ordentlich festschrauben, oder Ähnliches. Sowas gehört zur Kategorie: “Funktioniert, warum also ändern?!”.
Ähnlich ist das bei Software. Wenn ein armer Student als Praktikant plötzlich eine Software für einen Betrieb schreiben muss, dann kann man nur hoffen, dass er was von “Design, Analyse und Implementierung” gehört hat, das Lasten- und Pflichtenhefte keine Fremdworte sind und dass Code der “ad hoc” in den PC getrimmert wird, meist nicht das Gelbe vom Ei ist. Aber selbst wenn man sich viele Gedanken gemacht hat und diese auch wunderbar mittels UML niedergeschrieben hat, jegliche Spezifikation sich aus den Fingern saugt und dann denkt das man “doch an alles gedacht hat”, so wird man doch meist von der Realität eingeholt und muss seine Software umstrukturieren. Hier greift dann die Refaktorisierung.
Natürlich gibt es auch andere Anwendungsgebiete, wie z.B. Anpassung einer Software an ein neues Betriebssystem, Erweiterung der Funktionalitäten oder Sonstiges, dies alles kann zur Refaktorisierung führen. Wichtigste Grundregel für die Faktorisierung ist aber:
Das System muss bereits laufen
Ohne ein laufendes System gibt es auch keine Refaktorisierung. Zweiter wichtiger Punkt ist die Tatsache dass die Funktionalität nicht geändert werden darf. Dies steht nicht im Widerspruch zur obigen Aussage “Erweiterung der Funktionalitäten”, da das Refactoring tatsächlich erstmal das “Aufräumen” des Codes ist um dann im Nachhinein neue Features einzubauen.
Refaktorisieren ist relativ einfach. Man will eigentlich nur folgende Ziele erreichen (zitiert aus der Wikipedia):
- Lesbarkeit
- Übersichtlichkeit
- Verständlichkeit
- Erweiterbarkeit
- Vermeidung von Redundanz
- Testbarkeit
Wer schon einmal Klassen mit ein, zwei Funktionen gesehen hat, diese aber 170-180 Zeilen Code jeweils ausmachen, der weiss wie schwer es ist sich in diesen Wulst einzulesen. Warum also, wenn man den Code eh schon verstehen muss, den Code nicht auch gleich verständlicher machen?
Die Mittel der Refaktorisierung sind simpel und meist Schritt für Schritt zu erledigen. Einen schönen Katalog dazu hat Martin Fowler (Refactoring. Wie Sie das Design vorhandener Software verbessern. Addison-Wesley Verlag, ISBN 3-8273-1630-8) erstellt, dort wird über mehrere Kapitel genau erläutert wie man Schritt für Schritt Software “schöner” macht. Ich empfehle jedem Softwaredesigner dieses Buch zumindest mal anzulesen. Ich werde es mir auch erst noch kaufen müssen, da ich bisher nur “auf der Arbeit” einen Blick reinwerfen konnte.
Man sollte sich dringend in den Wikipedia-Artikel einlesen, auch wenn dieser recht schmalbrüstig ist. Dort sind aber gute (englische) Artikel verlinkt und ausserdem hat sich jemand die Mühe gemacht den oben erwähnten Katalog von Fowler online zu stellen.
- Unit Testing
- Geschwindigkeit von Webseiten
- 3/14
- Firefox Addons selbst erstellen
- Die Not der Erklärung
If you enjoyed this post, please consider to leave a comment or subscribe to the feed and get future articles delivered to your feed reader.