Bei der Programmierung treten drei Codeprobleme auf: Hardcode, Govnokod und Schizokod.
Reden wir darüber.
Hardcode
Dies ist ein bekanntes Problem, wenn ein Programmierer aufgrund von Eile oder Faulheit Code ohne Rücksicht auf Variablen schreibt. Der vielleicht häufigste Fall ist die Domain der Site. Es kann von Umgebung zu Umgebung unterschiedlich sein und verursacht oft große Probleme. Hier ist alles einfach. Auf verschiedenen Plattformen wird dies auf unterschiedliche Weise gelöst. Die Hauptsache ist, die auf der Plattform festgelegten Vereinbarungen und Regeln einzuhalten.
In der Regel werden Probleme dieser Klasse schnell erkannt und leicht behandelt.
Govnokod
Dies ist ein schwierigeres Problem. Oft subjektiv. Grob gesagt ist dies eine Verletzung des Codestils, der im Kopf, im Team oder in der Community angewendet wird.
Abhängig von der Plattform und manchmal sogar innerhalb der Plattform gibt es unterschiedliche Codestile:
Dies ist aus der PHP-Welt. In anderen Gemeinden ist die Situation ähnlich. Dies beinhaltet auch Geschichten über die Registerkarte, die Registerkarte nach 2 Leerzeichen oder die Registerkarte nach 4 Leerzeichen usw.
Hier tritt das Problem des reinen Codes auf ... zum Beispiel lange Funktionen von 3-4 Seiten, was kritisiert wird. Dies ist nicht immer sicher schlecht, aber oft ist es möglich, solche Funktionen zu verkürzen und in eine Reihe von kurzen Funktionen zu unterteilen, von denen jede ihr eigenes Problem löst.
In der Regel lassen sich diese Probleme leicht durch Software und die Kontrolle akzeptierter Standards in einem bestimmten Team lösen.
Kunstflug, wenn ein Entwickler je nach Projekt zwischen verschiedenen Codestilen wechseln kann.
Es ist schlecht, wenn der Entwickler gegen den vom Team verwendeten Codestil verstößt oder seinen bevorzugten (oft der einzig erlernte) Codestil als den einzig richtigen betrachtet.
Es gibt keine richtigen Codestile. Es gibt genehmigte Stile im Team oder allgemein akzeptierte Stile.
Auch ein relativ einfaches Problem und leicht zu lösen.
Schizocode
Dies ist ein weniger beliebtes Problem, aber oft das teuerste.
Schizocode - stammt aus dem Konzept der Schizophrenie. Squeeze aus Wikipedia:
Schizophrenie (aus dem anderen Griechischen: σχίζω "split", "split" + φρήν - "Geist, Denken, Denken"), früher lat. Demenz praecox ("vorzeitige Demenz") oder Schizophrenie ist eine endogene polymorphe psychische Störung oder eine Gruppe von psychischen Störungen, die mit dem Zusammenbruch von Denkprozessen und emotionalen Reaktionen verbunden sind.
Es gibt zwei wichtige Punkte: Spaltung und Demenz. Welches sind die Ursachen für Schizocode.
Ein idealer Code ist ein Code, der nicht geschrieben ist. Schizocoder kennen dieses Konzept nicht.
Kurz gesagt, der Schizocode ist ein Code, der gegen das Razor-Prinzip von Occam verstößt.
Squeeze aus Wikipedia:
"Occams Rasiermesser (Klinge)" ist ein methodisches Prinzip, benannt nach dem englischen Mönch Franziskaner, dem nominellen Philosophen William Ockham. In vereinfachter Form heißt es: "Sie sollten nicht ohne Notwendigkeit multiplizieren"
Dies drückt sich darin aus, dass Entwickler den Code und die Architektur ohne guten Grund komplizieren. Oder das Gewicht der Gründe existiert nur in ihrer Vorstellung.
Imaginäre Probleme - die Wurzel schlechter Software
Es gibt zwei Hauptsymptome: die Erfindung von Fahrrädern auf Krücken und die Multiplikation von Abstraktionsschichten.
Die Erfindung von Fahrrädern auf Krücken
Es wird zum Ausdruck gebracht, dass Entwickler angesichts der schlechten Lernfähigkeit, anstatt nach optimalen Lösungen / Methoden im Rahmen der Plattform und der vorhandenen Architektur zu suchen, anfangen, Fahrräder / Krücken zu erfinden.
Beispiele:
- Schreiben Sie Ihre eigenen CMS / ptm-Frameworks, bei denen vorhandene einen schwerwiegenden Fehler aufweisen
- Symfony Blog Trotz der Tatsache, dass die ganze Welt WordPress dafür verwendet.
- Online-Shops auf Laravel, obwohl es WooCommerce (Nr. 1 der Welt), Magento (ebenfalls gut), 1C-Bitrix (im schlimmsten Fall besser als Laravel) gibt
- Ich bin auf eine Situation gestoßen, in der sich das Layout auf Bootstrap befand, aber der Entwickler hat beschlossen, seine eigenen Stile für Labels zu schreiben. Was hat Sie daran gehindert, die Label-Klasse hinzuzufügen, über die Bootstrap bereits verfügt?
- Redundante Funktionen, Methoden und Klassen haben keinen Kalkül, der mit vorgefertigten Bibliotheken und Methoden auf den verwendeten Plattformen vermieden werden könnte
Unkontrollierte Weitergabe von Abstraktionsebenen: zusätzliche Klassen, Vererbung, Methoden
Der aufmerksame Leser konnte einen Konflikt mit dem Govnokod feststellen. In einem Fall besteht das Problem darin, dass die Funktion oder Klasse zu lang ist, das Problem jedoch darin besteht, dass im Gegenteil eine übermäßige Fragmentierung von Entitäten vorliegt.
Hierbei ist zu beachten, dass dies eines der Extreme ist, deren Grenze nicht immer leicht zu beobachten ist.
Einerseits ist es schlecht zu versuchen, alles mit einer Funktion auf 3 Seiten oder einer Klasse zu lösen, die HTML- und Vorlagenmechanik enthält, und irgendwo ist es rentabler, den Code in mehrere Funktionen / Klassen / Komponenten aufzuteilen, von denen jede ihr eigenes Problem löst. Das ist ein Extrem.
Auf der anderen Seite ist ein sehr einfacher Code in 5 Klassen unterteilt, von denen jede 3-4 Methoden mit 3-4 Zeilen mit vielen nutzlosen Vererbungen enthält, wenn Sie eine oder zwei mit minimaler Vererbung oder sogar ohne Vererbung ausführen können, wenn dies vermieden werden kann.
Die Folgen überflüssiger und schlechter Abstraktionen
Weitergabe von Methoden, Klassen, Vererbung ohne guten Grund - das ist überflüssiger Code und das Wachstum von Abstraktionsebenen.
Alles hat einen Preis sowie zusätzliche Abstraktionen:
- neues Entwicklertraining verwöhnt
- Je mehr Code, desto mehr Fehlerquellen, desto mehr Fehler
- Diagnose und Code-Debugging sind kompliziert
Gedankenproblem
Je mehr Ebenen von Abstraktion, Vererbung und Methoden vorhanden sind, desto mehr Denkkraft wird für Änderungen, Verbesserungen und die Diagnose von Problemen benötigt.
Und das Arbeitsvolumen des Kraftstoffs ist begrenzt und oft verursacht sein Mangel sehr hohe Entwicklungskosten.
Jeder Entwickler, der die Diagnose stellte und den Schizocode änderte, beruhte auf einem Mangel an Gedankenbrennstoff. Aber nicht jeder war sich dessen bewusst.
Ein Video, das erklärt, was Kraftstoff denkt, und eine einfache Übung für 1 Minute gibt, mit der Sie sich an einem einfachen Beispiel an das Gefühl des Kraftstoffmangels erinnern können:
Läuft es in OOP, Klassen und Vererbung?
Überhaupt nicht. Dies ist jedoch etwas Wahres. In einem funktionalen Stil ist Novokovodit einfacher, aber Schizocode ist dort schwierig. OOP bietet einerseits viele Vorteile, eröffnet aber auch Spielraum für einen Schizocode.
OOP, Klassen und Vererbung sind weder schlecht noch gut. Dies sind die Werkzeuge. Ich persönlich benutze sie.
Ich habe jedoch eine Reihe meiner eigenen Regeln:
- Ich schreibe fast immer Klassen wegen der Kapselung, aber oft habe ich genug Singleton, statische Methoden und zustandslose
- Wo es eine häufig verwendete Methode gibt, schreibe ich Funktionen, die oft nur Wrapper für die Methoden einer Klasse sind, aber manchmal ist eine Funktion nur eine Funktion ohne Klasse, und dies ist gegebenenfalls gut.
- Stateful Klassen - ja, aber seltener und immer wieder nur, wenn es gute Gründe gibt
- Vererbung ist noch seltener und nur dort, wo es gute Gründe dafür gibt (ich versuche, Abstraktionsebenen zu reduzieren und Gedanken und Treibstoff in einem Team zu sparen).
Zusammenfassung
Wir reden viel über Hardcode und Govnokode, weil Sie sind verständlich und leicht greifbar. Der Schizocode wird jedoch häufig nicht bestraft, da es schwieriger ist, den Schaden zu identifizieren und zu verstehen. Und das Ausmaß des Schadens ist möglicherweise größer, als man sich mit einem Schnappschuss vorstellen kann.
Mein Manifest ist einfach:
- Es ist am besten, das Best-of-Breed-Prinzip zu lernen, bevor Sie ein anderes Krückenrad erfinden, das niemand braucht
- Lassen Sie uns weniger Schizocode schreiben
- Lassen Sie uns lernen, das Razor-Prinzip von Occam einzuhalten und den Code nicht ohne Grund zu komplizieren
- Lasst uns unsere Gedanken und unser Team retten
Nun, ich werde mich freuen, sowohl zur Unterstützung des Manifests als auch seiner Kritik Stellung zu nehmen.