Ziel ist es, Programme in kleinere Komponenten zu zerlegen
Eines der Dinge, über die Programmierer oft sprechen, ist der Wunsch, Programme in kleinere Komponenten oder Funktionen zu zerlegen, damit sie leichter zu verfolgen, zu lesen und zu debuggen sind.
Aber es ist nicht ungewöhnlich, monolithische Funktionen mit vielen Codekommentaren zu sehen, die helfen, zu erklären, was im Programm vor sich geht.
Ich klopfe das nicht wirklich ab, weil ich die Einschränkungen nicht kenne, unter denen ein Programmierer arbeitete. Das ist:
- Welches Budget hatte er/sie beim Erstellen des Programms?
- Wie viel Zeit wurde für die Fertigstellung des Projekts eingeräumt?
- Haben viele Leute an dem Projekt gearbeitet?
- Hatte der Programmierer Zeit, den Code zu schreiben, damit er ihn testen, umgestalten oder einfach lesbarer machen konnte?
Kurz gesagt, es gibt viele Gründe – glaube ich – dafür, dass wir „schlechten Code” lesen können, und es muss nicht immer die Schuld des Programmierers sein (das ist nur das Natürlichste, was wir beim Lesen wegwerfen müssen etwas, das wir nicht mögen).
Bedeutet dies jedoch, dass wir nicht danach streben sollten, Code so umzugestalten oder zu schreiben, dass er leichter verständlich ist? Natürlich nicht. Angenommen, wir haben die Zeit dafür, wie könnten wir es tun?
Brechen Sie Programme in kleinere Komponenten auf
Wenn es darum geht, über ein Thema wie dieses zu schreiben, kann es eine Herausforderung sein, insbesondere in einer Wirtschaft, die so aktiv ist wie der E-Commerce in WordPress.
„Lass uns konkret werden, Bob.”
Das heißt, ich kann sehr detailliert darüber schreiben, indem ich eine Reihe von Plugins verwende, die Daten anschaue, Abfragen seziere und zeige, wie es geht. Oder ich kann es auf einer etwas höheren Ebene darüber schreiben, mit dem ultimativen Ziel, zu zeigen, wie man Programme in kleinere Komponenten zerlegt.
Da es so viele Möglichkeiten gibt, Ersteres zu erreichen, entscheide ich mich für Letzteres. Das heißt, es werden nicht unbedingt bestimmte Plugins verwendet, sondern direkte Abfragen. Es wird jedoch High-Level-Beispiele verwenden, um Ihnen zu helfen, durch eine Reihe von Abfragen und Schleifen zu gehen und sie in kleinere Funktionen aufzuteilen.
Ein generisches Beispiel
Nehmen wir zum Beispiel an, ich arbeite an einer Funktion eines WordPress-Plug-Ins, das letztendlich dazu dient, alle verschiedenen Zahlungsmethoden abzurufen, die ein Benutzer gespeichert hat und die mit seinem Konto zusammenhängen.
Die Herausforderung besteht darin, dass diese Informationen über mehrere Datenbanktabellen verstreut sind (aufgrund verschiedener verwendeter Plugins), sodass einige Abfragen ausgeführt und dann abgerufen werden müssen.
Die Schritte zum Erstellen solcher Abfragen könnten etwa so aussehen:
- Abrufen der Kunden-ID des aktuellen Benutzers,
- Erhalten Sie alle Auftrags-ID-Nummern für den Kunden
- Bestimmen Sie, welche Zahlungsmethoden für jede Bestellung verwendet wurden
- die genannten Zahlungsmethoden abrufen und dann die Informationen an den Kunden senden
Je nachdem, wie die Datenbank eingerichtet ist, abhängig von Ihren SQL-Kenntnissen und je nachdem, wie die verschiedenen Plugins für die Verarbeitung aller oben genannten Daten zusammenarbeiten, kann es einfach sein, eine große Abfrage zu schreiben, um diese Informationen abzurufen.
Aber wenn Sie mit eCommerce in WordPress und verschiedenen Plugins gearbeitet haben, wissen Sie, dass es nicht immer so einfach ist.
Stattdessen sehen Sie sich etwas an wie:
- wir müssen ein Kundenprofil aus den Benutzermetadaten abrufen,
- wir müssen alle Bestellungen finden, die der Benutzer getätigt hat, und dies kann oft mit dem Post oder der Post-Metadatentabelle verknüpft sein,
- Die Zahlungsmethoden können sehr wahrscheinlich in ihrer Tabelle gespeichert werden, die dem Benutzer durch eine Art Token zugeordnet ist.
- Das obige Token befindet sich in einer Tabelle und bezieht sich auf eine bestimmte Information in einer anderen Tabelle, aus der Sie dann ableiten müssen, indem Sie sich die Daten ansehen, die in der gesamten Datenbank vorhanden sind.
Letztendlich müssen Sie nur eine Reihe von Abfragen erstellen, indem Sie zunächst verstehen, wie Sie die gesuchten Daten abfragen. Das ist so schon herausfordernd genug. Aber wenn Sie dazu kommen, nehmen wir an, Sie schreiben Ihre Abfragen sequentiell und verwenden dann die Ergebnisse von jeder, um zu Ihrer gewünschten Ausgabe zu gelangen.
Das kann so etwas ergeben :
Aber es muss nicht so sein.
Erstens sind dies alles unabhängige Abfragen mit unabhängigen Ergebnissätzen, obwohl sie zusammen verwendet werden müssen. Das bedeutet, dass wir sie auseinander brechen und die Ergebnisse jedes einzelnen auswerten können, bevor wir mit dem nächsten Schritt fortfahren.
Darüber hinaus ermöglicht es uns, kleinere, zusammenhängendere Funktionen zu schreiben. Auch wenn sie voneinander abhängen, können wir jede Funktion so einrichten, dass sie ein Argument akzeptiert (oder eine Reihe von Argumenten, aus denen wir alle Informationen abrufen können).
Vielleicht sieht das Endergebnis so aus :
Natürlich kann ich kein aktuelles SQL zeigen – na ja, zumindest nicht überall – weil ich weder den generellen Aufbau kenne noch genau weiß, mit welchen Plugins oder Schemas du arbeitest.
Aber darum ging es in diesem Beitrag nie.
Stattdessen ist der letzte Punkt, den ich zu vermitteln versuche, folgender: Auch wenn wir unter sehr begrenzten Einschränkungen arbeiten, können wir Programme immer noch in kleinere Komponenten zerlegen, die uns helfen, zu beschreiben, was passiert, zu verstehen, wie es gemacht wird, und dann Daten zu senden hin und her zwischen verschiedenen Funktionen und zum und vom Benutzer.