Ruby on Rails-modularisering med Packwerk Episode II

Ansökan som ett paket

Tillvägagångssättet för att modularisera vår applikation består i att konvertera hela applikationen till ett paket.

Skapa strukturen

Först måste vi skapa app/paket mappen där vi kommer att placera alla våra paket. För att kunna isolera våra paket måste vi separera varje MVC-konceptet i en och samma mapp. Genom att ta KodTriage projekt som exempel kommer vi att ha något som liknar följande bild.

Om vi försöker köra servern kommer den inte att hitta konstanterna. Det är därför vi måste lägga till en konfigurationsrad i vår applikation.rb

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

Nu fungerar programmet, men det kan inte hitta vyerna, så vi måste lägga till ytterligare en konfigurationsrad i vår applikation_controller.rb

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

Skapa paketen

Vår struktur är klar, så nu kan vi börja skapa paketen. För att göra det behöver vi bara lägga till enpaket.yml till varje mapp med följande konfiguration:

enforce_privacy: false
enforce_dependencies: true

genomdriva_integritetger oss möjlighet att isolera alla konstanter i paketet och arbeta med ett offentligt API. För att exponera de offentliga konstanterna måste vi lägga till konstanterna i till exempel paket/användare/app/public.För närvarande ska vi ställa in denna konfiguration till falska.

genomdriva_beroenden kommer att genomdriva beroendet av ett paket och kontrollera alla konstanta referenser. Om ett beroende inte är explicit definierat kommer det att utgöra en överträdelse av gränsen.

Validering av paketsystemet

Packwerk fastställt ett kriterium som vi måste följa för att ha ett giltigt paketsystem. Vi kan börja köra packwerk giltig i vår konsol.

 Detta kommer att kontrollera vår mappstruktur, paketkonfigurationoch autoload sökvägscache.

Just nu är vår ansökan inte giltig och vi måste åtgärda lastvägarna ipackwerk.yml. För att göra detta behöver vi bara lägga till de saknade vägarna.

# packwerk.yml

ladda_vägar:
.
.
.

# Användare
- app/packages/användare/styrenheter
- app/packages/användare/modeller
- app/packages/användare/package.yml
- app/paket/användare/visningar

Nu är vi redo att kontrollera gränsöverträdelser i vår applikation. För att kontrollera överträdelser kan vi körapackwerk uppdatering-avvecklingar kommer detta kommando att generera avskrivna_referenser.yml fil för varje paket. I varje fil hittar vi paketnamn, typ av överträdelse och filsökväg. Med all denna information vet vi var överträdelsen sker och vi kan fatta ett beslut om att lösa den.

# avskrivna_referenser.yml

.
.
.

app/packages/repos:
  "::Repo":
    överträdelser:
    - Beroende
    filer:
    - app/packages/users/models/user.rb

I exemplet kommer vi att beskriva varje del av den information som genereras
av Packwerk.

– app/paket/repos  - paket där den konstanta överträdelsen är
hittade.

– ::Repo  - sökväg till filen som innehåller den kränkta konstanten.

– Beroende  - en typ av kränkning, antingen beroende eller integritet.

– app/packages/users/models/user.rb  - sökväg till filen som innehåller den kränkta konstanten.

Som ett sista steg i detta avsnitt, glöm inte att lägga till de nya genererade filsökvägarna i packwerk.yml och kör valideringarna igen.

Visualisering av beroenden

Med all information i package.yml och avskrivna_referenser.ymlkan vi sedan
visualisera en graf över beroenden. För att göra det måste vi lägga till en annan gem, i det här fallet kommer vi att använda Pocky.

Löpande räfsa pocky:generera kommer vi att generera en fil som heter packwerk.png där vi kan visualisera vår första graf över beroenden.

Med alla paket definierade kommer vår graf att se ut så här.

beroenden redan finns, men det betyder inte att de accepteras av Packwerk. Till
acceptera ett beroende måste vi lägga till beroendekonfigurationen i paket.yml
i varje paket. Vi kommer att fokusera på post_byggare eftersom det är ett paket utan cirkulära beroenden. Det är värt att nämna att Packwerk låter oss inte acceptera cirkulära beroenden.

# app/packages/mail_builders/package.yml

```ruby
enforce_privacy: false
enforce_dependencies: true
Beroenden:
- app/packages/docs
- app/packages/frågor
- app/packages/repos

När du har lagt till den här konfigurationen, Pocky kommer att färga de accepterade beroendena med grönt.

Vi kan radera avskrivna_referenser.yml från app/packages/mail_builders och kör
packwerk uppdatering-avvecklingar igen. Filen kommer inte att genereras igen eftersom alla
överträdelser åtgärdades för detta paket. Det är viktigt att nämna att även om vi inte Graph med accepterade beroenden

Ruby on Rails-modularisering med Packwerk vår applikation kommer fortfarande att fungera som tidigare, men nu har vi fler
information för att fatta beslut och omarbeta.

Ta bort cirkulära beroenden

I vår tidigare graf hade vi en hel del cirkulära beroenden som behövde lösas på något sätt. Vi har olika strategier för att göra det:

- Gör ingenting,

- Acceptera beroenden, Sammanfoga paket,

- Flytta kod mellan förpackningarna,

- Duplicera en funktionalitet, 

- Utför beroendeinjektion eller beroendeinjektion med typning.

Ett problem här är att för att kunna göra en ordentlig refaktorisering måste vi känna till kodbasen. Jag är inte så bekant med kodbasen i det här projektet eftersom jag tog det som ett exempel, så av praktiska skäl kommer vi att gå med den första strategin, gör ingenting. Även om vi kommer att undvika det mesta av refaktoriseringen vill vi arbeta med beroendena i rot paket.

Rotpaketet innehåller allt lim från Rails ramverkAlla klasser som vi ärver från och får alla att fungera tillsammans. Så för att lösa de cirkulära beroendena kommer vi att skapa ett nytt paket som heter rails inom följande steg:

1. Flytta alla application_-filer och mappar från appen till app/paket/rails.
2. Skapa enpaket.yml för paketet med samma konfiguration som de tidigare paketen.
3. Lägg till alla nya filsökvägar i packwerk.yml.
4. Lägg till app/paket/rails som ett beroende av resten av paketen.

När vi väl har skapat paketet kommer vi att märka att det finns en hel del filer som kan struktureras om. Efter att ha flyttat allt till motsvarande paket och accepterat
beroenden får vi en ny struktur och en renare graf.

Ta bort beroenden från rotpaketet

Nu ser vår graf mycket bättre ut, och det vore bra om vi kunde ta bort alla beroenden från rotpaketet. Om vi kontrollerar deprecated_references.yml i rotpaketet kommer vi att märka att de flesta av dem är från test , lib/arbetsuppgifter , db och konfiguration
mapp. För att lösa dessa beroenden kommer vi att skapa en testmapp i varje paket. Att ha något i stil med app/packages/användare/test. Därefter kommer vi att utesluta lib/arbetsuppgifter , db och konfigurationbland andra mappar från Packwerk eftersom dessa beroenden inte är särskilt viktiga i vår analys och vi inte har något enkelt sätt att lösa dem. Vi kommer att lägga till följande i vår packwerk.yml.

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

När vi har flyttat alla tester från rotpaketet och uteslutit mapparna från analysen får vi en ny graf utan rotberoenden.

Som vi kan se har vi fortfarande cirkulära beroenden ianvändare , Repos , och Dokument . Även om vi inte löste dem har vi viktig information att förmedla nu. Vi vet att varje Team som gör ändringar i ett av dessa paket kommer förmodligen att behöva göra ändringar i de paket som har det cirkulära beroendet. Å andra sidan vet vi att ett team kan arbeta med github_fetchers enbart, att veta vilka paket som är
att påverkas av förändringarna i varje ögonblick.

Du kan hitta slutresultatet av projektet här.

Nästa steg

Som ett nästa steg kan du genomdriva konstant sekretess i varje paket och endast exponera det offentliga API som kommer att vara tillgängligt från andra paket. Du kan enkelt konfigurera var ditt API ska placeras i paket.yml.

genomdriva_integritet: sant
enforce_dependencies: true
public_path: min/custom/path/

Slutsatser

Packwerk ger oss mycket information om vår applikation och med den informationen kan vi fatta beslut för att förbättra arbetsflödet för våra team. Även om processen verkade vara lång och med många konfigurationer, behöver det inte alltid vara så. Vi kan börja med att skapa paket endast för den nya kod som läggs till i vår applikation och sedan modularisera gradvis. Så nu kan vi börja prata om gradvis modularisering, det här är ett koncept som introducerades av Stephan Hagemann "Vi kan för första gången bestämma oss för att börja modularisera en del av koden på ett ambitiöst sätt ... Detta gör att vi kan skapa ett gradvis expanderande stödsystem mot en bättre applikationsstruktur".

Källor

1. Gradvis modularisering för Ruby on Rails - Stephan Hagemann
2. Genomdriva modularitet i Rails-appar med Packwerk
3. Packwerk Github
4. Källkod för artikeln

Läs mer om

GraphQL Ruby. Hur är det med prestanda?

Räls och andra transportmedel

Rails-utveckling med TMUX, Vim, Fzf + Ripgrep