Web-Entwicklung: Die 10 Coding Antipatterns, die Sie vermeiden müssen

Das Entwerfen der Architektur einer Website oder einer Anwendung oder das Einrichten eines effektiven Arbeitsablaufs für die Kodierung lassen uns häufig wiederkehrende Probleme behandeln. Wir müssen diese Softwaredesignprobleme nicht unbedingt von Grund auf lösen, da Lösungen auf der Architekturebene genauso wie Code-Snippets auf der Mikroebene wiederverwendet werden können .

Entwurfsmuster sind in der Regel wiederverwendbare Lösungen für bestimmte Szenarien, die zur Lösung häufig auftretender Probleme nützlich sein können und uns enorm dabei helfen können, unseren Code zu optimieren.

Design-Patterns sind zwar großartige Mittel, um unseren Entwicklungsprozess durch die Verwendung gut getesteter Formeln zu verbessern, manchmal können wir aber auch falsch damit umgehen. Diese werden als Antipattern bezeichnet.

Was sind Antipattern?

Der Begriff "Antipattern" wurde 1998 in einem Buch namens AntiPatterns geprägt. Er bezieht sich auf wiederverwertete Lösungen, die zunächst nützlich erscheinen, später aber mehr Schaden als Nutzen anrichten.

Dies kann aus verschiedenen Gründen geschehen, zum Beispiel wenn wir die Muster nicht im richtigen Kontext, Setting oder Zeit verwenden (Lösungen, die in der Vergangenheit wirksam waren, funktionieren möglicherweise nicht immer in der Gegenwart) oder in anderen Fällen das gesamte Paradigma war einfach von Anfang an schlecht.

Antimuster werden häufig auch als Fehlermuster bezeichnet . Die gute Nachricht ist, dass es möglich ist, sie zu erkennen und zu vermeiden .

In diesem Beitrag werden wir uns 10 gängige codierende Antipattern in der Webentwicklung ansehen, die uns dazu verleiten könnten, zu denken, dass wir gut optimierten Code haben. (Beachten Sie, dass die in diesem Beitrag aufgelisteten Antipattern nicht unbedingt dieselben sind wie in dem oben genannten Buch.)

1. Vorzeitige Optimierung

Gutes Timing ist ein entscheidender Faktor bei der Code-Optimierung. Wir können das Antipattern der "vorzeitigen Optimierung" leicht reproduzieren, wenn wir auf kleine Effizienzen achten und diese zu früh im Entwicklungsprozess optimieren, bevor wir genau wissen, was wir machen wollen.

Nach Donald Knuths berühmtem Zitat "verfrühte Optimierung ist die Wurzel allen Übels", mag das eine Übertreibung sein, zeigt aber immer noch, wie ernsthafte Probleme eine vorzeitige Optimierung später verursachen kann.

Wenn wir vor der Einrichtung einer effektiven Architektur die Leistung optimieren, können wir die Lesbarkeit des Codes verringern, das Debugging und die Wartung erschweren und unserem Code überflüssige Teile hinzufügen .

Um eine vorzeitige Optimierung zu vermeiden, ist es eine gute Idee, dem YAGNI-Programmierprinzip zu folgen, das rät, "Dinge immer dann zu implementieren, wenn Sie sie wirklich brauchen, niemals wenn Sie nur voraussehen, dass Sie sie brauchen."

2. Das Rad neu erfinden

Das Anti-Pattern "Neuerfindung des Rades" wird manchmal auch als "Gestaltung im Vakuum" bezeichnet . Es passiert, wenn wir alles alleine machen wollen und alles von Grund auf neu schreiben, ohne nach bereits existierenden Methoden, APIs oder Bibliotheken zu suchen.

Das Rad neu zu erfinden ist nicht nur eine zeitraubende Sache, sondern kundenspezifische Lösungen, insbesondere für Basisfunktionen, sind selten so gut wie Standardlösungen, die bereits von vielen Entwicklern und Benutzern getestet wurden.

3. Abhängigkeits-Hölle

Das Gegenteil des Antipatterns "Neuerfindung des Rades" ist ein weiteres gemeinsames Antipattern namens "Abhängigkeitshölle" .

Wenn wir, anstatt alles von Grund auf neu zu schreiben, zu viele Bibliotheken von Drittanbietern verwenden, die auf bestimmte Versionen anderer Bibliotheken angewiesen sind, können wir leicht in eine kaum handhabbare Situation geraten, wenn wir diese aktualisieren wollen, da diese Abhängigkeiten in vielen Fällen nicht kompatibel sind einander .

Abhängigkeitshölle können mithilfe von Paketmanagern gelöst werden, die in der Lage sind, voneinander abhängige Abhängigkeiten intelligent zu aktualisieren . Wenn wir von dem Problem zu sehr überwältigt sind, kann Refactoring auch eine gute Idee sein.

4. Spaghetti-Code

"Spaghetti Code" ist wahrscheinlich das bekannteste Kodierungs-Antipattern. Es beschreibt eine Anwendung, die wegen des Fehlens einer geeigneten Architektur schwer zu debuggen oder zu modifizieren ist .

Das Ergebnis von schlechtem Software-Design ist eine Menge Code, der in seiner Struktur einer Schüssel Spaghetti ähnlich ist, dh verschlungen und gewunden . Lesbarkeit von Spaghetti-Code ist sehr gering, und es ist normalerweise eine fast unmögliche Mission zu verstehen, wie es genau funktioniert.

Spaghetti-Code ergibt sich normalerweise aus der Kombination verschiedener schlechter Programmierpraktiken, wie der Code, der keine richtigen Bedingungsblöcke enthält, viele goto-Anweisungen, Ausnahmen und Threads enthält, Teile enthält, die irgendwo anders gehören, minimale Beziehungen zwischen Objekten haben, Funktionen haben oder Methoden, die nicht wiederverwendet werden können oder nicht richtig oder überhaupt dokumentiert sind.

5. Programmierung per Permutation

"Programmieren durch Permutation" oder "Programmieren durch Zufall" geschieht, wenn wir versuchen, eine Lösung für ein Problem zu finden, indem wir mit kleinen Modifikationen sukzessive experimentieren, sie einzeln testen und bewerten, und schließlich die eine, die zuerst funktioniert, implementieren.

Programmieren per Permutation kann leicht neue Bugs in unseren Code einführen, schlimmer noch, sie sind Bugs, die wir nicht unbedingt sofort erkennen. In vielen Fällen ist es auch nicht vorhersehbar, ob die Lösung für alle möglichen Szenarien geeignet ist oder nicht.

6. Kopieren und Einfügen Programmierung

"Kopieren und Einfügen" tritt auf, wenn wir nicht dem DRY-Codierprinzip folgen. Statt generische Lösungen zu erstellen, fügen wir bereits vorhandene Codeschnipsel an verschiedenen Stellen ein und bearbeiten sie später in den gegebener Kontext.

Diese Praxis führt zu einem Code, der sich sehr repetitiv darstellt, da sich die eingefügten Codeteile normalerweise nur in kleinen Diskrepanzen unterscheiden.

Kopieren und Einfügen-Programmierung wird nicht nur von unerfahrenen Entwicklern, sondern auch von erfahrenen Programmierern durchgeführt, da viele von ihnen dazu neigen, ihre eigenen vorgefertigten, gut getesteten Code-Schnipsel für bestimmte Aufgaben zu verwenden, was leicht zu unbeabsichtigten Wiederholungen führen kann .

7. Cargo-Kult-Programmierung

Der Name "Cargo-Kult-Programmierung" stammt von einem speziellen ethnographischen Phänomen, dem "Cargo-Kult". Nach dem Zweiten Weltkrieg traten im Südpazifik Frachtkulte auf, als der erzwungene Kontakt mit den Hochkulturen dazu führte, dass die von den Frachtschiffen auf die Inseln mitgebrachten Produkte wie Coca-Cola, Fernseher und Kühlschränke durch übernatürliche Kräfte hergestellt wurden Methoden; und wenn sie magische Rituale durchführen, die den Gewohnheiten der Westler ähneln, wird die mit Waren gefüllte Fracht wiederkommen.

Wenn wir das Antipattern der Cargocult-Programmierung begehen, machen wir dasselbe. Wir verwenden Frameworks, Bibliotheken, Lösungen, Entwurfsmuster usw., die für andere gut funktionierten, ohne zu verstehen, warum wir dies tun oder wie die genannten Technologien genau funktionieren.

In vielen Fällen tun Entwickler nur rituell, was zu dieser Zeit angesagt ist, ohne irgendeinen wirklichen Zweck . Diese Vorgehensweise ist nicht nur schlecht, weil sie unsere Anwendung überflüssig macht, sondern sie kann auch leicht neue Fehler in unseren Code einbringen.

8. Lavafluss

Wir sprechen über den "Lava Flow" Antipattern, wenn wir mit Code arbeiten müssen, der redundante oder minderwertige Teile hat, die integraler Bestandteil des Programms zu sein scheinen, aber wir verstehen nicht vollständig, was es tut oder wie es die gesamte Anwendung beeinflusst . Dies macht es riskant, es zu entfernen.

Dies geschieht normalerweise mit Legacy-Code oder wenn der Code von jemand anderem geschrieben wurde (normalerweise ohne entsprechende Dokumentation) oder wenn das Projekt zu schnell von der Entwicklungs- in die Produktionsphase überging.

Der Name des Antipatterns kommt von seiner Ähnlichkeit mit Lava, die von Vulkanen kommt, dh zuerst bewegt es sich schnell und flüssig, ohne zu viele Vorsichtsmaßnahmen zu treffen, aber später erstarrt es und wird schwer zu entfernen.

Theoretisch können wir Lavaströme mit umfangreichen Tests und Refactoring loswerden, aber in der Praxis ist die Implementierung oft schwer oder sogar unmöglich . Da Lavaströme in der Regel hohe Leistungskosten haben, ist es besser, sie zu verhindern, indem Sie von Anfang an eine gut durchdachte Architektur und einen soliden Arbeitsablauf einrichten.

9. Harte Codierung

"Hard Coding" ist ein bekanntes Antipattern, vor dem uns die meisten Webentwicklungsbücher im Vorwort warnen. Hartes Codieren ist die unglückliche Praxis, in der Konfigurations- oder Eingabedaten, wie z. B. ein Dateipfad oder ein Remote-Host-Name, im Quellcode gespeichert werden, anstatt sie aus einer Konfigurationsdatei, einer Datenbank, einer Benutzereingabe oder einer anderen externen Quelle zu beziehen .

Das Hauptproblem bei hartem Code ist, dass er nur in einer bestimmten Umgebung korrekt funktioniert und dass sich die Bedingungen jederzeit ändern . Wir müssen den Quellcode ändern, normalerweise an mehreren verschiedenen Stellen.

10. Soft-Codierung

Wenn wir uns sehr bemühen, die Falle der harten Codierung zu vermeiden, können wir leicht auf ein anderes Antipattern namens "soft coding" stoßen, was genau das Gegenteil ist.

Bei Soft-Coding legen wir Dinge, die im Quellcode liegen sollten, in externe Quellen, beispielsweise speichern wir Geschäftslogik in der Datenbank. Der häufigste Grund dafür ist die Befürchtung, dass sich die Geschäftsregeln in Zukunft ändern werden. Daher müssen wir den Code neu schreiben.

In extremen Fällen kann ein softcodiertes Programm so abstrakt und verschachtelt werden, dass es fast unmöglich ist, es zu verstehen (besonders für neue Teammitglieder), und extrem schwer zu warten und zu debuggen .