Es gibt 10 häufige Fehler, die von Backend-Entwicklern gemacht werden. Verstehe sie und lerne, sie zu verhindern. Finden Sie heraus, was zu tun ist, wenn sie bereits passiert sind.
A QUICK SUMMARY – FOR THE BUSY ONES
TABLE OF CONTENTS
Dieser Artikel richtet sich an alle, die jede Art von Backend-Code schreiben, egal wie erfahren sie sind, ob sie nun vollständig Backend oder Fullstack sind oder hauptsächlich Frontend und gelegentlich Backend schreiben, und unabhängig davon, welche Plattform sie verwenden (Node.js, PHP, Python, Ruby, Java, .NET, Golang usw.).
Hier erfährst du mehr über die Die 10 häufigsten Fehler von Backend-Entwicklern und Liste von 16 anderen Fehlern. Nachdem Sie diesen Artikel gelesen haben, sollten Sie wissen, wie Sie einen bestimmten Fehler, seine Folgen und wie Sie damit umgehen können, falls er bereits passiert ist.
Ich habe diesen Backend-Entwicklungsfehler als den ersten aufgeführt, weil er am häufigsten vorkommt. Wenn er nicht frühzeitig behoben wird, ist er später schwer zu behandeln, da manchmal ein großer Teil des Projekts neu geschrieben werden muss. Zu viele technische Schulden bedeuten im Allgemeinen, schlechte Praktiken wie das Brechen von Problemen anzuwenden FEST UND TROCKEN Regeln, sehr lange Funktionen/Methoden, eine große Anzahl von Einrückungsebenen, fehlende Tests (im nächsten Punkt beschrieben), fehlende Dokumentation, schlechte Variablenbenennung, schlechte Benennung von Commit-Nachrichten, zu wenig Wert auf Leistung usw. Es könnte auch eine schlechte Architektur bedeuten, die normalerweise noch schlimmer ist. Wenn der Code hässlich ist, können Sie ihn im Grunde Microservice für Microservice oder Datei für Datei umgestalten, aber wenn das gesamte System schlecht konzipiert ist, ist es viel schwieriger, ihn zu reparieren.
Over-Engineering entsteht, wenn Backend-Entwickler ein viel zu ausgeklügeltes Muster zu einem bestimmten Zeitpunkt verwenden, an dem eine viel einfachere Lösung problemlos funktionieren würde — es macht das kaputt KISS oder YAGNI Regel. Überoptimierung bedeutet, sich zu sehr um die Leistung an einem Ort zu kümmern, an dem es nicht wirklich darauf ankommt, z. B. eine bestimmte Prozedur von 0,1 s auf 0,01 s zu verkürzen, während eine andere Prozedur, die einen Engpass darstellt, etwa 15 s dauert.
Langfristig führt jedes der Teilprobleme zu verschwendete Entwicklungszeit da die Entwicklung jeder neuen Funktion im Allgemeinen immer schwieriger und irgendwann fast unmöglich wird. Im Extremfall nimmt die Zeit für die Implementierung der nächsten Funktionen exponentiell zu, da alle möglichen Pfade getestet oder alle vorhandenen Bedingungen im Produktionscode aktualisiert werden müssen, wobei die alten Funktionen mit den neuen kombiniert werden.
Sowohl technische Schulden als auch Over-Engineering machen die Code ist zu schwer zu verwalten. Überoptimierung kann auch dazu führen, wenn sie mit Over-Engineering zusammenhängt, was oft der Fall ist.
Bei der Entwicklung einer bestimmten Funktion sollten Backend-Entwickler die kommenden Funktionen berücksichtigen, um zu wissen, ob es sich lohnt, sie zu überarbeiten oder zu optimieren. Wir sollten auch Folgendes berücksichtigen funktionale Lebensdauer (wie lange wird diese Funktion in der Produktion verwendet) und ihre technologische Lebensdauer (wie lange kann diese Funktion mit den aktuellen Technologien verwendet werden), um zu wissen, wie hoch die technischen Schulden zu einem bestimmten Zeitpunkt sind. Es ist wichtig, jede Funktion und jeden Bugfix im Code zu überprüfen (ein weiterer Punkt).
Wenn wir feststellen, dass eine bestimmte technische Schuld oder eine Überkonstruktion die Wartung zu schwierig macht, sollten wir sie umgestalten, um den gute Praktiken und sei einfach genug. Überoptimierung, wenn sie nicht mit Over-Engineering einhergeht, sollte jedoch nicht behandelt werden, da es gut ist, dass unsere Codeausführung schneller ist. Wir haben bereits Zeit mit übermäßiger Optimierung verschwendet, was ein Problem ist, aber wir können die Zeit nicht zurückbekommen.
<span class="colorbox1" fs-test-element="box1"><p>Lesen Sie auch: Die Priorisierung von Technologieschulden kann schwierig sein. Erfahren Sie, wie ein Entwicklungsteam mit technischen Schulden umgegangen ist, indem es Verbesserungsmöglichkeiten identifiziert hat, die das Geschäft unterstützen und nicht nur den Code bereinigen.</p></span>
Fehlende Tests bedeuten, dass ein bestimmtes Szenario nicht durch Tests abgedeckt wird oder dass es für eine bestimmte Funktion überhaupt keine Tests gibt. Wenn wir nicht auf jeder Ebene der Pyramide testen, verpassen wir Tests auf mindestens einer Ebene der Pyramide.
Dies führt zu Produktionscode, der für die Backend-Entwickler schwer zu verwalten ist, da sie Angst haben, etwas zu beschädigen, was die Anzahl der Fehler erhöht. Denken wir jedoch daran, dass ein vollständiges Testen unmöglich ist.
Es sollte helfen, alle Tests auf jeder Ebene zusammen mit einer neuen Funktion und Regressionstests zusammen mit einem Bugfix zu schreiben. Die Tests sollten in den Tagesablauf integriert werden. Dies kann von jedem Backend-Entwickler individuell durchgesetzt werden, indem TDD (testgetriebene Entwicklung) und statische Codeanalyse sowie Überprüfung der Codeabdeckung.
Ein weiterer, aber nicht ausschließlicher Ansatz zur Durchsetzung von Schreibtests ist mit Zusammenspiel — den Code so schnell wie möglich zu pushen und ihn von einem anderen Backend-Entwickler zu überprüfen oder manchmal auch paarweise zu programmieren. Manchmal widersetzt sich jemand dem Schreiben von Tests. Ein Gegner kann entweder ein Junior-Backend-Entwickler sein, der keine Erfahrung im Schreiben von Tests hat, oder ein Product Owner, der die Dinge so schnell wie möglich implementiert haben möchte. Daher ist es wichtig, ihnen zu erklären, warum die Tests so wichtig sind. Die Hauptgründe sind: eine höhere Arbeitsleistung auf lange Sicht, manchmal sogar eine höhere Arbeitsleistung auf kurze Sicht, wenn eine bestimmte Funktion kompliziert genug ist, weniger Bugs und schließlich die Entwicklung einer besseren Architektur. Für eine detailliertere Erklärung kannst du versuchen, in Google, Quora und YouTube nach „Warum sollte ich Tests schreiben“ zu suchen.
Im Allgemeinen sollten Sie die Dinge aus dem Unterabschnitt „Prävention“ beheben, aber Sie sollten analysieren, welche Funktionen und Szenarien am wichtigsten sind, um sie in der ersten Reihenfolge durch Tests abzudecken.
Bei fehlender Codeüberprüfung wird Code im Allgemeinen in den Standard-Branch verschoben, ohne dass mindestens ein Backend-Entwickler außer dem Code-Autor ihn Zeile für Zeile überprüft. Eine fehlende statische Codeanalyse bedeutet, dass Code in den Standardzweig verschoben wird, ohne ihn mit einem Tool wie ESLint für JavaScript oder TSLint für TypeScript zu analysieren.
Mögliche Folgen sind schlechte Praktiken oder ein inkonsistenter Codestil, der die Wartung des Codes erschwert, Sicherheitslücken und die Behandlung verpasster Randfälle.
Um dies zu verhindern, überprüfe jeden PR/MR vor dem Zusammenführen (und natürlich niemals direkt zu einem der geschützten Branches, die in GitHub oder GitLab erzwungen werden könnten) und verwende Continuous Integration, um nach jedem Commit eine statische Codeanalyse durchzuführen.
Um diesen Backend-Entwicklungsfehler zu beheben, sollten wir Maßnahmen wie das Starten von Code-Reviews, das Konfigurieren der statischen Codeanalyse und das Überprüfen von Code ergreifen, der sich bereits im Standard-Branch befindet, aber noch nicht überprüft wurde.
Manchmal kann es bei der Überprüfung der einzelnen Codes zu Problemen kommen, daher empfehle ich die folgenden Möglichkeiten, sie zu beheben:
Im Allgemeinen sollten Backend-Entwickler dieselbe Technologie (Programmiersprache oder Framework oder Bibliothek oder DBMS oder eine externe API) und dasselbe Muster verwenden, um ein bestimmtes Problem zu lösen. Beispiele sind JavaScript für die Programmierung auf hoher Ebene, Moment.js für Datums-/Uhrzeitoperationen, MongoDB für die Speicherung von Dokumenten, Factory-Funktion zum Erstellen eines Objekts.
Natürlich ist es in Ordnung, Python statt JavaScript, Day.js statt Moment.js, CouchDB statt MongoDB oder eine Klasse statt einer Factory-Funktion zu verwenden, aber Sie sollten entscheiden, welche Alternative Sie für das gesamte Projekt verwenden. Eine temporäre Ausnahme kann das Experimentieren mit einer neuen Technologie an einigen Stellen sein, aber später solltest du diese Technologie entweder für das gesamte Projekt verwenden oder ihre Einführung rückgängig machen.
Haben inkonsistente Technologien oder Herangehensweisen machen die Wartung schwieriger Da es viel mehr Wissen erfordert, besteht ein höheres Risiko von Fehlern/Sicherheitslücken aufgrund einer höheren Anzahl von Abhängigkeiten und einer langsameren Installation, da mehr Abhängigkeiten installiert werden müssen.
Verwendung derselben Technologien und Muster für ein bestimmtes Problem und Codeüberprüfung (der vorherige Punkt).
Wir sollten entscheiden, welche Technologie oder welcher Ansatz für unser Projekt am besten geeignet ist, und den verbleibenden Code so umgestalten, dass er immer dieselbe Technologie oder denselben Ansatz verwendet.
<span class="colorbox1" fs-test-element="box1"><p>Lesen Sie auch: Zu viele technische Schulden können eine tickende Zeitbombe sein. Entdecken Sie 10 praktische Tipps, wie Sie eine technische Insolvenz vermeiden können, solange Sie noch etwas bewegen können.</p></span>
Die Produktionsdatenbank wird manchmal ganz oder teilweise gelöscht oder enthält aufgrund eines Fehlers oder manueller Operationen ungültige Daten. Produktionsdaten sind in der Regel noch wertvoller als unser Code, da der Code das Ergebnis der Arbeit von Dutzenden von Backend-Entwicklern sein kann, während die Produktionsdaten das Werk von Tausenden oder sogar Millionen von Anwendungsbenutzern sein können. Darüber hinaus kann unser Code durch eine andere Anwendung oder manchmal durch eine Tabelle ersetzt werden, während Die Produktionsdatenbank kann möglicherweise nicht wiederhergestellt werden ohne ein Backup zu haben.
Unsere Systembenutzer könnten das Ergebnis ihrer Arbeit verlieren. Im Gegensatz zu anderen Punkten sind wir wahrscheinlich verpflichtet, Schadensersatz zu zahlen, falls Produktionsdaten verloren gehen.
Konfiguration des automatischen Backups, z. B. bietet MongoDB Atlas standardmäßig regelmäßige automatische Backups an, aber es ist gut, dies zu überprüfen.
Falls nicht zuvor konfiguriert, konfigurieren Sie das automatische Backup so schnell wie möglich. Wenn die Datenbank bereits ohne Backup gelöscht wurde, ist es zu spät, aber wenn wir Glück haben, können wir einen Teil der Produktionsdaten aus den Protokollen abrufen (ein weiterer Punkt) oder unsere Teamkollegen fragen, ob einer von ihnen ein manuelles Backup durchgeführt hat.
Die Produktion sollte so zugänglich wie möglich sein. Wenn also ein Microservice für einige Stunden ausfällt, kann dies zu großen Problemen führen. Deshalb müssen wir alle Microservices überwachen und falls einer ausfällt, sollten wir ihn so schnell wie möglich wieder hochfahren. Das ist ein DevOps-Fehler, aber neben der DevOps-Arbeit müssen Backend-Entwickler für jeden Microservice einen Status-Endpunkt implementieren. Wenn ein Microservice ausfällt, sind wahrscheinlich einige Backend-Entwicklungsarbeiten erforderlich, um das Problem zu beheben.
Größere Fehler, die darauf zurückzuführen sind, dass ein Microservice ausgefallen ist oder das gesamte System ausgefallen ist, wenn die wichtigsten Microservices ausgefallen sind.
Wir sollten einen Monitor konfigurieren für jeden Produktions-Microservice als eine der ersten Aktionen, die nach der Erstellung der Produktionsumgebung ausgeführt werden.
Wir sollten die fehlenden Monitore konfigurieren und alle toten (ausgefallenen) Microservices wiederbeleben.
Das Datenmodell ist ein wichtiger Bestandteil der Systemarchitektur. Wenn es also schlecht konzipiert ist, kann es zu einigen der später beschriebenen Probleme führen.
Dies kann zu ungültigen Produktionsdaten, Daten, die schwer zu analysieren oder zu verwalten sind, und zu sehr langsamen Datenabfragen führen.
Wir sollten das Datenmodell sorgfältig entwerfen und es mit dem gesamten Backend-Team besprechen, wenn es relativ klein ist (bis zu 10 Backend-Teammitglieder). Bei einem größeren Team sollten wir das Modell mit dem Subteam besprechen, das für die Logik dieses Modells verantwortlich ist, und zusätzlich mit einigen allgemeinen Datenexperten oder spezialisierten Datenexperten wie einem Key-Value-DBMS-Experten.
Wenn ein fehlerhaftes Datenmodell noch nicht in der Produktion eingesetzt wird, können wir das Datenmodell einfach aktualisieren und die ungültigen Daten entfernen, die in niedrigeren Umgebungen erstellt wurden. Wenn ein fehlerhaftes Datenmodell bereits in der Produktion eingesetzt wird, müssen wir nicht nur das Datenmodell aktualisieren, sondern auch eine Migration schreiben, um die ungültigen Daten zu korrigieren.
Leider kann es in manchen Situationen unmöglich sein, ungültige Produktionsdaten vollständig zu korrigieren. Es passiert, wenn wir einige mehrdeutige Daten speichern, z. B. einen Städtenamen anstelle der Stadt-ID, da es viele Städte mit demselben Namen geben kann.
Dies ist ein Fehler, der hauptsächlich von jüngeren Backend-Entwicklern gemacht wird, aber manchmal können sogar Senioren diesen Fehler machen. Eine SQL-Injektion ist eine gefährliche Möglichkeit, dass der Benutzer eine Abfrage eingibt, die dann aufgrund einer Zeichenkettenverkettung in der Datenbank ausgeführt wird. Wie dem auch sei, es ist ein allgemeiner Begriff, da es sich um eine Injektion einer anderen Abfragesprache wie AQL (ArangoDB Query Language), GraphQL usw. handeln kann. Ein ähnliches Problem kann auftreten, wenn Sie die Funktion eval verwenden oder einen Betriebssystembefehl ausführen.
Ein Benutzer (Hacker), der Daten erhält, die er eigentlich nicht lesen kann, oder was noch schlimmer ist, Daten aktualisiert, einfügt oder löscht.
Um diesen Backend-Entwicklungsfehler zu verhindern, sollten wir Maßnahmen ergreifen wie Übergabe von Parametern an jede Abfrage anstatt sie zu verketten, eine sorgfältige Codeüberprüfung durchzuführen (ein früherer Punkt), dabei so wenig Zeichenkettenverkettungen wie möglich zu verwenden, sicherzustellen, dass jeder Stringteil validiert ist, damit keine gefährliche Abfrage entsteht. Dabei werden viele Datenbanken und viele Datenbankbenutzer verwendet, sodass selbst wenn ein Benutzer etwas ausnutzt, seine Macht begrenzt ist, und automatische Produktionsdatenbank-Backups (ein früherer Punkt), um die von einem Hacker gelöschten oder defekten Daten wiederherstellen zu können.
Umsetzung der Präventionsmaßnahmen und schnellstmöglicher Einsatz in der Produktion.
Die Protokollierung ist unerlässlich, um Probleme zu melden und Statistiken über die Systemnutzung zu sammeln.
Es ist schwieriger oder manchmal sogar unmöglich, bereits bereitgestellte Fehler (für Entwickler, Stage oder Produktion) zu beheben.
Wir sollten alle Serverfehler für die Produktionsumgebung protokollieren, einschließlich Stack-Trace, Zeitstempel, Anforderungstext/Pfad/Header und möglicherweise des dekodierten Benutzernamens und der Client-IP-Adresse. Außerdem ist es für die Entwicklungsumgebung gut protokolliere jede Anfrage mit einer vollständigen Antwort. Wir müssen auch die Anmeldeinformationen redigieren, bevor wir sie protokollieren, um zu verhindern, dass sie durchsickern. Manchmal benötigen wir möglicherweise eine teilweise Protokollierung, z. B. wenn wir nur ein paar Elemente des Arrays behalten und danach etwas wie „<20 other elements>“, um die Festplattenlimits einzuhalten.
Es ist auch gut, sehr grundlegende Informationen über jede Produktionsanfrage wie Zeitstempel, Anforderungspfad, dekodierten Benutzernamen und Client-IP zu protokollieren, um Statistiken zu sammeln, die zeigen, wie oft ein bestimmter Endpunkt verwendet wird und zu welcher Uhrzeit/an welchem Wochentag der Verkehr am höchsten ist.
Implementierung der Protokollierung so schnell wie möglich.
Jede Client-Fehleranfrage (ein Statuscode, der mit 4 beginnt) sollte Details enthalten, damit Benutzer (normalerweise Frontend-Entwickler oder andere Webentwickler) sind in der Lage, die übergebenen Parameter einfach zu korrigieren. Serverfehleranfragen (ein Statuscode, der mit 5 beginnt) sollten jedoch keine Details preisgeben, weil sie könnte möglicherweise verwendet werden, um das System auszunutzen.
Wenn ein Stacktrace verfügbar gemacht wird, besteht außerdem das Risiko, dass er einige Anmeldeinformationen enthält. Daher sollten wir bei einem Serverfehler eine generische Meldung wie „Interner Serverfehler“ zurückgeben und die Fehlerdetails protokollieren (ein Teil des vorherigen Punktes).
Fehlende Client-Fehlerdetails erschweren die Verwendung des angegebenen Endpunkts erheblich, und offengelegte Serverfehlerdetails können zur Ausnutzung des Systems führen.
Implementierung jedes Endpunkts gemäß den in diesem Punkt definierten Regeln und eine angemessene Codeüberprüfung.
Endpunkttests decken verschiedene Szenarien ab, einschließlich Client-Fehlern (im Allgemeinen können wir Serverfehler nicht vorhersagen).
Beide Situationen erkennen und beheben.
Neben diesen 10 Fehlern gibt es noch einige andere, an die es sich zu erinnern und sie zu vermeiden gilt (obwohl sie weniger wichtig sind als die zuvor beschriebenen):
Egal wie umfangreich deine Backend-Erfahrung ist, ich hoffe, du hast einige Fehler kennengelernt, die es wert sind, vermieden zu werden, oder einfach mehr Details wie mögliche Konsequenzen oder Möglichkeiten, einen bestimmten Fehler zu verhindern oder zu behandeln, kennengelernt.
Wenn Ihnen das Lesen Spaß gemacht hat, können Sie diesen Artikel gerne mit Ihren Freunden und Netzwerken in den sozialen Medien (Facebook, Twitter, Linkedin) teilen.
Our promise
Every year, Brainhub helps 750,000+ founders, leaders and software engineers make smart tech decisions. We earn that trust by openly sharing our insights based on practical software engineering experience.
Authors
Full-Stack-Softwareingenieur mit 8 Jahren Berufserfahrung.
Enthusiast für Softwareentwicklung mit 9 Jahren Berufserfahrung in dieser Branche.
Full-Stack-Softwareingenieur mit 8 Jahren Berufserfahrung.
Enthusiast für Softwareentwicklung mit 9 Jahren Berufserfahrung in dieser Branche.
Read next
Popular this month
previous article in this collection
It's the first one.
