Share
Die Organisation kann die Wartbarkeit einer Anwendung beeinträchtigen. Bei kleineren Anwendungen ist die Organisation offensichtlicher. Mit zunehmender Anwendung und zunehmender Anzahl von Anwendungsentwicklern und Front-End-Ingenieuren, die Code erstellen, kann die Organisation jedoch verwirrender werden. In diesem Beitrag werden wir einige grundlegende Konzepte zur Organisation von Anwendungen durchgehen, sodass das Finden von relevantem Code ein effizienter und systematischer Prozess ist.
JavaScript sollte in einem effizienten Umfang verwendet werden.
Nehmen wir uns einen Moment Zeit und überlegen wir uns, wie die Teams von Rails und Wordpress ihre Projekte organisieren. Die Chancen stehen gut, dass Sie wahrscheinlich mit dem einen oder dem anderen gearbeitet haben. Beide Frameworks haben eine festgelegte Standardstruktur.
Wenn Sie eine Rails-Anwendung erstellen, erfüllt Rails einen Großteil der wichtigsten organisatorischen Anforderungen für Sie. Da es auf MVC basiert, enthält das Standard-Rails-Setup einen Ordner mit der Bezeichnung "App", der die Ordner "Model" / "View" / "Controller" enthält. Es bietet auch die "Helfer" und "Mailer", die Controller-Erweiterungen, mit deren Hilfe die Lücken zwischen Controllern und Modellen geschlossen werden können.
Rails generiert auch einige andere Elemente auf derselben Ebene wie der Ordner "App", z. B. Konfiguration, Protokollierung, Datenbanken, temporäres Caching, Tests und einige andere Elemente. Was für diese Diskussion besonders interessant ist, sind die App und die öffentlichen Ordner. Im öffentlichen Ordner werden statische Assets bereitgestellt, einschließlich nicht dynamischer HTML-, CSS- und JavaScript-Dateien.
Bei der Arbeit mit Wordpress ist die Benennung und Struktur weitaus weniger offensichtlich.
… Die Anwendung ist für Benutzer erstellt…
Konventionen werden anhand der Dokumentation offengelegt. Insbesondere arbeiten Entwickler wahrscheinlich innerhalb eines Designs, das sich im Verzeichnis wp-content / themes / befindet. Dieses Design enthält eine Reihe von Dateien mit speziellen Namen, die hauptsächlich auf Ansichten basieren. EIN Functions.php Datei fungiert als eine Art "Controller", in den ein Entwickler Funktionen einfügen kann, um sie von den Ansichten zu trennen. Wordpress-Motive verschmutzen jedoch oft die Bereiche zwischen Logik und Präsentation. Datenbankabfragen sind zum Beispiel implizit nach Dateiname, werden jedoch häufig geändert, indem die Abfrage geändert wird, bevor die zurückgegebenen Ergebnisse durchlaufen werden. Diese Manipulation abstrahiert nicht auf dieselbe Weise wie ein Controller (und natürlich ist Wordpress nicht in der Nähe von MVC, daher können wir diese Art von Organisation nicht erwarten.).
Beide Frameworks sind äußerst beliebt und beide verwenden ihre eigene implizite Strukturierung. Sie verlangen unbedingt, dass die Entwickler die Funktionsweise des Systems verstehen, um effizient zu sein. In unseren eigenen Anwendungen sollten wir diesem organisatorischen Paradigma folgen und einen systematischen Ansatz für die Strukturierung von Anwendungen entwickeln. Dies ist für jede einzelne Anwendung sehr unterschiedlich.
Die oben genannten Frameworks erfordern nicht, dass Entwickler die Struktur definieren. Sie sind "vorverdrahtet", um auf bestimmte Weise zu arbeiten.
Ein wichtiger Grund, weshalb robuste Frameworks diese Konfigurationen häufig abstrahieren und Standardstrukturen bereitstellen, ist, dass die Leute damit beginnen, einen Community-Standard zu entwickeln, der auf der Standardstruktur basiert.
Ignorieren Sie Standards nicht, wenn Sie Ihre Anwendung organisieren!
Wenn Sie mit Rails vertraut sind, können Sie wahrscheinlich ein Github-Repository betrachten und wissen, ob es sich bei der Rails-App nur um die Ordnerstruktur handelt - Rails hat einen dokumentierten Standard.
Ignorieren Sie bei der Organisation Ihrer Bewerbung keine Standards! Es ist sehr wahrscheinlich, dass Sie, wenn Sie eine Anwendung auf Unternehmensebene organisieren, mit modularen, diskreten, service-basierten Mini-Anwendungen zu tun haben. Es kann zum Beispiel der Fall sein, dass Sie mehrere Anwendungen mit einem oder mehreren verschiedenen Frameworks erstellt haben, oder dass diese von Hand gerollt werden und in Verbindung miteinander arbeiten, wodurch APIs verfügbar gemacht werden, die Hooks für die anderen Dienste bereitstellen. Jede dieser diskreten Anwendungen folgt wahrscheinlich den Standards des Frameworks, auf dem sie aufbaut. Diese Standards existieren, weil sie so gestaltet wurden, dass sie funktionieren. Wenn Sie versuchen, diese Standards in einer separaten Anwendung zu ändern, werden Sie wahrscheinlich enden Verschwenden Sie mehr Zeit für die Konfiguration als tatsächlich eine funktionierende Anwendung erstellen.
In der Praxis bedeutet dies, dass die Dinge, die einem Dienst für einen anderen zur Verfügung gestellt werden, in einer einheitlichen Weise funktionieren sollten, und die Teile eines Dienstes sollten so funktionieren, wie es für diesen bestimmten Dienst am besten ist, wahrscheinlich durch ein beliebiges Rahmenwerk oder ein bestimmtes Verhalten Technologiestack, auf dem der Dienst ausgeführt wird.
Denken Sie daran, dass die Anwendung am Ende des Tages für Benutzer entwickelt wurde und die Trennung der einzelnen Dienste nicht bekannt ist.
Sie verstehen stattdessen die Anwendung und Erfahrung als ein Stück, und dieses Stück wird in erster Linie von der Einheitlichkeit auf oberster Ebene profitieren.
Also, was muss einheitlich sein?
Je größer die Anwendung, desto verwirrender kann die Organisation werden.
Routen (URL-Strukturen) sind einer der wichtigsten Einflussfaktoren für die Funktionsweise einer Webanwendung. Es ist wichtig, dass Ihre Routen einer einheitlichen Struktur folgen. Zum Beispiel beim Anzeigen eines "Benutzerkontos" mit einer URL wie / Benutzer / 5 woher 5 Ist die primäre Ganzzahl-ID des Benutzers, sollten Sie keinen Plural für ein anderes singuläres Objekt verwenden, wie z / widgets / 16. Stattdessen sollte es sein / widget / 16. Dies hilft nicht nur Entwicklern durch Konsistenz, sondern bietet auch Klarheit und Einheitlichkeit für Benutzer. Es ist egal, was Sie für Ihre Routenstruktur wählen, solange sie auf der Ebene der Benutzer konsistent ist.
Dies ist von entscheidender Bedeutung für die interne Entwicklung und noch wichtiger für die Entwicklung von Softwareprodukten / -diensten, wenn eine API der Öffentlichkeit zugänglich gemacht wird. Wenn Ihre API-Aufrufe Unterstriche als Worttrennzeichen enthalten, verwenden Sie an anderer Stelle keinen camelCase-Schlüssel oder einen durch Bindestrich getrennten Schlüssel in Ihrer API. Wenn Sie das Wort "count" für "diese Anzahl von Objekten zurückgeben" verwenden, verwenden Sie nicht etwa "count_per_page", um dasselbe an anderer Stelle in derselben (oder einer verwandten) API zu bedeuten. Dies ist ein schlampiges API-Design. Entwickeln Sie eine Standardsyntax und bleiben Sie dabei. Beachten Sie, dass dies häufig durch ein gut ausgeführtes Routendesign in REST-APIs sichergestellt wird.
Wenn Sie sich in Ihrer Anwendung mit "foo-Widgets" (beliebigen Objekten oder Aktionen) beschäftigen, sollten Sie generell sicherstellen, dass Sie in allen Ihren Anwendungen dieselbe Terminologie verwenden. Obwohl es in Rails üblich ist, das "public" -Verzeichnis zu verwenden, haben Sie die Kontrolle darüber, was sich darin befindet.
Verwenden Sie keinen Ordner "js" für ein Framework und einen Ordner "Scripts" für ein anderes Framework.
Nennen Sie Datenmodelle nicht "orange_items" in einem Framework und "OrangeItems" in einem anderen Framework, es sei denn, die Sprache oder das Framework fordert dies aus funktionalen Gründen explizit auf. Stellen Sie auch dann sicher, dass es ein konsistentes System und eine "Grammatik" gibt, und stellen Sie sicher, dass sich die einzelnen Dienste unterscheiden gut dokumentiert und begründet. Diese Art von Hinweisen und diese Einheitlichkeit werden das Verständnis von Klassifizierungen von Objekten in einer Anwendung erheblich verbessern.
Das Spiegeln von Routen zu Ordnern und Dateien trägt wesentlich dazu bei, eine Anwendung zu organisieren. In Ihren "öffentlichen" oder "statischen" Ordnern befinden sich zum Beispiel Ordner für CSS, JavaScript und Bilder. Durch das Erstellen einer Ordnerstruktur, die Ihren Routen, Ansichten, Controllern oder ähnlichen Strukturen zugeordnet ist, kann das CSS modularisiert bleiben. Sie können dann ein Tool wie CodeKit verwenden, um diese Dateien zu einer einzigen minimierten Datei zu verketten. Natürlich haben Sie auch eine global.css für Regeln, die für die gesamte Anwendung gelten. Ein Beispiel finden Sie unten (.rb ist für Ruby, dies könnte jedoch für jede MVC-Rahmenorganisation gelten).
- root / - app / --- models / ---- foo.rb ---- bar.rb ---- baz / ----- widget.rb --- views / ---- global. html.erb ---- foo.html.erb ---- bar.html.erb ---- baz / ----- widget.html.erb --- controller ---- foo.rb - - bar.rb - public - CSS --- global.css --- foo.css --- bar.css --- baz / ---- widget.css - JS --- global.js - - foo.js --- bar.js --- baz / ---- widget.js - Bilder / --- global / ---- image.jpeg --- foo ---- image.jpeg --- bar ---- image.jpeg --- baz / ---- widget / ----- image.jpeg
Man kann schnell erkennen, dass es nicht schwer ist, bestimmte CSS, JavaScript, Modelle usw. für einen bestimmten Abschnitt der Anwendung zu finden.
Routen (URL-Strukturen) sind einer der wichtigsten Einflussfaktoren für die Funktionsweise einer Webanwendung.
Am besten denken Sie daran, Ihre Dateien in "Bereiche" Ihrer Site zu unterteilen. Beispielsweise haben Sie möglicherweise eine Anwendung, die einen "Admin" -Bereich und einen "Profil" -Bereich enthält. Sie könnten ein erstellen global.css Datei für die Objekte / Regeln, die für beide Bereiche gelten (einschließlich eines Reset, einiger Typografieregeln, Farben usw.), und erstellen Sie dann bestimmte Dateien, die für die separaten Bereiche der nicht gemeinsam genutzten Inhaltsstilregeln gelten. Wenn ein Entwickler auf einer bestimmten Seite arbeitet, bleibt er in einer oder zwei Dateien und weiß genau, wo er die richtigen Dateien findet.
Eine weitere effektive Möglichkeit, Ihre statischen Dateien zu kontrollieren, besteht darin, sie basierend auf ihren Aktionen zu benennen. Zum Beispiel erstellen Sie eine reset.css, ein typografie.css, ein dimensions.css, ein colors.css, usw. Diese Methode hat Vor-und Nachteile, insbesondere für CSS. Dadurch bleibt Ihr CSS auf Präsentationsregeln fokussiert. Es ist jedoch wahrscheinlich erforderlich, dass Sie die Selektoren für mehrere Dateien wiederholen und sie erneut öffnen, um verschiedene Arten von Stilregeln zu definieren. Die einzige Möglichkeit, dies zu vermeiden, besteht darin, Ihre Klassen / IDs nur nach Stil und nicht nach Semantik wie z. B. zu benennen class = "grüner Text mit fünf Spalten, mittlerer Schatten". Andernfalls tun Sie am Ende so etwas:
Im typografie.css
.Semantic-Widget color: # 232323; Text-Schatten: 1px 1px #fff; Schriftgröße: 1.2em; Zeilenhöhe: 1.1em; Schriftfamilie: serifenlos; Schriftgewicht: 300;
Im dimensions.css
.Semantic-Widget width: 20%; Marge: 0 2,5%; Polsterung: 10px;
Was natürlich nicht so trocken ist wie möglich.
Die Organisation kleinerer Anwendungen (mit weniger dieser "Widget" -Objekte) kann immer noch von der Trennung nach Regeltyp profitieren.
Wenn Sie jedoch über eine Anwendung mit vielen verschiedenen Objekttypen, Anwendungsbereichen usw. verfügen, sollten Sie Ihre CSS-Dateien wahrscheinlich in Bereiche aufteilen (die oben diskutierte Spiegelungsstrategie)..
Das Benennen von JavaScript-Dateien anhand ihrer Funktionen ist etwas praktikabler, jedoch nur, wenn Sie Ereignisauslöser (ein Pub / Sub-Modell) nutzen. Betrachten Sie das folgende Beispiel:
Accentsconagua
$ .getJSON ("/ messages / all.json", Funktion (Daten) // erledige etwas); Möglicherweise möchten Sie in diesem Rückruf einige Dinge tun. Möglicherweise möchten Sie eine Benachrichtigung an den Benutzer senden und eine Liste der Nachrichten aktualisieren. Wenn Sie Ihre Dateien nach Funktionalität getrennt haben, haben Sie möglicherweise eine notifications.js und ein messages.js Datei, die diese bestimmten Funktionen behandelt. Innerhalb des Callbacks für diesen JSON-Ajax-Aufruf würden Sie ein Ereignis für den Rest der Anwendung "veröffentlichen". In Ihren Benachrichtigungs- und Nachrichtendateien können Sie dann das Ereignis "abonnieren" und entsprechend reagieren.
im events.js:
$ .getJSON ("/ messages / all.json", Funktion (Nachrichten) $ ("body"). trigger ("receive_messages", messages);); im messages.js:
$ ("body"). on ("receive_messages", function (event, messages) // Durchlaufen von Nachrichten und Anhängen an eine Liste); im notifications.js
$ ("body"). on ("receive_messages", function (event, messages)) // send_notification kann eine lokale Funktion sein, mit der Sie Benachrichtigungen // an den Benutzer senden können, zusammen mit einem Benachrichtigungstyp eine ganze Zahl; für Beispiel: In diesem // Fall kann "1" einfach bedeuten, die Benachrichtigung als "Erfolg" -Alarm zu formatieren. send_notification ("Erfolgreich empfangene Nachrichten!", 1);); Es gibt einige Dinge, die Sie bei statischen Dateien beachten sollten. In diesem Artikel wird davon ausgegangen, dass Sie Ihre statischen Dateien auf geeignete Weise verketten. Aber was genau ist angebracht??
Warum fragst du das? In erster Linie, um den Browser-Cache zu nutzen.
Durch die schnelle Verkettung können Sie beispielsweise den Cache des Browsers nicht nutzen. Der andere Vorteil dieses Ansatzes besteht darin, nur das zu laden, was Sie benötigen. Wenn Sie über einen gesamten "Admin" -Abschnitt verfügen, den 95% Ihrer Benutzer nie sehen, sollten Sie das CSS für diesen Abschnitt nicht herunterladen müssen.
Entwickeln Sie eine Standardsyntax und bleiben Sie dabei.
Ähnlich wie CSS sollte JavaScript in einem effizienten Umfang verwendet werden.
Die Gewinne sollten immer sorgfältig verwaltet werden. Wenn Ihr Javascript klein genug ist, um die Verkettung in einem einzigen Skript auf alle Fälle zu rechtfertigen, fühlen Sie sich nicht unter Druck gesetzt, modularisiertes JavaScript in Ihr Endprodukt zu laden.
Wie bereits erwähnt, sollten Sie CSS / JS nicht in die statischen Dateien Ihrer globalen Anwendung einfügen, wenn nur eine vernachlässigbare Anzahl von Benutzern auf eine bestimmte Seite fällt. Administrative statische Dateien sollten auch getrennt bleiben. Wenn Ihre Anwendung Benutzerkonten unterstützt, sollten Sie die statischen Dateien für die nicht autorisierte (Marketing-) Seite der Anwendung offenlegen. Nachdem sich ein Benutzer angemeldet hat, hat er sich bereits verpflichtet, an den von Ihrer Anwendung angebotenen Funktionen teilzunehmen. Erste Eindrücke sind alles, und das Laden einer Reihe von nicht verwendeten CSS und JavaScript beeinträchtigt nur die Leistung eines ersten Eindrucks.
Wenn Sie tatsächlich ein Framework verwenden, verwenden Sie die vorhandene Struktur dieses Frameworks. Wenn Ihr Framework nicht über eine vorhandene Struktur oder eine sehr einfache Struktur verfügt (Sinatra und CodeIgniter sind hervorragende Beispiele dafür), sollten Sie die Struktur anderer Komponenten in der Anwendung spiegeln. Wenn Sie von vorne anfangen, werfen Sie einen Blick auf andere Projekte, die in dem von Ihnen verwendeten Rahmen und in anderen Rahmen mit derselben Sprache abgeschlossen wurden. Wenn Sie beispielsweise ein Framework für MVC ausgewählt haben, jedoch keine Standardkonfigurationen für die Platzierung dieser Teile haben, ist es wahrscheinlich, dass eine Benennung vorliegt Konvention die die Schlüsselwörter Model, View und Controller verwendet.
Im Kern geht es bei der Organisation auf Unternehmensebene um vier Hauptpunkte:
