Refaktorisierung komplexer PHP-Anwendungen

GSWE ist spezialisiert für die Refaktorisierung komplexer PHP-Anwendungen. In unser PHP-Agentur refaktorisieren erfahrene PHP-Programmierer mit entsprechenden Standards, Methoden, Prinzipien und Best Practices für ein professionelles Code Refactoring.

Gute Entwickler zeichnen sich durch die Qualität ihres Codes aus. In der Softwarebranche bedeutet das Schreiben von gutem Code, das Geld zu sparen, das möglicherweise in das Testen, Aktualisieren, Erweitern oder Beheben von Fehlern investiert wird.

Einige Software-Projekte werden unter dem Druck geführt, möglichst viele Features in kürzester Zeit zu veröffentlichen. Die zuständige Programmierer unterliegen der Verlockung vermeintlich Zeit zu sparen, in dem Sie z.B. Tests auslassen.

In der Folge entstehen komplexe Anwendungen, die notdürftig am Leben gehalten werden ohne das Problem nachhaltig zu lösen.

Refaktorisierung PHP basierter Anwendungen

In diesem Artikel zeige ich Ihnen Beispiele aus der Praxis für einige Techniken und Ideen, die Ihnen helfen werden, Ihren Legacy-Code zu bereinigen und ihn umzugestalten, um ihn robuster und modularer zu machen. Diese Techniken helfen Ihnen nicht nur dabei, Ihren alten Code umzugestalten, sondern geben Ihnen auch tolle Ideen, wie Sie von nun an sauberen Code schreiben können.

Grundlegende Regeln beim Refactoring von PHP-Codes

Die Arbeit im Refactoring umfasst Techniken und Schritte, den bestehenden Code (Legacy Code) durch neuen Code zu ersetzen. Ziel der Refaktorisierung ist, dass der Code danach sehr gut lesbar, erweiterbar und wiederverwendbar ist, ohne das viel Code bearbeitet werden muss.

Nachfolgend zeigen wir Ihnen Beispiele für das Refactoring eines Legacy-Codes und dessen Verbesserung auf, damit Sie nachvollziehen können, worauf wir konkret achten.

Refaktorisieren Sie niemals einen Produktionscode, der keine Unit-Tests hat

Wir empfehlen, niemals mit dem Refactoring eines Legacy-Codes zu beginnen, der keine ordnungsgemäßen Unit-Tests hat. Der Grund ist offensichtlich: Sie werden am Ende kaputte Funktionalitäten haben, die schwer zu reparieren sind, weil Sie nicht herausfinden können, was kaputt ist. Wenn Sie es also umgestalten müssen, beginnen Sie damit, es zuerst zu testen. Stellen Sie sicher, dass der Teil, den Sie umgestalten möchten, von den Tests abgedeckt wird.

Beginnen Sie mit dem Refactoring am tiefsten Punkt Ihres Codes

Schauen Sie sich das nächste Bild an. Dies ist ein echtes Projekt für ein Hotel[management](https://hackernoon.com/tagged/management)system, das ich auf Github gefunden habe. Dies ist ein echtes Open-Source-Projekt, also kann die geschlossene Quelle am schlimmsten sein.

Beispiel: Refactoring tiefste Punkte zuerst

Wie Sie in dieser Methode sehen können, gibt es drei rot markierte Ebenen. Der tiefste Punkt sollte die verschachtelte if/else-Anweisung innerhalb der ersten if-Bedingung sein. Normalerweise liegt der tiefste Punkt darin, sich auf eine einzelne Logik zu konzentrieren, die das Refactoring erleichtert.

Machen Sie Ihre Methoden kürzer, indem Sie sie in kleinere Methoden oder Konfigurationsdateien/DB-Tabellen aufteilen

Vielleicht können wir es in diesem Fall wie folgt in eine private Methode extrahieren:

Wir kürzen die Funktionen

Der nächste tiefste Punkt wird das Abrufen der Beitragsdaten und das Laden der Ansichten sein. Schauen Sie sich nun die Methode add() an, nachdem Sie die anderen Teile umgestaltet haben. Es ist viel sauberer, lesbarer und testbarer.

Beispiel: Refactoring tiefste Punkte zuerst

Verwenden Sie immer {} innerhalb von if-Anweisungen

Die meisten Programmiersprachen unterstützen einzeilige if-Anweisungen und einige Entwickler verwenden sie, weil sie kurz sind. Sie sind aber nicht gut lesbar und können leicht Probleme verursachen. Eine leere Zeile kann die Bedingung unterbrechen und zum Absturz führen. Sehen Sie den Unterschied zwischen den beiden Beispielen:

Beispiel: Verwenden Sie geschweifte Klammern

Verwenden Sie keine magischen Zahlen oder magischen Zeichenfolgen:

Im nächsten Beispiel bemerken Sie, dass bei mehr als 250 Zimmern eine Fehlermeldung zurückgegeben wird. In diesem Fall gilt 250 als magische Zahl. Wenn Sie nicht der Entwickler sind, der es geschrieben hat, wird es schwierig sein, herauszufinden, was es darstellt.

Beispiel: magische Zahlen

Um diese Methode umzugestalten, können wir herausfinden, dass 250 die maximale Anzahl von Räumen ist. Anstatt es fest zu codieren, können wir es daher in die Variable $maxAvailableRooms extrahieren. Jetzt ist es für andere Entwickler verständlicher.

Beispiel: Magische Zahlen korrigieren

Verwenden Sie keine else-Anweisungen, wenn Sie nicht müssen:

In derselben Funktion availablerooms() bemerken Sie die if-Anweisung, in der wir den else-Teil leicht entfernen können und die Logik immer noch dieselbe ist.

Beispiel: Ignoriere die else-Anweisung

Verwenden Sie aussagekräftige Namen für Ihre Methoden, Variablen und Tests

Im folgenden Beispiel sehen Sie, dass es zwei Methoden aus dem Hotelverwaltungssystem mit den Namen „index() und room_m()“ gibt. Für mich kann ich nicht bestimmen, was ihre Zwecke sind. Ich denke, es wäre einfacher zu verstehen, wenn ihre Namen beschreibend wären.

Beispiel: schlechte Methodennamen

Nutzen Sie die maximalen Möglichkeiten Ihrer Programmiersprache

Viele Entwickler nutzen nicht die vollen Möglichkeiten der von ihnen verwendeten Programmiersprache. Viele dieser Funktionen können Ihnen viel Aufwand ersparen und Ihren Code robuster machen. Sehen Sie sich die nächsten Beispiele an und sehen Sie, wie einfach es sein kann, das gleiche Ergebnis mit weniger Code zu erzielen, indem Sie einfach den Typhinweis verwenden.

Ich möchte mit ein paar weiteren schnellen Tipps zum besseren Codieren enden

  • Verwenden Sie eine neue Array-Form [ ] anstelle des alten array().
  • Verwenden Sie den Operator === anstelle von ==, es sei denn, es ist wichtig, den Datentyp nicht zu prüfen.
  • Es ist immer eine gute Idee, öffentlichen Methoden kurze, aussagekräftige Namen zu geben. Es ist in Ordnung, dass private Methoden längere Namen haben, da sie einen begrenzten Gültigkeitsbereich haben.
  • Verwenden Sie nur allgemeine Namen für Methoden, die Schnittstellen implementieren, z. B. add(), und verwenden Sie beschreibende Namen für einzelne Klassenmethoden addUser() oder addDocument().
  • Entfernen Sie ungenutzte Methoden aus Ihren Klassen.
  • Verwenden Sie das Präfix is/has mit Funktionen, die boolesche Werte zurückgeben, z. B.: isAdmin($user), hasPermission($user).
  • Verwenden Sie immer Zugriffsmodifikatoren in Klassenmethoden und Eigenschaften.
  • Seien Sie vorsichtig mit Schnittstellenverschmutzung: Verwenden Sie nur Methoden, die Benutzer öffentlich verwenden können.
  • Organisieren Sie Klassenmethoden, bei denen öffentliche Methoden ganz oben stehen.
  • Wenden Sie in Ihrem Unterricht immer das Konzept der Einzelverantwortung an.