Ihr Code funktioniert – aber das heißt nicht, dass er gut ist
\n\nSie haben ein Skript geschrieben. Es läuft. Die Kunden sind zufrieden. Aber ein Monat vergeht, und Sie betrachten entsetzt genau die Funktion, die auf 200 Zeilen angewachsen ist. Darin sind API-Aufrufe, DOM-Manipulationen und irgendeine Magie mit Daten vermischt. Kommt Ihnen das bekannt vor?
\n\nWillkommen in der Welt, in der Refactoring von JavaScript-Code keine Marotte eines Perfektionisten, sondern eine lebensnotwendige Notwendigkeit ist. Wenn Sie möchten, dass Ihr Projekt lange lebt und nicht bei der ersten Änderung auseinanderfällt, ist dieser Artikel genau das Richtige für Sie.
\n\nWas Refactoring ist und was es nicht ist
\n\nBeginnen wir mit dem Wichtigsten. Refactoring von JavaScript-Code ist der Prozess der Änderung der internen Struktur eines Programms, ohne dessen externes Verhalten zu verändern. Sie fügen keine neuen Funktionen hinzu, Sie beheben keine Fehler. Sie machen den Code lediglich sauberer, verständlicher und leichter wartbar.
\n\nViele verwechseln Refactoring mit Neuschreiben. Das sind unterschiedliche Dinge. Neuschreiben bedeutet, dass Sie den alten Code verwerfen und von Grund auf neu schreiben. Refactoring ist Evolution, nicht Revolution. Sie ändern den Code in kleinen Schritten und überprüfen jedes Mal, dass nichts kaputt gegangen ist.
\n\nWann sollte man ein Refactoring von JavaScript durchführen?
\n\nHier sind einige sichere Anzeichen dafür, dass Ihr Code um Hilfe schreit:
\n\n- \n
- Die Drei-Regel. Wenn Sie dasselbe Codefragment zum dritten Mal kopieren – ist es Zeit, es in eine separate Funktion auszulagern. \n
- Die Monster-Funktion. Eine Funktion, die länger als 30–40 Zeilen ist und sich nicht auf einen Blick erfassen lässt. \n
- „Magische Zahlen“. Im Code verstreute Zahlen wie
86400000oder42ohne Kommentare oder Konstanten. \n - Globale Variablen. Wenn Sie Angst haben, eine Variable zu ändern, weil Sie nicht wissen, wo sie sonst noch verwendet wird. \n
- Tests. Wenn Sie Angst haben, Änderungen vorzunehmen, weil es keine automatischen Tests gibt – das ist das erste Warnsignal. \n
Es gibt aber auch Situationen, in denen ein Refactoring nicht nötig ist: vor einer Deadline, in der Produktion ohne Tests, oder wenn der Code schnell für einen Prototypen geschrieben wurde, der morgen weggeworfen wird.
\n\nRefactoring-Techniken für JavaScript: Vom Einfachen zum Komplexen
\n\n1. Funktion extrahieren (Extract Function)
\n\nDie beliebteste und sicherste Technik. Sie finden ein Codefragment, das gruppiert werden kann, und lagern es in eine separate Funktion aus.
\n\n// VOR dem Refactoring\nfunction calculateInvoice(items) {\n let total = 0;\n for (let item of items) {\n total += item.price * item.quantity;\n }\n let discount = 0;\n if (total > 1000) {\n discount = total * 0.1;\n }\n return total - discount;\n}\n\n// NACH dem Refactoring\nfunction calculateSubtotal(items) {\n return items.reduce((sum, item) => sum + item.price * item.quantity, 0);\n}\n\nfunction calculateDiscount(total) {\n return total > 1000 ? total * 0.1 : 0;\n}\n\nfunction calculateInvoice(items) {\n const subtotal = calculateSubtotal(items);\n const discount = calculateDiscount(subtotal);\n return subtotal - discount;\n}\n\n\nWas hat sich geändert? Jede Funktion ist jetzt für eine einzige Aktion verantwortlich. Sie können calculateSubtotal an anderer Stelle wiederverwenden und calculateDiscount lässt sich leicht separat testen.
2. Magische Zahlen durch Konstanten ersetzen
\n\nVerwenden Sie niemals „nackte“ Zahlen im Code. Nach einem Monat werden Sie sich selbst nicht mehr daran erinnern, was 86400000 bedeutet.
// SCHLECHT\nif (Date.now() - lastLogin > 86400000) {\n // erneute Anmeldung anfordern\n}\n\n// GUT\nconst MILLISECONDS_IN_A_DAY = 24 * 60 * 60 * 1000;\nconst ONE_DAY_MS = 86400000; // oder einfach eine lesbare Konstante\n\nif (Date.now() - lastLogin > ONE_DAY_MS) {\n // erneute Anmeldung anfordern\n}\n\n\n3. Vereinfachung von Bedingungskonstrukten
\n\nKomplexe verschachtelte if-else-Anweisungen sind der größte Feind der Lesbarkeit. Verwenden Sie frühe Rückgaben (early return) und ternäre Operatoren.
<