Ruby on Rails modulariseerimine Packwerk Episode II abil

Taotlus kui pakett

Meie rakenduse moduleerimine seisneb selles, et kogu rakendus muudetakse paketiks.

Loo struktuur

Kõigepealt peame looma app/packages kausta, kuhu me paigutame kõik oma paketid. Selleks, et meie pakette eraldada, peame eraldama iga paketi MVC kontseptsioon ühes kaustas. Võttes CodeTriage projekt näiteks on meil midagi sellist nagu järgmine pilt.

Kui me üritame serverit käivitada, ei leia see konstante. Seetõttu peame lisama rea konfiguratsiooni meie application.rb

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

Nüüd töötab rakendus, kuid ei leia vaateid, seega peame lisama veel ühe rea konfiguratsiooni meie application_controller.rb

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

Luua paketid

Meie struktuur on valmis, nii et nüüd saame alustada pakettide loomist. Selleks peame ainult lisamapackage.yml igasse kausta järgmise konfiguratsiooniga:

enforce_privacy: false
enforce_dependencies: true

enforce_privacyannab meile võimaluse isoleerida kõik paketi konstandid ja töötada avaliku API-ga. Avalike konstandide eksponeerimiseks peame lisama konstandid näiteks järgmiselt packages/users/app/public.Hetkel seame selle konfiguratsiooni väärtuseks vale.

enforce_dependencies kontrollib paketi sõltuvust ja kontrollib kõiki konstandiviiteid. Kui sõltuvus ei ole selgesõnaliselt määratletud, siis on see piiride rikkumine.

Pakendisüsteemi valideerimine

Packwerk kehtestas kriteeriumi, mida peame järgima, et meil oleks kehtiv paketisüsteem. Me võime hakata käivitama packwerk valideerib meie konsoolis.

 See kontrollib meie kaustade struktuuri, paketi konfiguratsioon, ja autoload path cache.

Praegu ei kehti meie rakendus ja me peame parandama koormusrajad aastalpackwerk.yml. Selleks tuleb meil lisada vaid puuduolevad teed.

# packwerk.yml

load_paths:
.
.
.

# Kasutajad
- app/packages/users/controllers
- app/packages/users/models
- app/packages/users/package.yml
- app/packages/users/views

Siinkohal oleme valmis kontrollima piiride rikkumisi meie rakenduses. Rikkumiste kontrollimiseks võime käivitadapackwerk update-deprecations , see käsk genereerib deprecated_references.yml faili iga paketi jaoks. Igast failist leiame paketi nime, rikkumise tüübi ja faili tee. Kogu selle teabe põhjal teame, kus rikkumine toimub, ja saame teha otsuse selle lahendamiseks.

# deprecated_references.yml

.
.
.

app/packages/repos:
  "::Repo":
    :
    - dependentsus
    failid:
    - app/packages/users/models/user.rb

Võttes näite, kirjeldame iga osa genereeritud teabest
poolt Packwerk.

– app/packages/repos  - pakett, kus konstantne rikkumine on
leitud.

– ::Repo  - tee faili, mis sisaldab rikutud konstanti.

– sõltuvus  - mingi rikkumine, kas sõltuvus või eraelu puutumatus.

– app/packages/users/models/user.rb  - tee faili, mis sisaldab rikutud konstanti.

Viimase sammuna selles jaotises ärge unustage lisada uued genereeritud failipolud aadressile packwerk.yml ja käivitage valideerimine uuesti.

Sõltuvuse visualiseerimine

Kõik andmed package.yml ja deprecated_references.ymlsaame siis
visualiseerida sõltuvuste graafikut. Selleks peame lisama veel ühe pärli, sel juhul kasutame me Pocky.

Jooksvad hargad pocky:generate genereerime faili nimega packwerk.png kus me saame visualiseerida oma esimest sõltuvuste graafikut.

Kui kõik paketid on määratletud, näeb meie graafik välja selline.

sõltuvused on juba olemas, kuid see ei tähenda, et neid aktsepteerib Packwerk. Et
aktsepteerida sõltuvust peame lisama sõltuvuste konfiguratsioonile package.yml
igas pakendis. Me keskendume mail_builders kuna tegemist on paketiga, millel ei ole ümmargust sõltuvust. Tasub mainida, et Packwerk ei lase meil aktsepteerida ringikujulisi sõltuvusi.

# app/packages/mail_builders/package.yml

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

Pärast selle konfiguratsiooni lisamist, Pocky värvib aktsepteeritud sõltuvused roheliseks.

Me võime kustutada deprecated_references.yml aadressilt app/packages/mail_builders ja käivitada
packwerk update-deprecations uuesti. Faili ei genereerita uuesti, kuna kõik
selle paketi puhul parandati rikkumised. Oluline on mainida, et isegi kui me ei graafi aktsepteeritud sõltuvustega

Ruby on Rails moduleerimine koos Packwerkiga aktsepteerida sõltuvusi, töötab meie rakendus endiselt nagu varem, kuid nüüd on meil rohkem
teavet otsuste tegemiseks ja ümbertöötlemiseks.

Eemaldage ringikujulised sõltuvused

Meie eelmises graafikus oli palju ringikujulisi sõltuvusi, mis tuli kuidagi lahendada. Meil on selleks erinevaid strateegiaid:

- Ärge tehke midagi,

- Võtke sõltuvused vastu, ühendage pakette,

- Liikumine kood pakettide vahel,

- Funktsionaalsuse dubleerimine, 

- Tehke sõltuvuse süstimine või sõltuvuse süstimine koos tüübistamisega.

Üks probleem on see, et korraliku refaktooringu tegemiseks peame tundma koodibaasi. Ma ei ole selle projekti koodibaasiga nii hästi kursis, kuna võtsin selle näitena, seega praktilistel põhjustel läheme esimese strateegiaga, ei tee midagi. Isegi kui me väldime enamiku refaktooringutest, tahame töötada sõltuvuste osas juur pakett.

Juurpakett sisaldab kõiki liimi alates Rails raamistik, kõik klassid, millest me pärime, ja paneme kõik koos tööle. Seega, selleks, et lahendada ümmargused sõltuvused, loome järgmise sammu raames uue paketi nimega rails:

1. Liigutage kõik rakenduse_ failid ja kaustad rakendusest aadressile app/packages/rails.
2. Loopackage.yml paketi jaoks, mille konfiguratsioon on sama, mis eelmistel pakettidel.
3. Lisage kõik uued failipolud aadressile packwerk.yml.
4. Lisa app/packages/rails sõltuvusena ülejäänud pakettidest.

Kui me loome paketi, hakkame märkama palju faile, mida saab ümber struktureerida. Pärast seda, kui kõik on viidud vastavasse paketti ja aktsepteeritud
sõltuvused on meil uus struktuur ja puhtam graaf.

Eemaldage sõltuvused juurpaketi peapaketist

Nüüd meie graafik näeb palju parem välja oleks hea, kui me saame eemaldada kõik sõltuvused juurpakett. Kui me vaatame deprecated_references.yml faili root paketis, siis märkame, et enamik neist on pärit test , lib/tasks , db ja config
kaust. Nende sõltuvuste lahendamiseks loome iga paketi sees testkausta. Võttes midagi sellist nagu app/packages/users/test. Järgmisena jätame välja lib/tasks , db ja configteiste kaustade hulgas Packwerk analüüsi, kuna need sõltuvused ei ole meie analüüsis tegelikult olulised ja meil ei ole lihtsat viisi nende lahendamiseks. Me lisame oma packwerk.yml.

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

Pärast kõigi testide teisaldamist juurpaketi alt ja kaustade väljajätmist analüüsist saame uue graafiku ilma juursõltuvusteta.

Nagu näeme, on meil ikka veel ringikujulisi sõltuvusikasutajad , repos ja docs . Kuigi me ei lahendanud neid, on meil nüüd oluline teave, mida edasi anda. Me teame, et iga meeskond mis teeb muudatusi ühes neist pakettidest, peab tõenäoliselt tegema muudatusi ka pakettides, mille puhul on tegemist ringikujulise sõltuvusega. Teisest küljest teame, et meeskond võib töötada github_fetchers ainult, teades, millised paketid on
muutustega igal hetkel mõjutatud saada.

Projekti lõpptulemuse leiad siin.

Järgmine samm

Järgmise sammuna võiksite igas paketis kehtestada pideva privaatsuse ja avalikustada ainult avaliku API, mis on teistest pakettidest kättesaadav. Saate hõlpsasti konfigureerida, kuhu teie API paigutatakse package.yml.

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

Järeldused

Packwerk annab meile palju teavet meie rakenduse kohta ja selle teabe abil saame teha otsuseid, et parandada meie meeskondade töövoogu. Kuigi protsess tundus pikk ja paljude seadistustega, ei pea see alati nii olema. Me võime alustada pakettide loomist ainult meie rakendusse lisatud uue koodi jaoks ja seejärel järk-järgult moduleerida. Nii et nüüd võime hakata rääkima järkjärgulisest modulatsioonist see on Stephan Hagemanni poolt tutvustatud kontseptsioon "Me saame esimest korda otsustada, et me hakkame osa koodist püüdlikult moduleerima... See võimaldab meil luua järk-järgult laieneva tugisüsteemi parema rakendusstruktuuri suunas".

Allikad

1. Ruby on Rails järkjärguline modulariseerimine - Stephan Hagemann
2. Modulaarsuse jõustamine Rails rakendustes koos Packwerkiga
3. Packwerk Github
4. Artikli lähtekood

Loe edasi

GraphQL Ruby. Kuidas on tulemuslikkus?

Rööpad ja muud transpordivahendid

Railsi arendamine TMUX, Vim, Fzf + Ripgrep abil