Detaillierte Richtlinien zur Code-Refakturierung Ihrer Website

Haben Sie jemals mit dem Kopf geschüttelt, während Sie Code lasen, als Sie an einem Projekt arbeiteten? Haben Sie zumindest einmal gedacht: "Das ist kein optimaler Code – es ist möglich, ihn besser und effizienter zu schreiben"? Führt das Hinzufügen oder Ändern einer theoretisch kleinen Funktionalität auf Ihrer Seite zu unzähligen Problemen und erfordert Änderungen in vielen anderen Bereichen? Wenn die Antwort auf mindestens eine dieser Fragen "ja" lautet, könnte es an der Zeit sein, Code-Refactoring zu planen.

Was bedeutet es, Code zu refaktorisieren?

Code-Refactoring bedeutet technische Schulden zu bekämpfen. Es ist ein Prozess, chaotischen Code, der nicht den Standards und Best Practices entspricht, in sauberen Code zu verwandeln, dessen Struktur einfach, verständlich und erweiterbar ist.

Was ist sauberer Code?

Code wird als sauber betrachtet, wenn jeder im Team ihn leicht verstehen kann. Die von sauberem Code bereitgestellte Funktionalität kann leicht von allen Entwicklern im Team erweitert werden, nicht nur von dem ursprünglichen Entwickler des Codes.

Sauberer Code zeichnet sich aus durch:

• Einfachheit,
• Verständlichkeit für andere Programmierer,
• keine Duplikate,
• Minimalismus,
• volle Testabdeckung,
• einfache und kostengünstige Wartung.

Schritt 1: Wissen über eine Anwendung oder Website sammeln

Am Anfang eines Code-Refaktorisierungsprozesses sollten Sie eine gründliche Analyse der Anwendung durchführen und die Elemente hervorheben, die schwer zu entwickeln und zu warten sind. Eine hilfreiche Methode in dieser Phase (und gleichzeitig – eine der Refaktorisierungsmethoden) ist das Explorative Refactoring. Was bedeutet das? Stellen Sie einen Timer auf 25-30 Minuten und refaktorisieren Sie die Funktionalität, die Sie in dieser Zeit verstehen möchten. In diesem Punkt spielt es keine Rolle, dass die von Ihnen eingeführten Änderungen nicht optimal sind oder dass der Code nicht mehr wie gewünscht funktioniert. Der Zweck der Einführung von Änderungen besteht darin, die Funktionalität gründlich zu verstehen und den Legacy-Code zu begreifen, den Sie refaktorisieren möchten. Dieser Ansatz verkürzt die Zeit, die für die Analyse benötigt wird – statisches Codelesen wird Ihnen fast nie ein vollständiges Bild der Situation geben.

Schritt 2: Schreiben Sie die Dinge auf, die ein Problem darstellen können

Hey, ich habe mich entschlossen, an der Klasse "AplicationManager" zu arbeiten. Sie wurde überhaupt nicht getestet. Sie hat viele Verantwortlichkeiten. Außerdem ist sie sehr anfällig und hat einen Tippfehler im Namen. Diese 250-Zeilen-Methode, die sieben Parameter und zwei Flags hat, könnte nicht nur in einige Methoden, sondern in drei Klassen aufgeteilt werden. Zu diesen Schlussfolgerungen bin ich während eines Explorative Refactorings gekommen und habe außerdem festgestellt, dass wir…

Dies ist ein Beispiel für das Ergebnis der Verwendung der Methode des Explorativen Refactorings. Während der Analyse notieren Sie die Probleme, auf die Sie gestoßen sind, und mögliche Lösungen für diese Probleme. Diese Liste ist notwendig, um den korrekten und optimalen Prozess der Gestaltung der erneuerten Anwendung zu planen. Konzentrieren Sie sich in dieser Phase nicht auf Details, versuchen Sie nicht, genaue Lösungen zu definieren – dafür wird es Zeit geben.

Welche Dinge können ein Problem darstellen? In vielen Fällen haben wir das Gefühl, dass etwas mit dem Code nicht stimmt. Es betrifft so viele Menschen, dass ein solches Gefühl sogar einen eigenen Namen bekommen hat – Code Smells. Die Code Smells können gruppiert und für ein iteratives Refactoring verwendet werden.

Code Bloat

Ich weiß, dass diese Klasse bereits 648 Zeilen, viele Abhängigkeiten und Verantwortlichkeiten hat, aber ich habe schnell eine Methode hinzugefügt, weil ich sie für meine Aufgabe benötigte. Diese Klasse erschien mir passend. Was? Warum habe ich das schon sechs Mal in sechs verschiedenen, nicht zusammenhängenden Aufgaben gemacht? Wie ich Ihnen sage – es ist nur ein schneller Fix.

Code ist aufgebläht, wenn er so groß ist, dass es lange dauert, ihn zu verstehen, zu warten, zu ändern oder zu erweitern. Diese Art von Code ist teuer und schwer zu testen. Er zeichnet sich aus durch:

• lange Methoden,
• lange Klassen,
• lange Parameterlisten,
• Duplikation von Variablen in mehreren Klassen,
• Verwendung von primitiven Feldern anstelle einfacher Klassen.

Teilweise oder unangemessene Nutzung der objektorientierten Programmierung

Der Code sammelt alle Missbräuche und die falsche Verwendung der objektorientierten Programmierung – er bricht die Regeln, verliert seine Lesbarkeit. Änderungen, Wartung und Tests werden teurer.

Die Code Smells Liste in diesem Fall umfasst:

• Duplikation von Funktionalitäten,
• umfassende Switches, die durch Polymorphismus eliminiert werden könnten,
• temporäre Variablen in der Methode.

Change Blocker

Änderungen an der Klasse erfordern das Überschreiben theoretisch nicht zusammenhängender Methoden. Dies verlängert die Zeit, die für Verbesserungen oder Erweiterungen des Codes benötigt wird.

Überflüssige Codeelemente

- Während des Code Reviews bin ich auf die Variable $fooMaganer gestoßen, die Sie als "Foo Manager Variable, used to manage the Foo" kommentiert haben. Denken Sie, dass dies ein angemessener Kommentar ist?

- Ich weiß nicht, aber unsere Standards besagen, dass jede Variable kommentiert werden muss, nicht dass der Kommentar etwas beitragen soll. Also, wie wird es sein? Werden Sie genehmigen?

Überflüssige Elemente umfassen alles, was nichts zum Code hinzufügt oder nicht verwendet wird. Dazu gehören:

• Code, der übermäßig mit unnötigen Kommentaren gefüllt ist,
• Code-Duplikate,
• nicht verwendeter Code,
• nicht verwendete Klassen,
• nicht verwendete Methoden.

Connectoren

Hallo, Adam, Anna benötigt eine Liste der ersten zehn Zahlen der Fibonacci-Reihe. Bitte gib sie mir, und ich werde sie in deinem Namen weitergeben. Danke!