Ende 2018 fand in Samara das
Panda-Meetup # 9 Frontend statt. Bei dieser Veranstaltung habe ich mich in einer neuen Rolle versucht und eine Präsentation gemacht. Ich heiße Evgeny Kholmov. Ich bin vor mehr als 10 Jahren als Student zum Programmieren gekommen. In den letzten 5 Jahren habe ich Remote-Service-Systeme bei großen russischen Banken entwickelt, davon zwei Jahre als Manager. Während dieser Zeit war ich an der Erstellung mehrerer führender russischer Unternehmensanwendungen beteiligt, die sich mit den Schwerpunkten schwerer Architektur-, Integrations- und Prozesslösungen befassten. Aufgrund meiner Erfahrung bei der Entwicklung mehrerer großer Internetbanken sagte ich den Gästen des Mitap, welchen Nutzen es hätte, wenn Sie die Regeln eines guten Entwicklungsstils befolgen würden. Die stimmhaften Figuren beeindruckten das Publikum. Die Besprechungsteilnehmer haben mich buchstäblich mit Fragen überwältigt. Es ist möglich, dass dieses Thema unter den Lesern von Habré eine lebhafte Antwort findet.
Sie können das Video meiner Präsentation auf Youtube sehen.
Und für die Bürger von Chabrowsk habe ich eine Textversion meines Berichts vorbereitet.
Als ich Probleme mit der Lesbarkeit von Code studierte, stieß ich auf StackOverflow zu einem merkwürdigen Thema. Es wurde diskutiert, wie wichtig geschäftslesbarer Code ist und ob er wichtiger ist als Leistung und Korrektheit. Infolgedessen war laut Community-Mitgliedern das wichtigste Kriterium die Lesbarkeit des Codes.
Zu dieser Zeit war ich nicht an Problemen mit der Lesbarkeit von Code interessiert - ich entwickelte die nächste Internetbank. Das Frontend verwendete HTML5, AngularJS, LESS. Das Projekt wurde für eine der größten Banken in Russland entwickelt. Ich bin von der Promsvyazbank zu diesem Projekt gewechselt, wo ich eine sehr ähnliche Internetbank entwickelt habe: dasselbe Kundensegment, dieselbe Anzahl von Benutzern, fast denselben Technologie-Stack (HTML5, AngularJS, SCSS). Trotz der starken Ähnlichkeit der Projekte war der Übergang für mich sehr schwierig. Es geht nur um Stil. Der Code für diese Projekte war in Design und allgemeiner Lesbarkeit auffallend unterschiedlich. Wenn die Entwickler in der Promsvyazbank die Richtlinien strikt befolgten, gab es im neuen Projekt keine klaren Stilregeln.
Damals konnte ich verstehen (und sogar berechnen), welche Vorteile ein großes Projekt für strenge Styleguides bringt. Nach der Analyse der Entwicklungskosten meines neuen Projekts kam ich zu dem gleichen Ergebnis wie bei den StackOverflow-Lesern: Lesbarkeit ist das wichtigste Kriterium.
Gute Stilregeln
Für AngularJS und Angular 2+ hat John Papa, ein bekannter Experte in der Welt der Frontend-Entwicklung, Styleguides erstellt, die die Regeln für einen guten Stil bei der Entwicklung von Angular-Anwendungen beschreiben. Als ich bei der Promsvyazbank arbeitete, lernte ich diese Styleguides kennen. Das Team hat sie bei allen Projekten klar verfolgt. Bei dem neuen Projekt stammte der Code jedoch von Auftragnehmern, die nicht so ernsthaft über den Programmierstil nachdachten. Mit meinem neuen Team stieß ich auf tägliche Aufgaben, die ich zuvor gelöst hatte. Dies brachte mir jedoch keine Vorteile, sondern nur Schmerzen und Leiden.
Eine Geschichte von verlorener Zeit oder warum brauchen wir all diese Regeln
John Papas Styleguide listet viele Regeln auf. Das wiederholte Auflisten macht keinen Sinn, sie sind in der
Originalquelle perfekt dargestellt. Ich werde mich auf einige Beispiele beschränken, die die Vorteile von Expertenempfehlungen farbenfroh demonstrieren.
Beginnen wir mit einem einfachen
Fallstudie. Benutzer der Internetbank zeigten irrelevante Wechselkurse an. Ich hatte zum Zeitpunkt der Operation die Aufgabe, aktuelle Kurse zu laden. Ich habe erwartet, dass der Code für das Laden von Wechselkursen in Services und Komponenten angezeigt wird. Aber natürlich war er nicht da (sonst hätte ich nichts zu schreiben). Es stellte sich heraus, dass Wechselkurse auf der Ebene des Anwendungsstarts in der Datei app.run extrahiert und gefiltert wurden, wonach sie in den Sitzungsspeicher gestellt wurden. Dies ist eindeutig nicht der beste Ansatz. Um das Problem zu lösen, musste der Code von dort entfernt werden. Es dauerte einen ganzen Tag, um eine einfache Aufgabe zu erledigen.
Schauen Sie sich nun die Bootstrapping-Regel (Style 02-05) im Styleguide an.
Platzieren Sie den Code, der zum Starten der Anwendung dient, in einer separaten Datei und platzieren Sie die Anwendungslogik nicht in dieser Datei. Logik sollte in Services und Komponenten platziert werden.
Millionen Beispiel
Wie Sie oben sehen können, kann das Vernachlässigen nur einer Regel zu Problemen führen. Aber wir werden wirklich schwerwiegende Konsequenzen haben, wenn wir nicht mehrere Empfehlungen gleichzeitig anhören.
Fallstudie. Unser Team erhielt die Aufgabe: Fügen Sie für Zahlungen für Wohnraum und kommunale Dienstleistungen die Möglichkeit hinzu, freiwillige Versicherungsbeträge in die Zahlung einzubeziehen. Im Frontend-Teil lief dies auf eine einfache Aufgabe hinaus: ein Kontrollkästchen auf dem Formular zu platzieren, dessen Einbeziehung die Versicherungskosten zum Zahlungsbetrag hinzufügen würde. Bei der Promsvyazbank haben wir eine ähnliche Aufgabe sehr schnell erledigt. Aber bei dem neuen Projekt ist alles schief gelaufen.
Aufgrund der Tatsache, dass der Code des Zahlungsmoduls äußerst erfolglos organisiert war, dauerte die Entscheidung Monate. Auf der Suche nach der am besten geeigneten Option haben wir diese Aufgabe mehrmals verschoben und erneut übernommen. Und die Bank hatte unterdessen Schwierigkeiten mit Zahlungen zugunsten von Wohnraum und kommunalen Dienstleistungen. Letztendlich haben wir uns natürlich mit dem Problem befasst. Aber ich habe mich gefragt, wie viel schlechter Code eine Organisation am Beispiel einer so einfachen Aufgabe kosten kann. Ich habe berechnet, wie viel Zeit alle Spezialisten für die Lösung des Problems aufgewendet haben. Bewaffnet mit Statistiken über Durchschnittsgehälter. Ich habe die damit verbundenen Verluste berechnet und aufgerundet. Als Ergebnis kam ich zu dem Schluss, dass wir mindestens 5 Millionen Rubel sparen würden, wenn wir einen anfänglich guten Code im Zahlungsmodul hätten.
Als ich John Papas Styleguide überprüfte, stellte ich fest, dass unser Modul mehrere Regeln für guten Code gleichzeitig verletzte. Nachdem ich den Grad des Einflusses jeder dieser Regeln geschätzt hatte, identifizierte ich drei, deren Verletzung vor allem unsere Arbeit verlangsamte:
- Eins-Regel - Ich habe 25% der verlorenen Zeit für Verstöße gegen diese Regel abgeschrieben.
- Einzelverantwortung - Abweichung von diesem Prinzip trug zum Gesamtverlust von 35% bei;
- LIFT - Verletzung dieser Gruppe von Ansätzen, ich denke, 40% von uns waren diejenigen, die am meisten langsamer wurden.
Regel von einem
Unsere Online-Bank unterstützte viele Zahlungen, von denen einige in ihrem Modell völlig unterschiedlich waren. Trotzdem haben die Programmierer versucht, ein „universelles“ Zahlungsformular zu erstellen, das mit allen Zahlungsoptionen funktioniert.
Auf dem Formular selbst wurden viele verschiedene Blöcke gebildet, die unter bestimmten Bedingungen gezeigt wurden und unter anderen nie gezeigt wurden. Gleichzeitig wurden sie von einer gemeinsamen Logik bedient, die ViewModel'i stark aufblähte.
Dies alles führte dazu, dass etwas, das an einer Stelle hinzugefügt wurde, an einer anderen Stelle unweigerlich abfiel. Zunächst stellte sich heraus, dass die Auswahl des Kontrollkästchens den Betrag nicht veränderte. Wir haben versucht, das Betragsfeld zu korrigieren. Bei allen anderen Zahlungsarten wurde es jedoch nicht mehr bearbeitet. Wir haben versucht, das Betragsfeld durch ein neues zu ersetzen. Die allgemeine Validierungslogik fiel jedoch aus: Das Kontrollkästchen funktioniert, aber die Zahlungsschaltfläche ist nicht verfügbar. In eine ähnliche Situation geraten?
Nun wollen wir sehen, was die Regel von einer Regel sagt.
Jedes einzelne Element, z. B. eine Komponente oder ein Dienst, sollte in einer separaten Datei abgelegt werden. Sie müssen sicherstellen, dass die Datei nicht wächst. Wenn die Anzahl der Codezeilen eine magische Zahl von 400 überschreitet, ist dies ein sicheres Zeichen dafür, dass es sich lohnt, die Komponente zu beschädigen.
Einzelverantwortung
Als wir mit dem Formular selbst fertig waren, stellte sich heraus, dass die Funktionen außerhalb des Formulars nicht mehr funktionierten. Beispielsweise wurde die Arbeit mit Zahlungsentwürfen beschädigt. In der Betriebsgeschichte traten Fehler auf. Dies geschah, weil neben dem Zahlungsformular selbst noch andere Komponenten an das Modell und den Zahlungscontroller des Formulars gebunden waren. Noch schlimmer war die Tatsache, dass ein Versuch, diese Funktionalität zu reparieren, uns zu einem defekten Zahlungsformular zurückführte.
Wir haben uns mit dem klassischen Fall der Verletzung der Einzelverantwortung befasst. Dieses Prinzip ist seit langem in der Gruppe der erfahrenen Programmierer des Gentleman enthalten. In seinem Styleguide wird ausdrücklich empfohlen, ihn bei der Entwicklung von Angular-Anwendungen zu verwenden.
Wenden Sie das Single Responsibility-Prinzip (SRP) an.
LIFT
Das Unbequemste, mit dem ich mich befassen musste, war das Navigieren im Projekt selbst. Die Logik war auf mehrere Dateien verteilt und zu einer unverständlichen Hierarchie von Vererbung und Delegierung zusammengefasst. Aus den Namen dieser Dateien folgte ihr Zweck überhaupt nicht. Dateien lagen in verschiedenen Ordnern. In einigen Ordnern, zum Beispiel Controllern, musste ich neben Dutzenden anderer Dateien ständig nach denjenigen suchen, die gerade benötigt werden. Die Anzahl der geöffneten Registerkarten in der Entwicklungsumgebung passte nicht auf den Computerbildschirm und in meinen Kopf. Während des Debuggens, als ich die N-te Komponente des Kontos erreichte, vergaß ich bereits, welchen Pfad und warum ich hierher gekommen bin. Von Zeit zu Zeit musste ein vollständiges Reverse Engineering mit eingeschaltetem Debugger durchgeführt werden, um herauszufinden, in welchem Projektordner sich die Datei mit einer bestimmten Funktionalität befand. Das akkumulierte Gefühl des Hasses auf den Code verwischte seine Augen und lenkte ihn von der Arbeit ab.
Der weise Styleguide kennt dieses Problem ebenfalls. Um dies zu lösen, wurde eine LIFT-Regelgruppe erstellt. LIFT steht für Locate, Identify, Flat und Try to be DRY. Nach den Grundsätzen von LIFT ist es notwendig, die Projektstruktur so zu organisieren, dass:
- Es war klar, wo neue Komponenten platziert und wo nach vorhandenen gesucht werden sollte (Suchen).
- Der Zweck der Komponente wurde durch den Namen der Datei (Identifizieren) deutlich.
- Es war einfach, in den Ordnern zu navigieren und die flachste Struktur für sie zu verwenden (flach).
- Versuchen Sie, Ihren Code nicht zu wiederholen, aber nicht auf Kosten anderer Regeln (Versuchen Sie, trocken zu sein).
Der LIFT-Ansatz wird durch zwei weitere Regeln ergänzt.
Allgemeine strukturelle Richtlinien bieten die Möglichkeit, für jede einzelne Komponente einen Ordner zu erstellen und alle mit dieser Komponente verbundenen Dateien darin zu gruppieren. Dies ist beispielsweise praktischer, wenn sich die Datei "payment-form.controller.js" nicht im Ordner "Controllers" befindet, sondern im Ordner "pay-form" zusammen mit "pay-form.html" und "payment-form.css".
Die Ordner-für-Feature-Struktur empfiehlt, separate Ordner mit den entsprechenden Namen für Features und Themenbereiche des Projekts zu erstellen. Nach dieser Regel sollte sich der oben erwähnte Zahlungsformularordner zusammen mit anderen Komponenten, die für die Arbeit mit Zahlungen erforderlich sind, im Zahlungsordner befinden.
Wenn die Autoren des Codes die LIFT-Regeln befolgen würden, würde die Struktur des Projekts folgendermaßen aussehen:
Stimmen Sie zu, diese Option zum Organisieren des Codes ist für den Leser viel bequemer. Und er würde unserem gesamten Team viel Zeit sparen.
Gute Programmierer gehen an die Bar
Ich hoffe, dass die obigen Beispiele überzeugend genug klangen, so dass der Leser, der zuvor nicht über den Programmierstil nachgedacht hatte, den Wunsch haben würde, in die Richtlinie zu schauen. Im Allgemeinen kommt gut gelesener und gepflegter Code nicht nur dem Projektbudget, sondern auch dem Programmierer selbst zugute. Lesbarer Code ist einfacher zu überprüfen. Wenn Sie die Hilfe von Kollegen benötigen, werden diese den lesbaren Code schnell verstehen. Wenn Sie nur ein Anfänger sind, ist die Lesbarkeit des Codes das erste, woran Sie arbeiten müssen. Selbst wenn Sie superkorrekten und perfekt optimierten Code schreiben, der jedoch absolut unlesbar und nicht unterstützt ist, werden Sie im Team sicherlich respektiert, aber Sie werden nach der Arbeit nicht in die Bar eingeladen.
Wenn dieser Text Sie dazu gebracht hat, über etwas nachzudenken oder an etwas schmerzlich Vertrautes zu erinnern, werde ich es gerne in den Kommentaren zum Beitrag sehen.