Ruby on Rails modulācija ar Packwerk Episode II

Pieteikums kā pakete

Mūsu lietojumprogrammas modulēšanas pieeja ir pārvērst visu lietojumprogrammu paketē.

Izveidot struktūru

Vispirms mums ir jāizveido app/packages mapi, kurā mēs izvietosim visas mūsu paketes. Lai izolētu mūsu paketes, mums ir jāatdala katra MVC koncepcija vienā mapē. Ņemot CodeTriage projekts kā piemēru mēs redzēsim kaut ko līdzīgu šādam attēlam.

Ja mēģināsim palaist serveri, tas nespēs atrast konstantes. Tāpēc mums ir jāpievieno konfigurācijas rinda mūsu application.rb

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

Tagad lietojumprogramma darbojas, bet tā nevar atrast skatus, tāpēc mums ir nepieciešams pievienot vēl vienu konfigurācijas rindu mūsu application_controller.rb

pievienot_skatījuma_ceļu(Dir.glob(Sliedes.root.join('app/packages/*/views'))))

Izveidot paketes

Struktūra ir gatava, tāpēc tagad varam sākt pakotņu izveidi. Lai to izdarītu, mums tikai jāpievienopackage.yml katrā mapē ar šādu konfigurāciju:

enforce_privacy: false
enforce_dependencies: true

enforce_privacysniedz mums iespēja izolēt visas paketes konstantes un strādāt ar publisku API. Lai atklātu publiskās konstantes, mums ir jāpievieno konstantes, piemēram. packages/users/app/public.Pagaidām mēs šo konfigurāciju iestatīsim uz viltus.

enforce_dependencies nodrošinās paketes atkarību un pārbaudīs visas konstantas atsauces. Ja atkarība nav skaidri definēta, tas būs robežas pārkāpums.

Iepakojumu sistēmas apstiprināšana

Packwerk noteica kritēriju, kas mums jāievēro, lai izveidotu derīgu pakešu sistēmu. Mēs varam sākt palaist packwerk apstiprināt mūsu konsolē.

 Tādējādi tiks pārbaudīta mūsu mapju struktūra, paketes konfigurācija, un automātiskā ceļā ielādēt kešatmiņu.

Šobrīd mūsu lietojumprogramma nav derīga, un mums ir jālabo slodzes ceļi programmā.packwerk.yml. Lai to izdarītu, mums tikai jāpievieno trūkstošie ceļi.

# packwerk.yml

load_paths:
.
.
.

# Lietotāji
- app/packages/users/controllers
- app/packages/users/models
- app/packages/users/package.yml
- app/packages/users/views

Šobrīd esam gatavi pārbaudīt robežu pārkāpumus mūsu lietojumprogrammā. Lai pārbaudītu pārkāpumus, mēs varam palaistpackwerk update-deprecations , šī komanda ģenerēs deprecated_references.yml failu katrai paketei. Katrā failā mēs atradīsim paketes nosaukumu, pārkāpuma veidu un faila ceļu. Izmantojot šo informāciju, mēs zinām, kur notiek pārkāpums, un varam pieņemt lēmumu par tā novēršanu.

# deprecated_references.yml

.
.
.

app/packages/repos:
  "::Repo":
    :: "Repo:": pārkāpumi:
    - atkarība
    faili:
    - app/packages/users/models/user.rb

Izmantojot piemēru, mēs aprakstīsim katru ģenerētās informācijas daļu.
līdz Packwerk.

- app/packages/repos  - pakete, kurā konstants pārkāpums ir
atrasts.

- ::Repo  - ceļš līdz datnei, kurā atrodas pārkāptā konstante.

- atkarība  - pārkāpuma veids - vai nu atkarība, vai privātums.

- app/packages/users/models/user.rb  - ceļš līdz datnei, kurā atrodas pārkāptā konstante.

Kā pēdējo soli šajā sadaļā neaizmirstiet pievienot jaunradītos failu ceļus pie packwerk.yml un vēlreiz palaidiet validāciju.

Atkarību vizualizācija

Izmantojot visu informāciju package.yml un deprecated_references.ymltad mēs varam
vizualizēt atkarību grafiku. Lai to izdarītu, mums ir nepieciešams pievienot vēl vienu gem, šajā gadījumā mēs izmantosim Pocky.

Sliežu grābeklis pocky:ģenerēt mēs izveidosim failu ar nosaukumu packwerk.png kur mēs varam vizualizēt mūsu pirmo atkarību grafiku.

Kad visas paketes ir definētas, mūsu grafiks izskatās šādi.

atkarības jau pastāv, bet tas nenozīmē, ka tās ir akceptētas ar Packwerk. Uz
pieņemt atkarību, mums ir nepieciešams pievienot atkarību konfigurāciju, lai package.yml
katrā iepakojumā. Mēs koncentrēsimies uz mail_builders jo tā ir pakete bez apļveida atkarības. Ir vērts pieminēt, ka Packwerk neļauj mums pieņemt apļveida atkarības.

# app/packages/mail_builders/package.yml

````ruby
enforce_privacy: false
enforce_dependencies: true
dependencies:
- app/packages/docs
- app/packages/issues
- app/packages/repos

Pēc šīs konfigurācijas pievienošanas, Pocky akceptētās atkarības tiks iekrāsotas zaļā krāsā.

Mēs varam dzēst deprecated_references.yml no app/packages/mail_builders un palaist
packwerk update-deprecations atkal. Faili netiks ģenerēts vēlreiz, jo visi
šajā paketē tika novērsti pārkāpumi. Ir svarīgi pieminēt, ka, pat ja mēs ne Grafiks ar pieņemtajām atkarībām

Rubīns on Rails modulēšana ar Packwerk pieņemt atkarības, mūsu lietojumprogramma joprojām darbosies kā iepriekš, bet tagad mums ir vairāk
informāciju, lai pieņemtu lēmumus un veiktu izmaiņas.

Dzēst apļveida atkarības

Mūsu iepriekšējā grafikā bija daudz apļveida atkarību, kuras vajadzēja kaut kā atrisināt. Mums ir dažādas stratēģijas, kā to izdarīt:

- Nedariet neko,

- Pieņemt atkarības, Apvienot paketes,

- Pārvietot kods starp iepakojumiem,

- Funkcijas dublēšana, 

- Veiciet atkarību iesmidzināšanu vai atkarību iesmidzināšanu ar rakstīšanu.

Viena no problēmām ir tā, ka, lai veiktu pareizu refaktorizāciju, mums ir jāpārzina kodbāze. Es neesmu tik labi iepazinies ar šī projekta kodu bāzi, jo to izmantoju kā piemēru, tāpēc praktisku apsvērumu dēļ mēs izvēlēsimies pirmo stratēģiju - nedarīt neko. Pat ja mēs izvairīsimies no lielākās daļas refaktorizācijas, mēs vēlamies strādāt ar atkarībām, kas atrodas saknes iepakojums.

Saknes pakete satur visu līme no Rails ietvars, visas klases, no kurām mantojam, un panākt, lai tās darbojas kopā. Tātad, lai atrisinātu cirkulāro atkarību problēmu, mēs izveidosim jaunu pakotni ar nosaukumu rails (sliedes), veicot šādus soļus:

1. Pārvietot visus lietojumprogrammas_ failus un mapes no lietotnes uz app/packages/rails.
2. Izveidotpackage.yml paketei ar tādu pašu konfigurāciju kā iepriekšējām pakotnēm.
3. Pievienojiet visus jaunos failu ceļus packwerk.yml.
4. Pievienot app/packages/rails kā atkarība no pārējām pakotnēm.

Kad izveidosim pakotni, sāksim pamanīt daudz failu, kurus var pārstrukturēt. Pēc tam, kad viss ir pārvietots uz atbilstošo pakotni un pieņemts
atkarības mums būs jauna struktūra un tīrāks grafiks.

Atkarību noņemšana no saknes pakotnes

Tagad mūsu grafiks izskatās daudz labāk, būtu lieliski, ja mēs varētu noņemt visas atkarības no saknes paketes. Ja mēs pārbaudīsim deprecated_references.yml saknes paketē, mēs pamanīsim, ka lielākā daļa no tām ir no tests , lib/tasks , db un konfigurators
mape. Lai atrisinātu šīs atkarības, mēs katrā paketē izveidosim testa mapi. Izmantojot kaut ko līdzīgu app/packages/users/test. Tālāk mēs izslēgsim lib/tasks , db un konfiguratorsstarp citām mapēm no Packwerk analīzei, jo šīs atkarības mūsu analīzē nav īpaši svarīgas un mums nav vienkārša veida, kā tās atrisināt. Mēs pievienosim mūsu packwerk.yml.

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

Pēc visu testu pārvietošanas no saknes paketes un mapju izslēgšanas no analīzes mums būs jauns grafiks bez saknes atkarībām.

Kā redzams, mums joprojām ir apļveida atkarības, jolietotāji , repozitoriji , un dokumenti . Lai gan mēs tos neatrisinājām, mums tagad ir svarīga informācija, ko nodot tālāk. Mēs zinām, ka katrs komanda kas veic izmaiņas vienā no šīm pakotnēm, iespējams, būs jāveic izmaiņas pakotnēs ar cirkulāro atkarību. No otras puses, mēs zinām, ka team var strādāt ar github_fetchers tikai, zinot, kādas paketes ir
ar katru mirkli tiek ietekmētas pārmaiņas.

Projekta galarezultātu varat atrast šeit.

Nākamais solis

Nākamais solis varētu būt pastāvīga privātuma nodrošināšana katrā pakotnē un publiskot tikai publisko API, kas būs pieejams no citām pakotnēm. Varat viegli konfigurēt, kur jūsu API tiks ievietots package.yml.

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

Secinājumi

Packwerk sniedz mums daudz informācijas par mūsu lietojumprogrammu, un, izmantojot šo informāciju, mēs varam pieņemt lēmumus, lai uzlabotu mūsu team darbplūsmu. Lai gan process šķita garš un ar daudzām konfigurācijām, tam nav jābūt tādam vienmēr. Mēs varam sākt veidot paketes tikai jaunajam kodam, kas pievienots mūsu lietojumprogrammai, un pēc tam pakāpeniski modulēt. Tagad mēs varam sākt runāt par pakāpenisku modulāro modulēšanu, un šo koncepciju ieviesa Stefans Hagemans (Stephan Hagemann). “Mēs pirmo reizi varam pieņemt lēmumu sākt modularizēt daļu koda, lai to padarītu mērķtiecīgu... Tas ļauj mums pakāpeniski izveidot atbalsta sistēmu, kas pakāpeniski paplašinās, lai izveidotu labāku lietojumprogrammas struktūru.”.

Avoti

1. Pakāpeniska modulācija Ruby on Rails - Stephan Hagemann
2. Modularitātes nodrošināšana Rails lietotnēs ar Packwerk
3. Packwerk Github
4. Raksta avota kods

Lasīt vairāk

GraphQL Ruby. Kā ir ar veiktspēju?

Sliedes un citi transporta līdzekļi

Rails attīstība ar TMUX, Vim, Fzf + Ripgrep