Das wichtigste Muster in der Programmierung

Guten Tag, ich programmiere seit 8 Jahren und programmiere in all seinen Erscheinungsformen: Entwickeln der Serverseite in verschiedenen Programmiersprachen, Entwickeln der Clientseite, Programmieren der Netzwerke, Verwalten von Linux und Optimieren der Leistung. Und wenn Sie so lange mit einem Geschäft beschäftigt waren, es aufrichtig lieben und nach Selbstentwicklung streben, dann entstehen unweigerlich verschiedene kausale Zusammenhänge auf dem entsprechenden Gebiet. Sie sehen jene Zusammenhänge, die Sie vorher noch nicht einmal kannten oder die Sie einfach als unbedeutend betrachteten. Das nennen die Leute Erfahrung.

Und es geht um einen dieser Kausalzusammenhänge, den ich in diesem Artikel mit Ihnen teilen möchte. Ich dachte zu schreiben, dass dies eine der wichtigsten Ursache-Wirkungs-Beziehungen ist, um ein wenig weniger radikal zu sein, aber immer noch nicht. Diese Ursache-Wirkungs-Beziehung ist mit großem Abstand die wichtigste Ursache-Wirkungs-Beziehung bei der Programmierung. Es läuft wie ein Thread durch absolut alle Bereiche der Programmierung: Schreiben von Code, Entwerfen einer Schnittstelle, Bereitstellen einer Anwendung, Organisieren eines Teams, Verwalten eines Bug-Trackers und so weiter. Und ich nenne diesen heiligen Kausalzusammenhang die Minimierung von Variablen .

Mit dem Begriff Variable meine ich nicht nur gewöhnliche Variablen (die über die Schlüsselwörter var , let , function deklariert werden), sondern auch Variablen im abstrakteren Sinne des Wortes: erstellte Ordner im Projektbaum, verbundene Bibliotheken, Anzahl der Ajax-Aufrufe an den Server, Anzahl Komponenten in der Schnittstelle, die Anzahl der Protokolle, denen der Programmierer beim Festschreiben des Codes folgen sollte (z. B. Codeüberprüfung, jede Funktion in einem separaten Brunch) und so weiter.

Tatsächlich ist der gesamte Programmierprozess eine Aufzählung von Sorten in Richtung der Implementierung dieser oder jener Funktion unter Verwendung der minimal möglichen Anzahl von Variablen (zumindest betrachte ich die Programmierung aus dieser Perspektive). Der Code, der die Funktion mit weniger Abhängigkeiten / Dateien / Codezeilen implementiert, ist besser als derjenige, der dieselbe Funktionalität mit einer großen Anzahl von Variablen implementiert. Wenn eine Utility-Klasse nur eine Funktion enthält - Sie müssen diese Utility-Klasse entfernen, wenn die Funktion nur aus einer Zeile besteht - müssen Sie diese Funktion entfernen, wenn die Komponente nur 10 Codezeilen enthält - Sie müssen diese Komponente löschen, wenn sich nur eine Datei im Ordner befindet - Sie müssen diesen Ordner entfernen und so weiter. Und wenn mehrere Tausend dieser scheinbar unbedeutenden Änderungen addiert werden, entsteht ein schöner, prägnanter und minimalistischer Code, der sehr einfach zu lesen ist. Der Teufel steckt im Detail, wie sie sagen.

Hier ist eine Liste der positiven Effekte, die auftreten, wenn Sie mit dem Programmieren beginnen, basierend auf dem Prinzip der Minimierung von Variablen:

• Weniger Fehler. Da weniger Code geschrieben wird, wird die Anzahl der Stellen, an denen Sie einen Fehler machen können, entsprechend reduziert.
• Es ist einfacher, neue Leute in das Projekt einzuführen. Die Komplexität des Projekts ist direkt proportional zur Anzahl der Variablen in diesem Projekt. Je weniger Variablen, desto einfacher ist es, neue Leute vorzustellen.
• Einfacher, neue Funktionen hinzuzufügen. Da eine geringere Menge an Code untersucht werden muss, ist es einfacher, die Funktion in den Kopf zu laden und dadurch neue Funktionen hinzuzufügen oder vorhandenen Code zu ändern.
• Vorhersehbarkeit. Der Programmierprozess wird viel vorhersehbarer, und Sie können leichter vorhersagen, wie lange es dauern wird, das eine oder andere Feature zu entwickeln, da die Anzahl der "Gags" abnimmt. Typischerweise sind es die Stecker, die die meisten Probleme verursachen und zu einer Verzögerung der Fristen führen.

Aber sehr oft tritt die gegenteilige Situation auf, Programmierer beginnen sich durch die Einführung neuer Variablen zu behaupten. Wir führen 20 verschiedene Bibliotheken und CSS-Frameworks ein, erstellen eine große Anzahl von mehrstufigen Abstraktionen wie UserFactoryManager (insbesondere Java-Programmierer sündigen aus irgendeinem Grund), erstellen zu viele Verzeichnisse, führen fortgeschrittenere Entwicklungsmethoden ein, fügen weitere Protokolle hinzu, bevor Dateien festgeschrieben werden. usw. Und die Motivation hinter solchen Entscheidungen kann verstanden werden, weil sie die Illusion von Professionalität erzeugt. Sie sagen, schauen Sie, wie viel ich weiß und mit welchen komplexen Abstraktionen ich umgehen kann. Aber oft schadet dies dem Projekt schrecklich.

Verstehen Sie mich nicht falsch, ich bin nicht gegen die Verwendung fortschrittlicherer Methoden, Frameworks und Technologien. Ich sage nur, dass sie sehr oft nur aufgrund von Hype eingeführt werden und nicht, weil diese Technologie ein dringendes Problem im Projekt löst.

Die Lösung des Problems zu vieler Variablenmengen kann als Overengineering bezeichnet werden . Sie müssen jedoch zugeben, dass, wenn Sie diese Situation so beschreiben, als ob das Problem durch zu viele Variablen gelöst wird, dies eine viel genauere Beschreibung dieses Phänomens ist.

Oft ist die Einführung neuer Variablen durch Skalierbarkeit gerechtfertigt. Wenn Sie hier eine UserManagerFactory erstellen, können wir bei Bedarf jederzeit eine Funktion übernehmen und hinzufügen. In Wirklichkeit ist Skalierbarkeit jedoch nicht der Fall, wenn viele Variablen eingeführt werden, sondern wenn nur wenige Variablen vorhanden sind. Überlegen Sie, wo Sie leichter neue Funktionen schreiben können: in der Chrome-Browser-Engine oder in einem völlig neuen Projekt, das Sie von Grund auf neu schreiben? Die Einführung neuer Variablen führt nicht zur Skalierbarkeit der Architektur. Was die Skalierbarkeit eines Projekts wirklich verbessert, ist, wenn Sie unnötige Variablen entfernen und vorhandenen Code vereinfachen.

Eine große Anzahl unnötiger Variablen - genau aus diesem Grund hasse ich die Programmiersprache Scala mit heftigem Hass und ich liebe JavaScript. Scala ist nur die Quintessenz eines überkomplizierten, sehr verwirrenden Typsystems, vieler Konzepte, die sich gegenseitig duplizieren, impliziter Konvertierungen und einer Vielzahl von Möglichkeiten, dasselbe zu tun. Wenn ich diese Programmiersprache verwende, denke ich nicht darüber nach, was zu tun ist, sondern darüber, wie es zu tun ist. Ich finde mich gerade sehr oft wieder, mein Ziel ist es nur, den Compiler zum Schweigen zu bringen. Auf der anderen Seite ist JavaScript das genaue Gegenteil von Scala, es ist eine Größenordnung minimalistischer, wenn ich es verwende, verbringe ich viel weniger geistige Anstrengungen, um das eine oder andere Konzept auszudrücken. Natürlich hat diese Einfachheit auch ihre Nachteile. Beispielsweise meldet der Compiler in Scala einen Fehler in der Kompilierungsphase, während Sie in JavaScript nur einen Fehler in der Laufzeit erkennen können und es für JavaScript grundsätzlich unmöglich ist, dieselbe funktionale IDE wie für stark typisierte zu schreiben Sprachen, aber das sind die Opfer, mit denen ich mich versöhnen will.

Das Prinzip der Minimierung von Variablen muss beim Entwerfen von Schnittstellen angewendet werden. Vergleichen wir beispielsweise Webschnittstellen für zwei konkurrierende soziale Netzwerke, um Tinder und Badoo zu datieren. Tatsächlich gibt es nur eine Seite in der Tinder-Weboberfläche, das Benutzerprofil, aktive Chats und die Suche nach neuen Bekannten werden auf einer Seite angezeigt, und es besteht keine Notwendigkeit, zu anderen Seiten zu wechseln. In dieser Oberfläche werden alle Benutzeranforderungen durch eine Mindestanzahl von Komponenten erfüllt. Während bei Badoo die Funktionalität zum Wechseln zum Benutzerprofil, die Nachrichtenschnittstelle und die Seite zum Suchen von Paaren als separate Seiten implementiert sind, muss der Benutzer mehr Aktionen ausführen, um die Anforderungen zu erfüllen, und dementsprechend ist diese Schnittstelle weniger effizient. Natürlich ist dies nur ein sehr kleines Beispiel, aber wenn es Dutzende und Hunderte solcher Beispiele gibt, bestimmen sie zusammen, ob die Schnittstelle durchdacht ist oder nicht. Beim Entwerfen der Schnittstelle muss eine Mindestanzahl von Komponenten erstellt werden, um die Anforderungen des Benutzers zu erfüllen.

Aus dem gleichen Grund mag ich die Ansätze, die Logik, Daten und Präsentation trennen, absolut nicht, da in diesem Fall eine Situation entsteht, in der zum Schreiben einer Funktion zum Erstellen von drei Dateien die Anzahl der Komponenten zunimmt und das Projekt bereits groß geworden ist. dann beginnt die Anzahl der Dateien alle vernünftigen Grenzen zu überschreiten. Wenn Sie beispielsweise Webschnittstellen schreiben, werden Stile normalerweise in separaten Dateien beschrieben, während sich die Knoten, an die diese Stile angehängt sind, in einer anderen Datei befinden. So seltsam es auch scheinen mag, die Hauptmotivation für eine solche Trennung ist die Skalierung. Wenn Sie also die Knoten selbst und ihre Stile trennen, wird die Navigation im Projekt einfacher und es ist möglich, diese beiden Teile der Funktion unabhängig voneinander zu entwickeln. Aber lassen Sie uns sehen, welche Variablen mit diesem Ansatz hinzugefügt werden: neue Dateien mit Stilen für jede Komponente, Selektoren (sie beschreiben, an welchen Knoten die Stile angehängt sind), Kaskadenregeln (wenn mehrere Selektoren denselben Knoten ansprechen). Wenn Sie Stile direkt in die Knoten schreiben, mit denen diese Stile verbunden werden sollen (z. B. über das Stilattribut), werden all diese zusätzlichen Variablen nicht mehr benötigt, was den Code erheblich vereinfacht. In letzter Zeit ist dieser Ansatz immer beliebter geworden. Es gibt viele Bibliotheken, mit denen Sie Stile direkt in das Stilattribut schreiben können.

Neue Variablen sollten immer schrittweise in das Projekt eingeführt werden. Zum Beispiel habe ich zu Beginn beim Schreiben eines Projekts alle Dateien im Stammverzeichnis, ohne Unterverzeichnisse, einfach weil es einfacher ist und nur wenn die Anzahl der Dateien auf 40-60 Dateien ansteigt, werden einige Dateien in Verzeichnissen gruppiert. Zu Beginn ist keine Entwicklungsmethodik erforderlich. Werfen Sie einfach alle Programmierer auf einen Haufen, geben Sie ihnen Aufgaben, und sie werden es selbst herausfinden. Wenn die Entwicklungsmethodik zu früh eingeführt wird, fühlt sie sich wie ein Ersatzkonzept an. Wenn Variablen eingeführt werden, bevor sie benötigt werden, spricht man von vorzeitiger Optimierung.

Ebenso ist es notwendig, Variablen beim Schreiben von Dokumentationen / Artikeln zu minimieren. Wenn ich Dokumentationen schreibe, denke ich immer darüber nach, wie viele Sätze ich mindestens benötige, um meine Gedanken zu vermitteln. Ich analysiere buchstäblich jeden Satz, und wenn es mir so erscheint, als ob dieser Satz nicht notwendig ist, keine zusätzliche semantische Last trägt, wird er gelöscht, wodurch eine sehr komprimierte Seite mit Dokumentation erhalten wird, die die maximale Menge an notwendigen Informationen in einer minimalen Textmenge enthält.

Tatsächlich hat im Allgemeinen jede Variable eine Schuldvermutung, es wird keine Variable benötigt, bis das Gegenteil bewiesen ist.

Sie können gegen mich Einwände erheben , sie sagen dasselbe zu mir, haben Amerika entdeckt, es ist seit langem bekannt und wird durch Prinzipien wie Okama-Rasiermesser , FEST beschrieben . Ich nenne dieses Konzept jedoch lieber „Minimierung von Variablen“, einfach weil diese Interpretation im Kopf sehr prägnant ist und es dementsprechend viel einfacher ist, sich in der Praxis daran zu halten. Wie viele von Ihnen können sich rühmen, sich an jeden Punkt des SOLID-Prinzips erinnert zu haben?

Anfänger schreiben einfachen Code, weil sie nicht wissen, wie man komplexen Code schreibt, durchschnittliche Programmierer schreiben komplexen Code, einfach weil sie können, Profis schreiben einfachen Code, weil sie keinen komplexen Code schreiben wollen.

Es sollte nicht vergessen werden, dass jedes Extrem schlecht ist: Wenn es fanatisch ist, Variablen bis auf atomare Ebene zu minimieren, ist dieser Ansatz sowie die Einführung zu vieler Variablen ein Extrem. Und jedes Extrem ist, wie Sie wissen, schlecht, die Wahrheit liegt immer irgendwo dazwischen.