Ruby on Rails Modularisierung mit Packwerk Episode II

Nicolas Nisoria

In der zweiten Folge unserer Ruby on Rails-Modularisierung mit Packwerk werden wir das Konzept der Anwendung als Paket unter die Lupe nehmen.

Bewerbung als Paket

Der Ansatz zur Modularisierung unserer Anwendung besteht darin, die gesamte Anwendung in ein Paket zu verwandeln.

Erstellen Sie die Struktur

Zunächst müssen wir Folgendes erstellen app/packages Ordner, in dem wir alle unsere Pakete ablegen werden. Um unsere Pakete zu isolieren, müssen wir jedes MVC-Konzept in einem Ordner. Die Übernahme der CodeTriage Projekt Als Beispiel sehen wir das folgende Bild.

Wenn wir versuchen, den Server zu starten, wird er die Konstanten nicht finden. Aus diesem Grund müssen wir eine Konfigurationszeile zu unserem anwendung.rb

config.paths.add 'app/packages', glob: '*/{*,*/concerns}', eager_load:true

Jetzt funktioniert die Anwendung, aber sie kann die Ansichten nicht finden, also müssen wir eine weitere Konfigurationszeile zu unserer application_controller.rb

append_view_path(Dir.glob(Rails.root.join('app/packages/*/views')))

Erstellen Sie die Pakete

Unsere Struktur ist fertig, jetzt können wir mit der Erstellung der Pakete beginnen. Dazu müssen wir nur noch einepaket.yml zu jedem Ordner mit der folgenden Konfiguration:

enforce_privacy: falsch
enforce_dependencies: true

datenschutz durchsetzengibt uns die Möglichkeit, alle Konstanten des Pakets zu isolieren und mit einer öffentlichen API zu arbeiten. Um die öffentlichen Konstanten freizulegen, müssen wir die Konstanten z.B. hinzufügen in packages/users/app/public.Für den Moment setzen wir diese Konfiguration auf falsch.

erzwingen_Abhängigkeiten erzwingt die Abhängigkeit eines Pakets und prüft alle Konstantenreferenzen. Wenn eine Abhängigkeit nicht explizit definiert ist, stellt dies eine Verletzung der Grenze dar.

Validierung des Paketsystems

Packwerk ein Kriterium festgelegt, das wir befolgen müssen, um ein gültiges Paketsystem zu haben. Wir können mit der Ausführung von packwerk validieren in unserer Konsole.

Dadurch wird unsere Ordnerstruktur überprüft, Paketkonfigurationund Autoload Path Cache.

Im Moment ist unsere Anwendung nicht gültig und wir müssen die Lastpfade inpackwerk.yml. Dazu müssen wir nur die fehlenden Pfade hinzufügen.

# packwerk.yml

load_paths:
.
.
.

# Benutzer
- app/packages/benutzer/steuerungen
- app/packages/benutzer/models
- app/packages/benutzer/package.yml
- app/packages/benutzer/ansichten

Jetzt sind wir bereit, Grenzverletzungen in unserer Anwendung zu überprüfen. Um Verletzungen zu überprüfen, können wir Folgendes ausführenpackwerk update-deprecations wird dieser Befehl Folgendes erzeugen deprecated_references.yml Datei für jedes Paket. In jeder Datei finden wir den Paketnamen, die Art des Verstoßes und den Dateipfad. Mit all diesen Informationen wissen wir, wo der Verstoß stattfindet, und wir können eine Entscheidung treffen, um ihn zu beheben.

# deprecated_references.yml

.
.
.

app/packages/repos:
  "::Repo":
    Verstöße:
    - Abhängigkeit
    Dateien:
    - app/packages/users/models/user.rb

Anhand des Beispiels werden wir jeden Teil der erzeugten Informationen beschreiben
von Packwerk.

– app/packages/repos - Paket, in dem die konstante Verletzung
gefunden.

– ::Repo - Pfad zu der Datei, die die verletzte Konstante enthält.

– Abhängigkeiten - eine Art der Verletzung, entweder der Abhängigkeit oder der Privatsphäre.

– app/packages/users/models/user.rb - Pfad zu der Datei, die die verletzte Konstante enthält.

Als letzten Schritt in diesem Abschnitt sollten Sie nicht vergessen, die neu generierten Dateipfade zu packwerk.yml und führen Sie die Validierung erneut durch.

Visualisierung von Abhängigkeiten

Mit allen Informationen in package.yml und deprecated_references.ymlkönnen wir dann
einen Graphen der Abhängigkeiten zu visualisieren. Um dies zu tun, müssen wir einen weiteren Edelstein hinzufügen, in diesem Fall werden wir verwenden Pocky.

Laufende Harke pocky:generate erzeugen wir eine Datei namens packwerk.png wo wir unser erstes Diagramm der Abhängigkeiten visualisieren können.

Wenn alle Pakete definiert sind, sieht unser Diagramm wie folgt aus.

Abhängigkeiten existieren bereits, aber das bedeutet nicht, dass sie von Packwerk. An
eine Abhängigkeit zu akzeptieren, müssen wir die Konfiguration der Abhängigkeiten in die paket.yml
in jedem Paket. Wir werden uns konzentrieren auf mail_builders da es sich um ein Paket ohne zirkuläre Abhängigkeiten handelt. Es ist erwähnenswert, dass Packwerk lässt uns keine zirkulären Abhängigkeiten akzeptieren.

# app/packages/mail_builders/package.yml

``ruby
enforce_privacy: falsch
enforce_dependencies: true
Abhängigkeiten:
- app/packages/docs
- app/packages/issues
- app/packages/repos

Nach dem Hinzufügen dieser Konfiguration, Pocky färbt die akzeptierten Abhängigkeiten grün.

Wir können löschen deprecated_references.yml von app/packages/mail_builders und laufen
packwerk update-deprecations wieder. Die Datei wird nicht erneut erstellt, da alle
Verstöße wurden für dieses Paket behoben. Es ist wichtig zu erwähnen, dass selbst wenn wir Graph nicht mit akzeptierten Abhängigkeiten

Ruby on Rails Modularisierung mit Packwerk Abhängigkeiten akzeptieren, funktioniert unsere Anwendung immer noch wie vorher, aber wir haben jetzt mehr
Informationen, um Entscheidungen zu treffen und Änderungen vorzunehmen.

Beseitigung zirkulärer Abhängigkeiten

In unserem früheren Diagramm gab es eine Menge zirkulärer Abhängigkeiten, die irgendwie aufgelöst werden mussten. Wir haben verschiedene Strategien, um das zu erreichen:

- Nichts tun,

- Abhängigkeiten akzeptieren, Pakete zusammenführen,

- Bewegen Code zwischen den Paketen,

- Duplizieren Sie eine Funktionalität,

- Durchführung von Dependency Injection oder Dependency Injection mit Typisierung.

Ein Problem dabei ist, dass wir die Codebasis kennen müssen, um eine angemessene Umstrukturierung durchführen zu können. Ich bin mit der Codebasis dieses Projekts nicht so vertraut, da ich es als Beispiel genommen habe, also werden wir aus praktischen Gründen die erste Strategie wählen, nämlich nichts zu tun. Auch wenn wir den größten Teil des Refactorings vermeiden werden, wollen wir an den Abhängigkeiten in der Wurzel Paket.

Das Wurzelpaket enthält den gesamten Klebstoff aus dem Rails-Frameworkalle Klassen, von denen wir erben und die alle zusammenarbeiten. Um also die zirkulären Abhängigkeiten zu lösen, werden wir in den folgenden Schritten ein neues Paket mit dem Namen rails erstellen:

Verschieben Sie alle Anwendungsdateien und -ordner von der Anwendung nach app/packages/rails.
Erstellen einerpaket.yml für das Paket mit der gleichen Konfiguration wie für die vorherigen Pakete.
Fügen Sie alle neuen Dateipfade zu packwerk.yml.
hinzufügen app/packages/rails als Abhängigkeit von den übrigen Paketen.

Sobald wir das Paket erstellt haben, werden wir feststellen, dass es eine Menge Dateien gibt, die umstrukturiert werden können. Nachdem wir alles in das entsprechende Paket verschoben und akzeptiert haben
Abhängigkeiten haben wir eine neue Struktur und einen saubereren Graphen.

Graph ohne zirkuläre Wurzelabhängigkeiten

Abhängigkeiten aus dem Wurzelpaket entfernen

Jetzt sieht unser Graph viel besser aus. Es wäre toll, wenn wir alle Abhängigkeiten aus dem Wurzelpaket entfernen könnten. Wenn wir die Datei deprecated_references.yml im Wurzelpaket überprüfen, werden wir feststellen, dass die meisten von ihnen aus Test , lib/Aufgaben , db und Konfiguration
Ordner. Um diese Abhängigkeiten aufzulösen, werden wir in jedem Paket einen Testordner anlegen. Mit etwas wie app/packages/users/test. Als nächstes werden wir Folgendes ausschließen lib/Aufgaben , db und Konfigurationneben anderen Ordnern von Packwerk Analyse, da diese Abhängigkeiten für unsere Analyse nicht wirklich wichtig sind und wir keine einfache Möglichkeit haben, sie aufzulösen. Wir fügen Folgendes zu unserer packwerk.yml.

exclude:
- "{bin,node_modules,script,tmp,vendor,lib,db,config,perf_scripts}/**/*"
- "lib/tasks/**/*.rake"

Nach dem Verschieben aller Tests aus dem Wurzelpaket und dem Ausschluss der Ordner aus der Analyse erhalten wir ein neues Diagramm ohne Wurzelabhängigkeiten.

Wie wir sehen können, gibt es immer noch zirkuläre Abhängigkeiten inBenutzer , Repos und docs . Wir haben sie zwar nicht gelöst, aber wir haben jetzt wichtige Informationen zu übermitteln. Wir wissen, dass jeder Team das Änderungen an einem dieser Pakete vornimmt, muss wahrscheinlich auch Änderungen an den Paketen mit der zirkulären Abhängigkeit vornehmen. Andererseits wissen wir, dass ein Team an folgenden Dingen arbeiten kann github_fetchers nur, zu wissen, welche Pakete es gibt
in jedem Moment von den Veränderungen betroffen zu sein.

Das Endergebnis des Projekts finden Sie unter hier.

Nächster Schritt

Als nächsten Schritt könnten Sie in jedem Paket eine konstante Privatsphäre erzwingen und nur die öffentliche API offenlegen, die für andere Pakete zugänglich ist. Sie können einfach konfigurieren, wo Ihre API in paket.yml.

enforce_privacy: wahr
enforce_dependencies: true
public_path: my/custom/path/

Schlussfolgerungen

Packwerk gibt uns viele Informationen über unsere Anwendung und mit diesen Informationen können wir Entscheidungen treffen, um den Arbeitsablauf unserer Teams zu verbessern. Obwohl der Prozess langwierig und mit vielen Konfigurationen verbunden zu sein schien, muss das nicht immer so sein. Wir können damit beginnen, Pakete nur für den neuen Code zu erstellen, der zu unserer Anwendung hinzugefügt wird, und dann schrittweise modularisieren. Jetzt können wir anfangen, über schrittweise Modularisierung zu sprechen. Dieses Konzept wurde von Stephan Hagemann eingeführt. "Wir können zum ersten Mal beschließen, einen Teil des Codes auf ehrgeizige Weise zu modularisieren... Dies ermöglicht uns, ein schrittweise wachsendes Unterstützungssystem für eine bessere Anwendungsstruktur zu schaffen".