Refactoring: Code optimieren - Teil 2

Zeit für Refactoring

Wann sollte man seinen Code einem Refactoring unterziehen? Diese Frage ist nicht eindeutig zu beantworten. Kent Beck und Martin Fowler haben in Martin Fowlers Buch „Refactoring“ (ISBN 3-8273-2278-2) über „Gerüche“ geschrieben, die der Code annehmen kann – und der ein Refactoring dringend erforderlich macht. Zu solchen „Gerüchen“ gehören beispielsweise folgende Besonderheiten im Code (viele dieser Gerüche beziehen sich speziell auf die objektorientierte Programmierung und ist auf die prozedurale Programmierung unter VBA angepasst):

• Gleicher oder ähnlicher Code kommt an mehreren Stellen vor. Den sollte man in einer neuen Routine unterbringen und von den entsprechenden Stellen aus darauf verweisen.

• Eine Routine ist sehr lang. Das ist dann der Fall, wenn der Routinenname den Inhalt derm Routine nicht erklären kann. Wenn beispielsweise ein aus einigen Zeilen bestehender Block einen einleitenden Kommentar erforderlich macht, sollte man prüfen, ob die Zeilen nicht in eine neue Routine ausgegliedert werden können.

• Auch zu große Module oder Klassen können auftreten. Module oder Klassen sollten zusammengehörende Funktionalität enthalten. Wenn kein klarer Zusammenhang zwischen der Klasse und dem enthaltenen Code besteht, sollten Sie den Code in eine neue Klasse oder ein neues Modul auslagern. Beispiel: Ein Formular-Klassenmodul enthält eine Routine zum Einlesen eines Verzeichnisses. Diese Routine wird dort sicher gebraucht, aber sollte sich in einem anderen Modul befinden, wo es für andere Klassen zugreifbar ist.

• Kommentare weisen darauf hin, dass der folgende Code ohne diesen Kommentar nicht oder nur schlecht zu verstehen ist. Warum also nicht den Kommentar weglassen und den Code besser lesbar machen?