Ruby on Rails:n modulaarisointi Packwerk Episode II:n avulla

Hakemus pakettina

Sovelluksen modulaaristaminen tapahtuu muuntamalla koko sovellus paketiksi.

Luo rakenne

Ensin meidän on luotava app/packages kansioon, johon sijoitamme kaikki pakettimme. Jotta voimme eristää pakettimme, meidän täytyy erottaa jokainen MVC-käsite yhdessä kansiossa. Kun CodeTriage projekti Esimerkkinä seuraavanlainen kuva.

Jos yritämme ajaa palvelinta, se ei löydä vakioita. Siksi meidän on lisättävä konfiguraatiorivi tiedostoon application.rb

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

Nyt sovellus toimii, mutta se ei löydä näkymiä, joten meidän on lisättävä toinen rivi konfiguraatioita meidän application_controller.rb

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

Luo paketit

Rakenteemme on valmis, joten nyt voimme aloittaa pakettien luomisen. Sitä varten meidän tarvitsee vain lisätä tiedostopackage.yml jokaiseen kansioon seuraavalla kokoonpanolla:

enforce_privacy: false
enforce_dependencies: true

enforce_privacyantaa meille mahdollisuuden eristää kaikki paketin vakiot ja työskennellä julkisen API:n kanssa. Jotta voimme paljastaa julkiset vakiot, meidän on lisättävä vakiot esimerkiksi seuraaviin kohtiin packages/users/app/public.Toistaiseksi asetamme tämän kokoonpanon arvoon väärä.

enforce_dependencies varmistaa paketin riippuvuuden ja tarkistaa kaikki vakioviittaukset. Jos riippuvuutta ei ole nimenomaisesti määritelty, se on rajan rikkominen.

Pakettijärjestelmän validointi

Packwerk vahvisti kriteerin, jota meidän on noudatettava, jotta meillä olisi pätevä pakettijärjestelmä. Voimme aloittaa packwerk kelpuuttaa konsolissamme.

 Tämä tarkistaa kansiorakenteemme, paketin kokoonpanoja automaattinen polkuvälimuisti.

Juuri nyt sovelluksemme ei ole voimassa, ja meidän on korjattava kuormituspolut osoitteessapackwerk.yml. Tätä varten meidän on vain lisättävä puuttuvat polut.

# packwerk.yml

load_paths:
.
.
.

# Käyttäjät
- app/packages/käyttäjät/ohjaimet
- app/packages/users/mallit
- app/packages/users/package.yml
- app/packages/users/näkymät

Tässä vaiheessa olemme valmiita tarkistamaan rajarikkomukset sovelluksessamme. Rikkomusten tarkistamiseksi voimme suorittaapackwerk update-deprecations , tämä komento luo deprecated_references.yml tiedosto jokaiselle paketille. Jokaisesta tiedostosta löytyy paketin nimi, rikkomustyyppi ja tiedostopolku. Kaikkien näiden tietojen avulla tiedämme, missä rikkomus tapahtuu, ja voimme tehdä päätöksen sen ratkaisemisesta.

# deprecated_references.yml

.
.
.

app/packages/repos:
  "::Repo":
    :
    - dependency
    tiedostot:
    - rb: app/packages/users/models/user.rb: app/packages/users/models/user.rb

Esimerkin avulla kuvaamme kaikki tuotetun tiedon osat.
by Packwerk.

– app/packages/repos  - paketti, jossa vakion rikkominen on
löytyi.

– ::Repo  - polku tiedostoon, joka sisältää rikotun vakion.

– riippuvuus  - jonkinlainen rikkomus, joko riippuvuus tai yksityisyys.

– app/packages/users/models/user.rb  - polku tiedostoon, joka sisältää rikotun vakion.

Viimeisenä askeleena tässä osiossa, älä unohda lisätä uusia luotuja tiedostopolkuja tiedostoon packwerk.yml ja suorita validointi uudelleen.

Riippuvuuden visualisointi

Kun kaikki package.yml:n tiedot ja deprecated_references.ymlvoimme sitten
visualisoida riippuvuuksien kuvaaja. Tätä varten meidän on lisättävä toinen helmi, tässä tapauksessa käytämme seuraavaa komentoa Pocky.

Juokseva harava pocky:generate luomme tiedoston nimeltä packwerk.png jossa voimme visualisoida ensimmäisen riippuvuuskaavion.

Kun kaikki paketit on määritelty, kuvaajamme näyttää tältä.

riippuvuudet ovat jo olemassa, mutta se ei tarkoita, että ne hyväksytään Packwerk. Osoitteeseen
hyväksyä riippuvuuden, meidän on lisättävä riippuvuuksien määritys tiedostoon package.yml
jokaisessa pakkauksessa. Keskitymme mail_builders koska se on paketti ilman kiertävää riippuvuutta. On syytä mainita, että Packwerk ei anna meidän hyväksyä pyöreitä riippuvuuksia.

# app/packages/mail_builders/package.yml

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

Kun olet lisännyt tämän kokoonpanon, Pocky värittää hyväksytyt riippuvuudet vihreällä.

Voimme poistaa deprecated_references.yml osoitteesta app/packages/mail_builders ja ajaa
packwerk update-deprecations jälleen. Tiedostoa ei luoda uudestaan, koska kaikki
rikkomukset on korjattu tätä pakettia varten. On tärkeää mainita, että vaikka emme Graph hyväksyisikään hyväksyttyjä riippuvuuksia.

Ruby on Rails:n modulaarisuus Packwerkin avulla hyväksyä riippuvuuksia, sovelluksemme toimii edelleen kuten ennenkin, mutta nyt meillä on enemmän riippuvuuksia.
tietoa päätösten tekemiseen ja muokkaamiseen.

Poista ympäripyöreät riippuvuudet

Edellisessä kuvaajassamme oli paljon ympyrämäisiä riippuvuuksia, jotka oli ratkaistava jotenkin. Meillä on siihen erilaisia strategioita:

- Älä tee mitään,

- Hyväksy riippuvuudet, Yhdistä paketit,

- Siirrä koodi pakettien välillä,

- Toiminnon kopiointi, 

- Suorita riippuvuusinjektio tai riippuvuusinjektio tyypittelyn avulla.

Yksi ongelma tässä on se, että voidaksemme tehdä kunnollisen refaktoroinnin meidän on tunnettava koodipohja. En tunne tämän projektin koodipohjaa kovin hyvin, koska otin sen esimerkkinä, joten käytännön syistä käytämme ensimmäistä strategiaa, emme tee mitään. Vaikka vältämme suurimman osan refaktoroinnista, haluamme työskennellä riippuvuuksien parissa vuonna root paketti.

Juuripaketti sisältää kaikki liimaukset paketin Rails-kehys, kaikki luokat, joista periydymme ja jotka saadaan toimimaan yhdessä. Jotta voimme ratkaista kiertävät riippuvuudet, luomme uuden paketin nimeltä rails seuraavien vaiheiden avulla:

1. Siirrä kaikki sovelluksen_ tiedostot ja kansiot sovelluksesta osoitteeseen app/packages/rails.
2. Luopackage.yml paketille, jolla on sama kokoonpano kuin edellisillä paketeilla.
3. Lisää kaikki uudet tiedostopolut osoitteeseen packwerk.yml.
4. Lisää app/packages/rails muiden pakettien riippuvuussuhteena.

Kun olemme luoneet paketin, alamme huomata paljon tiedostoja, jotka voidaan järjestää uudelleen. Kun kaikki on siirretty vastaavaan pakettiin ja hyväksyttyjen
riippuvuuksia, meillä on uusi rakenne ja puhtaampi graafi.

Poista riippuvuudet juuripaketista

Nyt kuvaajamme näyttää paljon paremmalta. Olisi hienoa, jos voisimme poistaa kaikki riippuvuudet juuripaketista. Jos tarkistamme deprecated_references.yml-tiedoston juuripaketista, huomaamme, että suurin osa niistä on peräisin tiedostosta testi , lib/tasks , db ja config
kansio. Näiden riippuvuuksien ratkaisemiseksi luomme testikansiot jokaiseen pakettiin. Jotain sellaista kuin app/packages/users/test. Seuraavaksi jätämme pois lib/tasks , db ja configmuiden kansioiden joukossa osoitteesta Packwerk analyysi, koska nämä riippuvuudet eivät ole todella tärkeitä analyysimme kannalta, eikä meillä ole helppoa tapaa ratkaista niitä. Lisäämme seuraavat asiat packwerk.yml.

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

Kun kaikki testit on siirretty juuripaketista ja kansiot on jätetty analyysin ulkopuolelle, meillä on uusi kuvaaja ilman juuririippuvuuksia.

Kuten näemme, meillä on edelleen ympyrämäisiä riippuvuuksia osoitteessakäyttäjät , repot ja docs . Vaikka emme ratkaisseet niitä, meillä on nyt tärkeää tietoa välitettävänä. Tiedämme, että jokainen joukkue joka tekee muutoksia johonkin näistä paketeista, joutuu todennäköisesti tekemään muutoksia paketteihin, joilla on kiertävä riippuvuus. Toisaalta tiedämme, että tiimi voi työskennellä seuraavilla aloilla github_fetchers yksinomaan, tietäen mitä paketteja ovat
joka hetki tapahtuvien muutosten vaikutuksesta.

Löydät projektin lopputuloksen täällä.

Seuraava vaihe

Seuraavana askeleena voisit varmistaa jatkuvan yksityisyyden suojan jokaisessa paketissa ja paljastaa vain julkisen API:n, johon muut paketit pääsevät käsiksi. Voit helposti määrittää, minne API sijoitetaan pakettien package.yml.

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

Päätelmät

Packwerk antaa meille paljon tietoa sovelluksestamme, ja näiden tietojen avulla voimme tehdä päätöksiä tiimien työnkulun parantamiseksi. Vaikka prosessi vaikutti pitkältä ja paljon konfiguraatioita sisältävältä, sen ei tarvitse olla aina samanlaista. Voimme aloittaa pakettien luomisen vain sovellukseemme lisättyä uutta koodia varten ja modulaarisoida sitten vähitellen. Nyt voimme siis alkaa puhua asteittaisesta modulaarisoinnista. Stephan Hagemann esitteli tämän käsitteen. "Voimme ensimmäistä kertaa päättää aloittaa osan koodin modulaarisoinnin tavoitteellisesti... Näin voimme luoda asteittain laajenevan tukijärjestelmän kohti parempaa sovellusrakennetta".

Lähteet

1. Asteittainen modulaarisointi Ruby on Rails:lle - Stephan Hagemann
2. Modulaarisuuden pakottaminen Rails-sovelluksissa Packwerkin avulla
3. Packwerk Github
4. Artikkelin lähdekoodi

Lue lisää

GraphQL Ruby. Entä suorituskyky?

Kiskot ja muut liikennevälineet

Rails-kehitys TMUX, Vim, Fzf + Ripgrep -ohjelmilla