50 Lines of Code lesen oder Extract Method Refactoring verwenden? - Einblicke von Derek Comartin

Das Beispiel: Benutzeranmeldung in einem Chat-System

Zu Beginn des Videos stellt Derek ein Beispiel vor: eine Anmeldefunktion für ein Chatsystem. Es handelt sich um einen kompakten, aber realistischen Codeblock von etwa 50 Zeilen, der mehrere Aufgaben erfüllt:

• Prüft, ob der Nutzername nicht leer ist

• Überprüft, ob der Benutzername bereits vergeben ist

• Bearbeitung von Kanälen mit Altersbeschränkung

• Speichert das neue Benutzerobjekt

• Versendet eine E-Mail mit einem Aktivierungslink

Dieser Code befindet sich in einer Funktion und sieht auf den ersten Blick wie ein guter Kandidat für das Refactoring von Extraktmethoden aus. Aber wie Derek warnt, kann ein blindes Refactoring, ohne die Auswirkungen zu verstehen, die Klarheit tatsächlich beeinträchtigen.

Beginn mit Refactoring: Methode zum Extrahieren auswählen

Derek fängt dort an, wo viele Entwickler es tun: Er zerlegt das Codefragment in kleinere Teile. Er zeigt, wie man Extract Method entweder über das Kontextmenü oder eine Tastenkombination in den meisten IDEs oder Code-Editoren auswählt.

Er extrahiert:

• validateUsername, um zu überprüfen, dass der Benutzername nicht leer ist

• existingSignUpNotActivated, um nach einem nicht aktivierten Konto zu suchen

• validateExistingUser, um alle Prüfungen auf vorhandene Benutzer durchzuführen

• filterAgeRestrictedChannels zur Verarbeitung von Kanälen für Benutzer unter 18 Jahren

• sendEmail, um die Willkommens-E-Mail zu versenden

Er gibt jeder neuen Funktion einen aussagekräftigen Namen, was einer der wichtigsten Tipps ist, die in der Clean-Code-Praxis oft propagiert werden. Doch während er diese modifizierten Versionen durchgeht, beginnt Derek, auf die Risse in der Logik hinzuweisen - nicht in der Funktionalität, sondern in der Lesbarkeit und im Kontrollfluss.

Aufgabe 1: Versteckte Implementierungsdetails

Eine der ersten roten Fahnen, auf die Derek hinweist, ist, dass Implementierungsdetails nun hinter extrahierten Methoden versteckt sind.

Zum Beispiel lösen die Methoden validateUsername und validateExistingUser tatsächlich Ausnahmen aus. Aber als Entwickler, der den refaktorisierten Code liest, hat man keine Ahnung, wenn man nicht auf die Interna zugreift.

Diese Art des Refactorings kann Steuerlogik verbergen, was zu Fehlern oder fehlenden Validierungen führt. Der Umfang und die Abläufe sind nicht mehr offensichtlich. Anstatt den Code klarer zu machen, schaffen Sie ein Labyrinth von Abstraktionen, in dem Nebeneffekte wie Ausnahmen oder geänderte Variablen nicht mehr in der Form sichtbar sind, in der die Logik ursprünglich geschrieben wurde.

Ausgabe 2: Indirektion und verkettete Auszüge

Als Nächstes weist Derek auf das Problem der Indirektion hin - wenn eine Extraktmethode eine andere aufruft und so weiter. Er zeigt, wie die Methode validateExistingUser selbst aus existingSignUpNotActivated zusammengesetzt ist.

Sie lesen nicht länger einen einfachen Top-Down-Codeblock. Sie springen zwischen Methoden, Dateien und Klassen hin und her, nur um zu verfolgen, was passiert. Und während der Editor bei der Navigation durch diesen Fluss helfen kann, wird er für den Leser zu einer kognitiven Belastung.

Noch schwieriger wird dies bei größeren Systemen, bei denen sich das Refactoring über mehrere Dateien oder Komponenten erstreckt. Plötzlich erscheint Ihr "sauberer Code" schwieriger zu verstehen als die ursprünglichen "unordentlichen" 50 Zeilen.

Ausgabe 3: Lokale Variablen und mutierender Zustand

Eine der wichtigsten Lektionen in diesem Video bezieht sich auf den Umgang mit lokalen Variablen und Zustandsmutation.

Derek stellt die Methode filterAgeRestrictedChannels in den Mittelpunkt. Es wird kein Ergebnis zurückgegeben, sondern die übergebene Kanalliste wird direkt geändert. Das bedeutet, dass Sie den lokalen Zustand innerhalb einer anderen Methode ändern, und wenn Sie die Methode nicht genau untersuchen, bleibt diese Änderung verborgen.

Dies bricht mit der Erwartung, dass eine Funktion entweder eine reine Operation ist oder deutlich signalisiert, wenn sie etwas verändert. Wenn Sie eine Logik durch eine neue Methode ersetzen, die keine Werte zurückgibt, sondern sie intern ändert, schaffen Sie Risiken und Verwirrung.

Dereks refaktorisierte Alternative

Wie refaktorisiert Derek eigentlich seinen alten Code?

Er schlägt einen viel einfacheren Ansatz vor:

1. Halten Sie selbsterklärende Logik inline. Die anfängliche Prüfung auf einen leeren Benutzernamen bleibt in der Hauptmethode, da sie leicht zu verstehen ist und die Codebasis nicht durcheinander bringt.

2. Ergebnisse zurückgeben, statt zu mutieren. Anstatt die Liste der Kanäle zu verändern, gibt die Funktion filterAgeAppropriateChannels jetzt eine gefilterte Liste zurück. Dies macht den Datenfluss klar und verhindert unerwartete Nebeneffekte.

3. Verwenden Sie einfache, vorhersehbare Extraktionsmethoden. Die einzige andere extrahierte Methode ist isExistingUserAlreadyActivated, die eindeutig einen booleschen Wert zurückgibt, ohne Ausnahmen auszulösen. Sie kapselt die Logik ein, ohne Details zu verbergen.

4. Vermeiden Sie Inline-Nebeneffekte wie das Versenden von E-Mails. Derek lässt die E-Mail-Logik zur Veranschaulichung bestehen, weist aber darauf hin, dass diese in einem echten System über ein Ereignis in einem separaten Prozess oder Thread gehandhabt werden sollte - und nicht direkt mit der Übermittlung des Benutzerformulars verbunden ist.

Insgesamt verwendet Derek nur zwei Extraktionsmethoden und belässt den Rest der Logik inline - weil es einfacher zu lesen, zu verstehen und zu kontrollieren ist.

Abschließende Tipps zum Refactoring von Extraktmethoden

Dereks Video gibt uns einige praktische Richtlinien für den effektiven Einsatz des Refactorings von Extraktmethoden an die Hand:

• Verwenden Sie aussagekräftige Namen, die genau beschreiben, was die Methode tut.

• Vermeiden Sie Nebeneffekte wie Zustandsmutation oder das Auslösen von Ausnahmen, es sei denn, sie sind offensichtlich.

• Rückgabewerte anstelle von Änderungen der Eingabeparameter.

• Verstecken Sie die Logik nicht hinter mehreren Abstraktionsebenen.

• Wenn eine Methode in ihrer ursprünglichen Form lesbar erscheint, sollten Sie sie nicht in mehrere Funktionen aufteilen, nur um des Refactorings willen.

Manchmal ist die beste Abstraktion keine Abstraktion - vor allem, wenn dies auf Kosten der Klarheit und des Verständnisses des Anwendungsbereichs geht.

Abschluss

Der Ansatz von Derek Comartin stellt die Vorstellung in Frage, dass Refactoring immer den Code verbessert. Bei der Refaktorierung von Extraktmethoden ist weniger oft mehr. Anstatt die ausgewählte Extract-Methode übermäßig zu verwenden, um Ihre Logik zu zerhacken, sollten Sie prüfen, was einen Mehrwert darstellt, was Ihren Code leichter verständlich macht und was wichtige Details verbirgt.

Mit klaren Beispielen und direktem Einblick in realen Code zeigt Derek in seinem Video, dass manchmal 50 Zeilen in einer einzigen Methode, die von oben nach unten wie eine Geschichte gelesen wird, besser sind als zehn kleinere Methoden, die über Ihre Codebasis verteilt sind.

Wenn Sie schon einmal zum Tastaturkürzel gegriffen haben, um eine neue Methode zu erstellen, denken Sie an Dereks Rat: Halten Sie inne, bewerten Sie und stellen Sie sicher, dass das Refactoring dem Leser dient - nicht nur der IDE.