Ruby on Rails-modularisering med Packwerk Episode II

Ansøgning som en pakke

Tilgangen til at modularisere vores applikation består i at konvertere hele applikationen til en pakke.

Skab strukturen

Først skal vi oprette app/pakker mappe, hvor vi vil placere alle vores pakker. For at isolere vores pakker er vi nødt til at adskille hver MVC-konceptet i én mappe. At tage KodeTriage projekt Som eksempel får vi noget, der ligner det følgende billede.

Hvis vi prøver at køre serveren, vil den ikke kunne finde konstanterne. Derfor er vi nødt til at tilføje en konfigurationslinje til vores applikation.rb

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

Nu fungerer programmet, men det kan ikke finde visningerne, så vi er nødt til at tilføje endnu en konfigurationslinje til vores application_controller.rb

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

Opret pakkerne

Vores struktur er klar, så nu kan vi begynde at oprette pakkerne. For at gøre det behøver vi kun at tilføje enpakke.yml til hver mappe med følgende konfiguration:

håndhæv_privatliv: false
enforce_dependencies: true

håndhæve_privatlivgiver os mulighed for at isolere alle pakkens konstanter og arbejde med et offentligt API. For at eksponere de offentlige konstanter skal vi tilføje konstanterne i f.eks. pakker/brugere/app/public.Indtil videre sætter vi denne konfiguration til falsk.

håndhæve_afhængigheder vil håndhæve afhængigheden af en pakke og tjekke for alle konstante referencer. Hvis en afhængighed ikke er eksplicit defineret, vil det være en overtrædelse af grænsen.

Validering af pakkesystemet

Packwerk etableret et kriterium, som vi skal følge for at have et gyldigt pakkesystem. Vi kan begynde at køre packwerk valideret i vores konsol.

 Dette vil tjekke vores mappestruktur, Pakkekonfigurationog autoload path cache.

Lige nu er vores applikation ikke gyldig, og vi er nødt til at rette belastningsstierne ipackwerk.yml. For at gøre dette behøver vi kun at tilføje de manglende stier.

# packwerk.yml

load_paths:
.
.
.

#-brugere
- app/packages/users/controllers
- app/pakker/brugere/modeller
- app/packages/users/package.yml
- app/pakker/brugere/visninger

Nu er vi klar til at tjekke grænseoverskridelser i vores applikation. For at tjekke overtrædelser kan vi kørepackwerk opdaterer afskrivninger vil denne kommando generere forældede_referencer.yml fil for hver pakke. I hver fil finder vi pakkenavn, type af overtrædelse og filsti. Med alle disse oplysninger ved vi, hvor overtrædelsen sker, og vi kan træffe en beslutning om at løse den.

# deprecated_references.yml

.
.
.

app/packages/repos:
  "::Repo":
    overtrædelser:
    - afhængighed
    filer:
    - app/packages/users/models/user.rb

Med udgangspunkt i eksemplet vil vi beskrive alle dele af den genererede information
af Packwerk.

– app/pakker/repos  - pakke, hvor den konstante overtrædelse er
fundet.

– ::Repo  - stien til den fil, der indeholder den krænkede konstant.

– Afhængighed  - en form for krænkelse, enten afhængighed eller privatliv.

– app/packages/users/models/user.rb  - stien til den fil, der indeholder den krænkede konstant.

Som et sidste trin i dette afsnit skal du ikke glemme at tilføje de nye genererede filstier til packwerk.yml og kør valideringer igen.

Visualisering af afhængighed

Med alle oplysningerne i package.yml og forældede_referencer.ymlVi kan så
visualisere en graf over afhængigheder. For at gøre det skal vi tilføje en anden perle, i dette tilfælde vil vi bruge Pocky.

Løbende rive pocky:generere vil vi generere en fil, der hedder packwerk.png hvor vi kan visualisere vores første graf over afhængigheder.

Når alle pakkerne er defineret, vil vores graf se sådan ud.

afhængigheder findes allerede, men det betyder ikke, at de accepteres af Packwerk. Til
acceptere en afhængighed, skal vi tilføje afhængighedskonfigurationen til pakke.yml
i hver eneste pakke. Vi vil fokusere på mail_builders da det er en pakke uden cirkulær afhængighed. Det er værd at nævne, at Packwerk vil ikke lade os acceptere cirkulære afhængigheder.

# app/packages/mail_builders/package.yml

```ruby
enforce_privacy: false
enforce_dependencies: true
afhængigheder:
- app/packages/docs
- app/packages/issues
- app/pakker/repos

Når du har tilføjet denne konfiguration, Pocky vil farve de accepterede afhængigheder med grønt.

Vi kan slette forældede_referencer.yml fra app/packages/mail_builders og køre
packwerk opdaterer afskrivninger igen. Filen vil ikke blive genereret igen, da alle
overtrædelser blev rettet for denne pakke. Det er vigtigt at nævne, at selv om vi ikke bruger Graph med accepterede afhængigheder

Ruby on Rails-modularisering med Packwerk acceptere afhængigheder, vil vores program stadig fungere som før, men nu har vi flere
information til at træffe beslutninger og refaktorere.

Fjern cirkulære afhængigheder

I vores tidligere graf havde vi en masse cirkulære afhængigheder, som skulle løses på en eller anden måde. Vi har forskellige strategier til at gøre det:

- Gør ingenting,

- Accepter afhængigheder, flet pakker,

- Flyt dig Kode mellem pakkerne,

- Dupliker en funktionalitet, 

- Udfør dependency injection eller dependency injection med typing.

Et problem her er, at vi skal kende kodebasen for at kunne lave en ordentlig refaktorering. Jeg er ikke så bekendt med kodebasen i dette projekt, da jeg tog det som et eksempel, så af praktiske grunde vil vi vælge den første strategi, nemlig ikke at gøre noget. Selv om vi undgår det meste af refaktoriseringen, vil vi gerne arbejde med afhængighederne i rod pakke.

Rodpakken indeholder al limen fra Rails-rammeværkalle de klasser, vi arver fra, og få dem til at arbejde sammen. Så for at løse de cirkulære afhængigheder skal vi oprette en ny pakke, der hedder rails, i de følgende trin:

1. Flyt alle application_-filer og -mapper fra appen til app/pakker/rails.
2. Opret enpakke.yml for pakken med samme konfiguration som de tidligere pakker.
3. Tilføj alle de nye filstier til packwerk.yml.
4. Tilføj app/pakker/rails som en afhængighed af resten af pakkerne.

Når vi har oprettet pakken, vil vi begynde at lægge mærke til en masse filer, der kan omstruktureres. Efter at have flyttet alt til den tilsvarende pakke og accepteret
afhængigheder får vi en ny struktur og en renere graf.

Fjern afhængigheder fra rodpakken

Nu ser vores graf meget bedre ud, og det ville være dejligt, hvis vi kunne fjerne alle afhængighederne fra rodpakken. Hvis vi tjekker deprecated_references.yml i rodpakken, vil vi bemærke, at de fleste af dem er fra test , lib/opgaver , db og konfiguration
mappe. For at løse disse afhængigheder vil vi oprette en testmappe i hver pakke. At have noget som app/pakker/brugere/test. Dernæst vil vi udelukke lib/opgaver , db og konfigurationblandt andre mapper fra Packwerk analyse, da disse afhængigheder ikke er særlig vigtige i vores analyse, og vi ikke har en nem måde at løse dem på. Vi vil tilføje følgende til vores packwerk.yml.

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

Når vi har flyttet alle testene fra rodpakken og udelukket mapperne fra analysen, får vi en ny graf uden rodafhængigheder.

Som vi kan se, har vi stadig cirkulære afhængigheder ibrugere , Repos og Dokumenter . Selv om vi ikke løste dem, har vi vigtige oplysninger at videregive nu. Vi ved, at alle hold der foretager ændringer i en af disse pakker, bliver sandsynligvis nødt til at foretage ændringer i pakkerne med den cirkulære afhængighed. På den anden side ved vi, at et team kan arbejde på github_fetchers udelukkende at vide, hvilke pakker der er
bliver påvirket af forandringerne i hvert øjeblik.

Du kan finde det endelige resultat af projektet her.

Næste skridt

Som et næste skridt kan du håndhæve konstant privatliv i hver pakke og kun eksponere det offentlige API, som vil være tilgængeligt fra andre pakker. Du kan nemt konfigurere, hvor din API skal placeres i pakke.yml.

håndhæv_privatliv: true
enforce_dependencies: true
public_path: min/custom/path/

Konklusioner

Packwerk giver os en masse information om vores applikation, og med den information kan vi træffe beslutninger om at forbedre arbejdsgangen for vores teams. Selvom processen så ud til at være lang og med mange konfigurationer, behøver det ikke altid at være sådan. Vi kan begynde med kun at oprette pakker til den nye kode, der tilføjes til vores applikation, og derefter modulere gradvist. Så nu kan vi begynde at tale om gradvis modularisering - det er et koncept, som Stephan Hagemann har introduceret. "Vi kan for første gang beslutte at begynde at modularisere en del af koden på en ambitiøs måde ... Dette giver os mulighed for at skabe et gradvist voksende støttesystem mod en bedre applikationsstruktur".

Kilder

1. Gradvis modularisering til Ruby on Rails - Stephan Hagemann
2. Håndhævelse af modularitet i Rails-apps med Packwerk
3. Packwerk Github
4. Kildekode til artiklen

Læs mere

GraphQL Ruby. Hvad med performance?

Skinner og andre transportmidler

Rails-udvikling med TMUX, Vim, Fzf + Ripgrep