thecodest, The Codest autorius

Paraiška kaip paketas

Mūsų taikomosios programos moduliavimo būdas - visą programą paversti paketu.

Sukurti struktūrą

Pirmiausia turime sukurti app/packages aplanką, į kurį dėsime visus savo paketus. Norėdami atskirti savo paketus, turime atskirti kiekvieną MVC koncepcija viename aplanke. Paėmus CodeTriage projektas kaip pavyzdį galime pateikti tokį paveikslėlį.

Jei bandysime paleisti serverį, jis neras konstantų. Štai kodėl turime pridėti konfigūracijos eilutę prie mūsų application.rb

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

Dabar programa veikia, bet ji negali rasti rodinių, todėl turime pridėti dar vieną konfigūracijos eilutę į mūsų application_controller.rb

append_view_path(Dir.glob(Bėgiai.root.join('app/packages/*/views')))

Sukurti paketus

Mūsų struktūra paruošta, todėl dabar galime pradėti kurti paketus. Tam mums tereikia pridėtipackage.yml į kiekvieną aplanką su tokia konfigūracija:

enforce_privacy: false
enforce_dependencies: true

enforce_privacypateikia . mus galimybė izoliuoti visas paketo konstantas ir dirbti su viešąja API. Norėdami atskleisti viešąsias konstantas, turime pridėti konstantas, pvz. packages/users/app/public.Kol kas šią konfigūraciją nustatysime į klaidinga.

enforce_dependencies užtikrins paketo priklausomybę ir patikrins visas konstantų nuorodas. Jei priklausomybė nėra aiškiai apibrėžta, tai bus ribos pažeidimas.

Paketų sistemos patvirtinimas

Packwerk nustatė kriterijų, kurio turime laikytis, kad turėtume galiojančią paketų sistemą. Galime pradėti vykdyti Packwerk patvirtinti mūsų konsolėje.

Patikrinsime aplankų struktūrą, paketo konfigūracija, ir automatinis kelio talpyklos įkėlimas.

Šiuo metu mūsų programa negalioja, todėl turime ištaisyti apkrovos keliuspackwerk.yml. Tam tereikia pridėti trūkstamus kelius.

# packwerk.yml

load_paths:
.
.
.

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

Šiuo metu esame pasiruošę patikrinti ribų pažeidimus savo programoje. Norėdami patikrinti pažeidimus, galime paleistipackwerk update-deprecations , ši komanda sukurs deprecated_references.yml kiekvieno paketo failą. Kiekviename faile rasime paketo pavadinimą, pažeidimo tipą ir failo kelią. Turėdami visą šią informaciją žinome, kur yra pažeidimas, ir galime priimti sprendimą, kaip jį pašalinti.

# deprecated_references.yml

.
.
.

app/packages/repos:
  "::Repo":
    : "Repo:": pažeidimai:
    - priklausomybė
    failai:
    - app/packages/users/models/user.rb

Remdamiesi pavyzdžiu, aprašysime kiekvieną sukurtos informacijos dalį.
pagal Packwerk.

- app/packages/repos - paketas, kuriame pastovus pažeidimas yra
rasta.

- ::Repo - kelias iki failo, kuriame yra pažeista konstanta.

- priklausomybė - tam tikros rūšies pažeidimas - priklausomybės arba privatumo.

- app/packages/users/models/user.rb - kelias iki failo, kuriame yra pažeista konstanta.

Baigdami šį skyrių, nepamirškite pridėti naujų sugeneruotų failų kelių prie packwerk.yml ir dar kartą paleiskite patvirtinimus.

Priklausomybės vizualizavimas

Naudodami visą informaciją, pateiktą package.yml ir deprecated_references.ymltada galime
vizualizuoti priklausomybių grafiką. Tam reikia pridėti dar vieną brangakmenį, šiuo atveju naudosime Pocky.

Veikiamas grėblys Pocky:generuoti sukursime failą, pavadintą packwerk.png kuriame galime vizualizuoti pirmąjį priklausomybių grafiką.

Apibrėžus visus paketus, mūsų diagrama atrodys taip.

priklausomybės jau egzistuoja, bet tai nereiškia, kad jos priimamos Packwerk. Į
priimti priklausomybę, turime pridėti priklausomybių konfigūraciją prie package.yml
kiekvienoje pakuotėje. Daugiausia dėmesio skirsime mail_builders nes tai paketas be žiedinės priklausomybės. Verta paminėti, kad Packwerk neleidžia mums priimti žiedinių priklausomybių.

# app/packages/mail_builders/package.yml

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

Pridėjus šią konfigūraciją, Pocky priimtinas priklausomybes nuspalvins žaliai.

Galime ištrinti deprecated_references.yml iš app/packages/mail_builders ir paleiskite
packwerk update-deprecations dar kartą. Failas nebus generuojamas iš naujo, nes visi
šiame pakete ištaisyti pažeidimai. Svarbu paminėti, kad net jei mes ne Grafikas su priimtomis priklausomybėmis

Ruby apie "Rails" moduliavimą su "Packwerk priimti priklausomybes, mūsų programa veiks kaip ir anksčiau, tačiau dabar turime daugiau
informaciją, kad galėtumėte priimti sprendimus ir keisti struktūrą.

Pašalinti žiedines priklausomybes

Ankstesnėje diagramoje buvo daug žiedinių priklausomybių, kurias reikėjo kažkaip išspręsti. Turime įvairių strategijų, kaip tai padaryti:

- Nieko nedarykite,

- Priimti priklausomybes, Sujungti paketus,

- Perkelti kodas tarp paketų,

- Dubliuoti funkciją,

- Atlikite priklausomybės įskiepijimą arba priklausomybės įskiepijimą su rašymu.

Viena iš problemų yra ta, kad, norėdami tinkamai atlikti refaktorių, turime žinoti kodų bazę. Nesu gerai susipažinęs su šio projekto kodų baze, nes jį ėmiau kaip pavyzdį, todėl praktiniais sumetimais pasirinksime pirmąją strategiją - nieko nedaryti. Net jei išvengsime didžiosios dalies refaktorizavimo, norime dirbti su priklausomybėmis root pakuotė.

Į šakninį paketą įtraukti visi klijai iš "Rails" sistema, visas klases, iš kurių paveldime, ir priversti jas veikti kartu. Taigi, kad išspręstume žiedinių priklausomybių problemą, toliau nurodytais veiksmais sukursime naują paketą, pavadintą rails:

Perkelkite visus programos_ failus ir aplankus iš programos į app/packages/rails.
Sukurtipackage.yml paketą, kurio konfigūracija tokia pati kaip ankstesnių paketų.
Pridėkite visus naujus failų kelius į packwerk.yml.
Pridėti app/packages/rails kaip priklausomybę nuo kitų paketų.

Sukūrę paketą pradėsime pastebėti daug failų, kurių struktūrą galima pakeisti. Viską perkėlus į atitinkamą paketą ir priėmus
priklausomybių, turėsime naują struktūrą ir švaresnį grafiką.

Grafikas be šakninių žiedinių priklausomybių

Priklausomybių pašalinimas iš šakninio paketo

Dabar mūsų grafikas atrodo daug geriau, būtų puiku, jei galėtume pašalinti visas priklausomybes iš šakninio paketo. Jei patikrinsime deprecated_references.yml šakniniame pakete, pastebėsime, kad dauguma jų yra iš testas , lib/tasks , db ir konfigūracija
aplankas. Norėdami išspręsti šias priklausomybes, kiekviename pakete sukursime bandymų aplanką. Turėdami kažką panašaus į app/packages/users/test. Toliau ketiname išskirti lib/tasks , db ir konfigūracijatarp kitų aplankų iš Packwerk analizę, nes šios priklausomybės nėra labai svarbios mūsų analizėje ir neturime paprasto būdo jas išspręsti. Mes pridėsime prie savo packwerk.yml.

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

Perkėlus visus testus iš šakninio paketo ir pašalinus aplankus iš analizės, turėsime naują grafiką be šakninių priklausomybių.

Kaip matome, vis dar turime žiedinių priklausomybiųvartotojai , atliekynai , ir dokumentai . Nors jų neišsprendėme, dabar turime perduoti svarbios informacijos. Mes žinome, kad kiekvienas komanda kuris atlieka pakeitimus viename iš šių paketų, tikriausiai turės atlikti pakeitimus ir paketuose, turinčiuose žiedinę priklausomybę. Kita vertus, žinome, kad team gali veikti github_fetchers tik žinant, kokie paketai yra
kiekvieną akimirką patiria pokyčius.

Galutinį projekto rezultatą galite rasti čia.

Kitas žingsnis

Kitas žingsnis - kiekviename pakete galite užtikrinti nuolatinį privatumą ir atskleisti tik viešą API, kuri bus prieinama iš kitų paketų. Galite lengvai konfigūruoti, kur jūsų API bus patalpinta package.yml.

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

Išvados

Packwerk suteikia mums daug informacijos apie mūsų taikomąją programą ir, naudodamiesi šia informacija, galime priimti sprendimus, kaip pagerinti team darbo eigą. Nors procesas atrodė ilgas ir su daugybe konfigūracijų, jis nebūtinai turi būti toks visada. Galime pradėti kurti paketus tik naujam kodui, pridėtam prie mūsų taikomosios programos, o vėliau palaipsniui modulizuoti. Taigi dabar galime pradėti kalbėti apie laipsnišką moduliavimą - šią koncepciją pristatė Stephanas Hagemannas “Pirmą kartą galime nuspręsti pradėti modulizuoti dalį kodo siekiamybės būdu... Tai leidžia mums sukurti palaipsniui besiplečiančią paramos sistemą geresnei taikomosios programos struktūrai”.

Šaltiniai

Skaitmeninių produktų kūrimo konsultacijos

Skaityti daugiau

"GraphQL Ruby". O kaip dėl našumo?

Bėgiai ir kitos transporto priemonės

"Rails" kūrimas naudojant TMUX, "Vim", Fzf + Ripgrep