Alle diese Punkte können auf die mobile Entwicklung, das Web-Frontend und das Backend angewendet werden. Ich habe diese Praktiken von verschiedenen Teams und anhand der Probleme, mit denen ich in den letzten 6 Jahren konfrontiert war, gesammelt. Diese Vorgehensweisen können besonders hilfreich sein, wenn Sie ein Projekt von Grund auf neu erstellen. Einige davon passen möglicherweise perfekt zu Ihnen, andere möglicherweise nicht. Wenn Sie eigene Ansätze und unterschiedliche Erfahrungen haben, würde ich mich freuen, wenn Sie diese hier teilen. Übrigens, wenn Sie ein mittlerer oder junger Entwickler sind, der eine Beförderung anstrebt, kann die Implementierung dieser Praktiken in Ihrem Team wirklich hilfreich sein. Lass uns gehen!

1. Backend-Antworten verspotten, bis sie fertig sind

Wenn in einem Standard-Softwareentwicklungsprozess eine neue Funktionsanfrage vom Unternehmen eingeht, wird diese auf mehrere Teams verteilt: Front-End, Back-End und Entwicklung mobiler Apps.

Anschließend führt jedes Team die Planung und Aufgabenzerlegung durch. Was aber, wenn das Back-End-Team deutlich mehr Zeit für die Entwicklung seines Teils benötigt? Was wäre, wenn sie Endpunkte nur einmal pro Woche bereitstellen könnten?

Das Backend wird zum Flaschenhals.

Die mobilen und Front-End-Entwicklungsteams arbeiten am Ende so: „Oh, das Back-End hat das bereits implementiert. Lassen Sie mich diese Aufgabe übernehmen.“ Dann machen sie eine Pause, wechseln ihren Kontext zu einem anderen Feature und der Zyklus geht weiter. Dies führt zu Ermüdung, verminderter Geschwindigkeit und verminderter Qualität.

Lösung: Vereinbaren Sie einen Vertrag mit dem Back-End-Team und verspotten Sie alle Anfragen.

1. Koordinieren Sie die Endpunkte und Entitäten mit dem Back-End-Team.

2A. Implementieren Sie die Backend-API mit Stub-Antworten. Die Faker-Bibliothek kann bei der Generierung von Beispieldaten helfen.

2B. Oder implementieren Sie Stubs im Frontend. Dies kann ein Objekt mit Daten direkt im Code sein. In Node.js können Sie dies beispielsweise mithilfe dynamischer Importe effizient implementieren und eine Erhöhung der Bundle-Größe vermeiden:

 getUser() { return import('../../assets/mocks/users') .then(data => data.userById) .then(deserializeUser); };

Dies kann auch ein simulierter HTTP-Dienst sein, der JSON-Dateien von Assets abruft, anstatt echte Anfragen zu stellen.

3. Verstecken Sie das Feature hinter einem Feature-Flag.

   
   

4. Wenn das Backend bereit ist, wechseln Sie zur eigentlichen API, wenn Sie den Front-End-Stub-Ansatz verwendet haben, und überprüfen Sie, ob alles wie erwartet funktioniert. Und schalten Sie diese Funktion ein.

2.Feature-Flag

Wie Sie wahrscheinlich bemerkt haben, habe ich im vorherigen Abschnitt Feature-Flags erwähnt. Kurz gesagt: Feature-Flags, auch Feature-Toggles genannt, ermöglichen es Entwicklern, Features in einer Live-Umgebung ein- oder auszuschalten. Es gibt auch einige Fälle, in denen sie nützlich sind: die schrittweise Einführung neuer Funktionen, die Durchführung von A/B-Tests, die Aktivierung von Betafunktionen und die Implementierung von Hotfixes.

Wir verwenden Gitlab zum Speichern von Feature-Flags. Es handelt sich um ein dediziertes Repository, das sowohl von Backend- als auch von Frontend-Projekten genutzt wird. Die gute Nachricht ist, dass es über eine benutzerfreundliche Benutzeroberfläche verfügt, sodass Produktmanager Funktionen selbst verwalten können. Bisher haben wir Feature-Flags für jedes Projekt-Repository separat verwendet. Dieser Ansatz bot jedoch nicht die Möglichkeit, Funktionen für das gesamte Produkt auf einmal zu deaktivieren. Also verschieben wir alles in das einzige Repository.

Im Code sieht es ganz einfach aus:

1. Im Projekt rufen wir alle aktiven Feature-Flags ab. Da Gitlab im Grunde auf Unleash (Feature-Toggle-Dienst) basiert, verwenden wir dessen offiziellen Client.
2. Und dann fügen Sie einfach if features.YOUR_FEATURE in den Code ein, der ausgeblendet werden soll.
3. Sie können die Anwendungsfälle erweitern, indem Sie im Feature-Flag unterschiedliche Werte hinzufügen. Zum Beispiel durch Addition des Farbwerts oder des Rabattwerts.

3.Überwachung von Fehlern zur Nachverfolgung von Problemen in einer Produktionsumgebung

Als unser Produkt von der MVP-Phase in eine Produktionsanwendung überging, hatten wir Angst, dass Benutzer Fehler erhalten würden, die wir nicht reproduzieren konnten und die uns möglicherweise nicht einmal bewusst waren. Nachdem wir uns über Tools zur Fehlerverfolgung informiert hatten, entschieden wir uns für Sentry. Die Erfahrung war positiv. Und nun gehen wir einige wichtige Nuancen durch.

Nutzlose Fehler

Unter der Haube wird jede nicht erfasste Ausnahme verfolgt. Wenn die Anwendung und die Anzahl der Benutzer wachsen, kann die Anzahl der Fehler so überwältigend werden, dass es fast unmöglich wird, etwas wirklich Wichtiges zu bemerken. Sentry kann sich in einen Müllcontainer verwandeln, wenn Sie nicht die unnötigen Dinge herausfiltern. Beispielsweise sind Ereignisse wie abgebrochene Anfragen, Verbindungsfehler und Fehler von verbundenen Skripten völlig nutzlos und führen nur dazu, dass Ihre geschäftlichen E-Mails mit Benachrichtigungen überschwemmt werden. Als Lösung können Sie der Konfiguration Filter hinzufügen. Definieren Sie dazu einfach einen beforeSend Rückruf und fügen Sie ihn in Ihre sentryPackage.init ein. In diesem Rückruf können Sie jeden abgefangenen Fehler analysieren und ihn dann verwerfen (indem Sie null zurückgeben), wenn er nutzlos ist. Hier ist ein Beispiel für einen Filter, der unnötige Fehler ausschließt:

 function beforeSend(event, hint) { const error = hint.originalException; const externalScripts = [ 'gtm.js', // Google Tag Manager 'watch.js', // X Analytics ].join('|'); const errorsToIgnore = [ AxiosError.ERR_NETWORK, AxiosError.ECONNABORTED, AxiosError.ETIMEDOUT ]; if (axios.isCancel(error) || errorsToIgnore.includes(error.code) || error.stack?.match(externalScripts)) { return null; } return event; }

Fügen Sie mehr Daten für ein besseres Debugging hinzu

Standardmäßig nimmt Sentry den Inhalt der Anfrage und Antwort möglicherweise nicht in den Fehlerbericht auf. Ohne diese Informationen ist ein ordnungsgemäßes Debuggen nicht möglich. Glücklicherweise können wir diese Informationen in den beforeSend Handler einbinden.

 function beforeSend(event, hint) { const error = hint.originalException; if (error.isAxiosError) { const url = error.request?.responseURL; const response = error.response?.data; const request = error.config?.data; event.extra = { ...(event.extra || {}), url, response, request }; } return event; }

Sensible Informationen filtern

Daten wie Passwörter, E-Mail-Adressen und Schlüssel sollten nicht im Fehlerinhalt enthalten sein. Sentry verfügt über einen integrierten Mechanismus zum Ausblenden dieser Art von Informationen. Sie können es in den Sicherheitseinstellungen konfigurieren. Darüber hinaus können Sie in beforeSend auch etwas aus dem Ereignisobjekt entfernen

Standalone-Lösung

Wenn die Art Ihres Unternehmens es nicht zulässt, diese Art von Daten auf einem anderen Server zu speichern, bietet Sentry die Möglichkeit, sie auf Ihren eigenen Servern zu verwenden.

4. Nachverfolgung

Stellen Sie sich eine Situation vor, in der Sie einen Fehler in Sentry erfolgreich erfassen, die Informationen in der Beschreibung jedoch unzureichend sind. Sie greifen auf Protokolle zurück, aber wie können Sie den spezifischen Fehler unter Tausenden von Anfragen und noch mehr Protokollzeilen pro Sekunde identifizieren? Wie können Sie die richtigen unterscheiden, die Anfragekette aufbauen und den genauen Fehler lokalisieren, insbesondere wenn Ihr Unternehmen über mehrere Teams verfügt und mit anderen Diensten integriert ist? Hier kommt die Rückverfolgung ins Spiel.

1. Die Ablaufverfolgung bietet ein vollständiges Diagramm der Aufrufe und identifiziert die genaue Methode, die fehlgeschlagen ist, selbst wenn die asynchrone Kommunikation von einem Nachrichtenbroker durchgeführt wird.
2. Dadurch können Sie bei der Integration mit verschiedenen Teams leicht feststellen, auf welcher Seite der Fehler aufgetreten ist.
3. Die Ablaufverfolgung ist auch für das Leistungsdebuggen nützlich. So kann beispielsweise geklärt werden, ob das Rendern länger dauert oder ob eine Methode in einem Microservice nicht ausreichend optimiert ist.

In unserer konkreten Implementierung haben wir Jaeger verwendet, das auf der OpenTracing-API basiert.

Kurz gesagt, jede Anfrage und alle ihre Methodenaufrufe werden mit einer eindeutigen Bezeichnung versehen. Jedes Label hat einen Verweis auf sein übergeordnetes Label und einige Metadaten. Die Struktur dieser Zahl hängt von der Implementierung ab, aber was OpenTracing betrifft, können Sie auf der offiziellen Repository-Seite nachlesen, wie es funktioniert, und sich mit Begriffen wie Span, Referenz, Kind, Eltern usw. vertraut machen. Im wirklichen Leben wird die Rückverfolgung glücklicherweise selten eingesetzt. Bei diesen seltenen Unfällen kann es Ihnen jedoch Zeit sparen.

5.Leistungsoptimierung

Als wir das MVP der Fintech-App implementierten, hatten wir eine recht komplizierte Form. Damals war ich noch jung und unerfahren. Und irgendwann stellten wir fest, dass unser Projekt langsamer wurde. Wir mussten zusätzliche Stunden damit verbringen, den Grund herauszufinden. Wir hatten viele unnötige Neu-Renderings, weil wir grundlegende Regeln für Requisiten in React ignorierten. Ich wollte alles tun, um solche Situationen in Zukunft zu vermeiden.

Also habe ich den Projekt-Linters wie diesen und eine zusätzliche Startkonfiguration zu package.json hinzugefügt, um why-did-you-render auszuführen. Kurz gesagt: Dieses Plugin gibt eine Warnung aus, wenn etwas unnötigerweise neu gerendert wird, und schlägt vor, wie man dies vermeiden kann. Außerdem haben wir die Ausführung von Lighthouse im Headless -Modus integriert. Manche Leute sagen, dass vorzeitige Optimierungen schlecht sind, aber für mich gilt der Grundsatz: Mach es von Anfang an richtig .

6.Definierter Codestil für alle Teamprojekte

Sie haben wahrscheinlich schon von der Theorie der zerbrochenen Fenster gehört. Wenn in einem Gebäude ein einziges Fenster kaputt ist und niemand es ersetzt, wird es in diesem Gebäude irgendwann kein einziges intaktes Fenster mehr geben.

Je weniger Regeln und Kontrollen es in einem Projekt gibt, desto größer ist die Versuchung, Code von geringer Qualität oder in einem völlig anderen Stil zu schreiben. Inkonsistenter Code erhöht die Zeit, die zum Verstehen benötigt wird, während klarer, vertrauter und prägnanter Code ein schnelles Lesen ermöglicht. In einem unserer Teams haben wir den Codierungsstil an einer Stelle beschrieben. Als guter Ausgangspunkt können Sie den Prettier- oder Airbnb-Codestil verwenden.

7.Regressionstests

Es wurde bereits eine beträchtliche Menge an Literatur über die verschiedenen Arten von Tests, Ansätze und wie man sie richtig schreibt, geschrieben. Erwähnenswert ist hier nur, dass keine Produktionsanwendung ohne Regressionstests überleben kann. Aus diesem Grund haben wir alle unsere Anstrengungen darauf konzentriert, ein umfassendes End-to-End-Test-Framework zu erstellen und darauf basierend Tests zu schreiben, die mit BDD-Szenarien und User Stories verknüpft sind. Wir haben das Page Object-Muster zum Organisieren unseres Codes und das Playwright-Framework für die Interaktion mit dem Browser verwendet. Um verschiedene Browser, einschließlich Safari, zu testen, können Sie eine Lösung namens Moon verwenden. Es kann auf einem Ihrer Server bereitgestellt werden.

Abschluss

Vielen Dank, dass Sie sich die Zeit genommen haben, diesen Artikel zu lesen! Abschließend beleuchtet dieser Artikel wichtige Software-Engineering-Praktiken, die Entwicklungsprozesse und Codequalität verbessern. Durch den Einsatz von Techniken wie Back-End-Response-Mocking, Feature-Flags, Fehlerüberwachung, Leistungsoptimierung, Codestilstandards, Regressionstests und Tracing können Sie effizientere und zuverlässigere Software erstellen. Lassen Sie uns unsere Software weiter verbessern und in Kontakt bleiben! :) :)

Das Leitbild für diesen Artikel wurde vomAI Image Generator von HackerNoon über die Eingabeaufforderung „speed“ generiert.