Webentwicklung Die 10 Kodierungsmuster, die Sie vermeiden sollten
Wenn Sie die Architektur einer Website oder Anwendung entwerfen oder einen effektiven Kodierungsworkflow einrichten, müssen wir uns häufig mit wiederkehrenden Problemen auseinandersetzen. Wir müssen diese Software-Design-Probleme nicht unbedingt von Grund auf lösen Lösungen auf architektonischer Ebene können wiederverwendet werden genauso wie Codeausschnitte auf der Mikroebene.
Designmuster sind im Allgemeinen wiederverwendbare Lösungen für bestimmte szenarien kann das nützlich, um häufig auftretende Probleme zu lösen, und kann uns enorm dabei helfen, unseren Code zu optimieren.
Während Entwurfsmuster ein hervorragendes Mittel sind, um unseren Entwicklungsprozess durch die Verwendung bewährter Formeln zu verbessern, können wir manchmal auch etwas falsch machen. Diese werden als Antimuster bezeichnet.
Was sind Antipatterns??
Der Begriff “Antipattern” wurde 1998 in einem Buch namens AntiPatterns geprägt wiederverwendete Lösungen, die anfangs nützlich erscheinen, aber später stellt sich heraus mehr schaden als nützen.
Dies kann verschiedene Ursachen haben, zum Beispiel, wenn wir die Muster nicht im richtigen Kontext, in der richtigen Einstellung oder in der richtigen Zeit verwenden (in der Vergangenheit wirksame Lösungen funktionieren möglicherweise nicht immer in der Gegenwart) oder in anderen Fällen das gesamte Paradigma war von Anfang an einfach nur schlecht.
Antimuster werden auch häufig aufgerufen Muster des Scheiterns. Die gute Nachricht ist, dass es so ist möglich, sie zu erkennen und zu vermeiden.
In diesem Beitrag werfen wir einen Blick auf 10 gängige Antipattern von Codierern in der Webentwicklung, die uns denken lassen, dass wir gut optimierten Code haben. (Beachten Sie, dass die in diesem Beitrag aufgelisteten Gegenmuster nicht unbedingt mit den Angaben in dem oben genannten Buch übereinstimmen.)
1. Vorzeitige Optimierung
Ein gutes Timing ist ein entscheidender Faktor bei der Codeoptimierung. Das Gegenmuster von können wir leicht reproduzieren “vorzeitige Optimierung”, wenn wir auf kleine Wirkungsgrade achten und diese zu früh im Entwicklungsprozess optimieren, bevor wir genau wissen, was wir tun wollen.
Nach Donald Knuths berühmtem Zitat “vorzeitige Optimierung ist die Wurzel allen Übels“, Dies kann übertrieben sein, zeigt aber immer noch, wie schwerwiegende Probleme eine vorzeitige Optimierung später verursachen kann.
Wenn wir die Leistung vor dem Aufbau einer effektiven Architektur optimieren, können wir dies tun geringere Lesbarkeit des Codes, machen Debugging und Wartung schwieriger, und Überflüssige Teile hinzufügen zu unserem Code.
Um eine vorzeitige Optimierung zu verhindern, ist es ratsam, das YAGNI-Programmierprinzip (You Are Not Not Need) zu befolgen, das zu empfehlen ist “Implementieren Sie immer Dinge, wenn Sie sie wirklich brauchen, niemals, wenn Sie nur voraussehen, dass Sie sie brauchen.”
2. Das Rad neu erfinden
Das “das Rad neu erfinden” Antipattern wird manchmal auch als “im luftleeren entwerfen”. Es passiert, wenn wir wollen mach alles alleine und schreib alles von Grund auf, ohne nach bereits vorhandenen Methoden, APIs oder Bibliotheken zu suchen.
Das Rad neu zu erfinden ist nicht nur eine Zeitverschwendung, sondern kundenspezifische lösungen, insbesondere für grundlegende funktionalitäten, sind selten so gut wie standardlösungen das wurde bereits von vielen Entwicklern und Anwendern getestet.
3. Abhängigkeit Hölle
Das Gegenteil von dem “das Rad neu erfinden” Antipattern ist ein anderes bekanntes Antipattern “Abhängigkeit Hölle”.
Wenn wir nicht alles von Grund auf neu schreiben, verwenden wir zu viele Bibliotheken von Drittanbietern, die auf bestimmten Versionen anderer Bibliotheken basieren, Wir können leicht in eine kaum überschaubare Situation geraten, wenn wir ein Update durchführen wollen, da es sich in vielen Fällen um subsidiäre Abhängigkeiten handelt miteinander unvereinbar.
Abhängigkeit Hölle kann gelöst werden, indem Paket-Manager verwenden, die dazu in der Lage sind interdependente Abhängigkeiten intelligent aktualisieren. Wenn wir zu sehr von dem Problem überfordert sind, kann auch das Refactoring eine gute Idee sein.
4. Spaghetti-Code
“Spaghetti-Code” ist wahrscheinlich das bekannteste Kodierungsmuster. Es beschreibt Eine Anwendung, die aufgrund fehlender Architektur nur schwer zu debuggen oder zu modifizieren ist.
Das Ergebnis eines schlechten Softwaredesigns ist eine Reihe von Code, der in seiner Struktur einer Schüssel Spaghetti ähnelt, d. H. verwirrt und verschlungen. Die Lesbarkeit von Spaghetti-Code ist sehr gering und es ist normalerweise eine fast unmögliche Aufgabe, die genaue Funktionsweise von Spaghetti zu verstehen.
Spaghetti-Code stammt normalerweise aus dem Kombination verschiedener schlechter Kodierungspraktiken, Beispielsweise enthält der Code keine richtigen Bedingungsblöcke, enthält viele goto-Anweisungen, Ausnahmen und Threads, die Teile enthalten, die an anderer Stelle gehören, minimale Beziehungen zwischen Objekten, Funktionen oder Methoden, die nicht wiederverwendet werden können oder die nicht ordnungsgemäß dokumentiert sind überhaupt.
5. Programmierung durch Permutation
“Programmierung durch Permutation” oder “Programmierung durch Zufall” passiert, wenn wir versuchen, eine Lösung für ein Problem zu finden, indem wir sukzessive mit kleinen Modifikationen experimentieren, sie einzeln testen und bewerten und schließlich diejenige implementieren, die zuerst funktioniert.
Das Programmieren durch Permutation ist problemlos möglich füge neue Fehler in unseren Code ein, Schlimmer noch, es sind Fehler, die wir nicht sofort erkennen können. In vielen Fällen lässt sich auch nicht vorhersagen, ob die Lösung für alle möglichen Szenarien funktioniert oder nicht.
6. Kopieren und Einfügen der Programmierung
“Programmierung kopieren und einfügen” Dies geschieht, wenn wir nicht dem DRY-Codierungsprinzip (DRY) folgen. Statt generische Lösungen zu erstellen, fügen wir bereits vorhandene Code-Snippets an verschiedenen Stellen ein und bearbeiten sie später in den jeweiligen Kontext.
Diese Übung führt zu einem Code, der sich stark wiederholt, denn die eingefügten Codeteile unterscheiden sich meist nur in geringfügigen Abweichungen.
Das Kopieren und Einfügen von Programmen wird nicht nur von neuen Entwicklern begangen, sondern auch von erfahrenen Programmierern, da viele von ihnen dazu neigen Verwenden Sie für bestimmte Aufgaben eigene, vorab geschriebene, gut getestete Code-Snippets, was leicht dazu führen kann unbeabsichtigte Wiederholungen.
7. Cargo-Cult-Programmierung
Der Name von “Cargo-Kult-Programmierung” kommt von einem bestimmten ethnographischen Phänomen namens “Frachtkult”. Nach dem Zweiten Weltkrieg tauchten im Südpazifik Ladenkulte auf, als der Ureinwohner aufgrund des erzwungenen Kontakts mit fortgeschrittenen Zivilisationen der Meinung war, dass hergestellte Produkte wie Coca-Cola, Fernseher und Kühlschränke, die von Frachtschiffen auf die Inseln gebracht wurden, auf übernatürliche Weise entstanden waren Methoden; und wenn sie magische Riten durchführen, die den Gewohnheiten westlicher Menschen ähneln, wird die mit Waren gefüllte Ladung wieder kommen.
Wenn wir das Gegenmuster der Frachtkultprogrammierung festlegen, machen wir im Grunde dasselbe. Wir verwenden Frameworks, Bibliotheken, Lösungen, Entwurfsmuster usw., die für andere gut funktionierten, ohne zu verstehen, warum wir das tun, oder wie genau diese Technologien funktionieren.
In vielen Fällen nur für Entwickler Rituell tun, was zu dieser Zeit Hüfte ist, ohne einen wirklichen Zweck. Diese Vorgehensweise ist nicht nur schlecht, weil unsere Anwendung dadurch überflüssig wird, sondern auch neue Fehler in unseren Code aufgenommen werden können.
8. Lavafluss
Wir sprechen über das “Lavastrom” Antipattern, wenn wir müssen Umgang mit Code, der redundante oder minderwertige Teile enthält Das scheinen integral zu sein zu dem Programm, aber wir verstehen nicht vollständig, was es macht oder wie es die gesamte Anwendung beeinflusst. Dies macht es riskant, es zu entfernen.
Das passiert normalerweise mit Legacy-Code, oder wenn der Code wurde von jemand anderem geschrieben (normalerweise ohne ordnungsgemäße Dokumentation) oder wenn das Projekt zu schnell von der Entwicklungsphase in die Produktionsphase übergeht.
Der Name des Antipatterns kommt von seiner Ähnlichkeit mit der aus Vulkanen stammenden Lava, d. H. Sie bewegt sich zunächst schnell und flüssig, ohne zu viele Vorsichtsmaßnahmen zu treffen, erstarrt jedoch und wird schwer zu entfernen.
Theoretisch können wir Lavaflüsse mit loswerden ausführliche Tests und Refactoring, aber in der Praxis, Die Implementierung ist häufig schwierig oder sogar unmöglich. Da Lavaströme in der Regel hohe Leistungskosten verursachen, ist es besser, dies durch eine gut durchdachte Architektur und einen guten Workflow von Anfang an zu verhindern.
9. Harte Codierung
“Harte Kodierung” ist ein bekanntes Muster, gegen das die meisten Bücher zur Webentwicklung direkt im Vorwort warnen. Hardcodierung ist die unglückliche Praxis, bei der Wir speichern Konfigurations- oder Eingabedaten, B. einen Dateipfad oder einen Remote-Hostnamen, im Quellcode Anstatt es aus einer Konfigurationsdatei, einer Datenbank, einer Benutzereingabe oder einer anderen externen Quelle abzurufen.
Das Hauptproblem bei Hardcode ist das es funktioniert nur in einer bestimmten Umgebung richtig, und bei jederzeit ändern sich die bedingungen, wir müssen ändern der Quellcode, in der Regel an mehreren verschiedenen Orten.
10. Weiche Codierung
Wenn wir uns sehr bemühen, die Fallstricke der harten Codierung zu vermeiden, können wir leicht auf ein anderes Antipattern stoßen “weiche Codierung”, Das ist genau das Gegenteil.
In weicher Codierung, Wir legen Dinge, die im Quellcode enthalten sein sollten, in externe Quellen ein, Zum Beispiel speichern wir Geschäftslogik in der Datenbank. Der häufigste Grund, warum wir dies tun, ist die Befürchtung, dass sich Geschäftsregeln in der Zukunft ändern werden. Daher müssen wir den Code umschreiben.
Im Extremfall kann ein Soft-Code programmiert werden so abstrakt und verschlungen werden, dass es fast unmöglich ist, es zu verstehen (besonders für neue Teammitglieder) und extrem schwer zu warten und zu debuggen.
