window.pipedriveLeadboosterConfig = { base: leadbooster-chat.pipedrive.com', companyId: 11580370, playbookUuid: '22236db1-6d50-40c4-b48f-8b11262155be', version: 2, } ;(function () { var w = window if (w.LeadBooster) { console.warn('LeadBooster on juba olemas') } else { w.LeadBooster = { q: [], on: function (n, h) { this.q.push({ t: 'o', n: n, h: h }) }, trigger: function (n) { this.q.push({ t: 't', n: n }) }, } } })() Ruby on Rails moduleerimine koos Packwerk Episode II-ga - The Codest
The Codest
  • Meie kohta
  • Teenused
    • Tarkvaraarendus
      • Frontend arendus
      • Backend arendus
    • Staff Augmentation
      • Frontend arendajad
      • Backend arendajad
      • Andmeinsenerid
      • Pilveinsenerid
      • QA insenerid
      • Muud
    • See nõuandev
      • Audit ja nõustamine
  • Tööstusharud
    • Fintech & pangandus
    • E-commerce
    • Adtech
    • Healthtech
    • Tootmine
    • Logistika
    • Autotööstus
    • IOT
  • Väärtus
    • CEO
    • CTO
    • Tarnejuht
  • Meie meeskond
  • Case Studies
  • Tea kuidas
    • Blogi
    • Kohtumised
    • Veebiseminarid
    • Ressursid
Karjäärivõimalused Võtke ühendust
  • Meie kohta
  • Teenused
    • Tarkvaraarendus
      • Frontend arendus
      • Backend arendus
    • Staff Augmentation
      • Frontend arendajad
      • Backend arendajad
      • Andmeinsenerid
      • Pilveinsenerid
      • QA insenerid
      • Muud
    • See nõuandev
      • Audit ja nõustamine
  • Väärtus
    • CEO
    • CTO
    • Tarnejuht
  • Meie meeskond
  • Case Studies
  • Tea kuidas
    • Blogi
    • Kohtumised
    • Veebiseminarid
    • Ressursid
Karjäärivõimalused Võtke ühendust
Tagasi nool TAGASI
2022-01-10
Tarkvaraarendus

Ruby on Rails modulariseerimine Packwerk Episode II abil

Nicolas Nisoria

Meie Ruby on Rails modulariseerimise teises episoodis koos Packwerkiga vaatleme lähemalt rakenduse kui paketi mõistet.

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.

paketi struktuur

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

package.yml

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
# 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.

graafik ilma aktsepteeritud sõltuvusteta

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.

graafik koos aktsepteeritud sõltuvustega

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.

Paketi struktuur koos rööbaspaketiga
Graafik ilma juurest tulenevate ümmarguste sõltuvusteta

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.

Graafik 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
Digitaalse tootearenduse nõustamine

Loe edasi

GraphQL Ruby. Kuidas on tulemuslikkus?

Rööpad ja muud transpordivahendid

Railsi arendamine TMUX, Vim, Fzf + Ripgrep abil

Seotud artiklid

Tarkvaraarendus

Tulevikukindlate veebirakenduste loomine: The Codest ekspertide meeskonna ülevaade

Avastage, kuidas The Codest paistab skaleeritavate, interaktiivsete veebirakenduste loomisel silma tipptehnoloogiatega, mis pakuvad sujuvat kasutajakogemust kõigil platvormidel. Saate teada, kuidas meie eksperditeadmised aitavad kaasa digitaalsele ümberkujundamisele ja äritegevusele...

THECODEST
Tarkvaraarendus

Top 10 Lätis asuvat tarkvaraarendusettevõtet

Tutvu Läti parimate tarkvaraarendusettevõtete ja nende innovaatiliste lahendustega meie viimases artiklis. Avastage, kuidas need tehnoloogiajuhid saavad aidata teie äri edendada.

thecodest
Enterprise & Scaleups lahendused

Java tarkvaraarenduse põhitõed: A Guide to Outsourcing Successfully

Tutvuge selle olulise juhendiga, kuidas edukalt outsourcing Java tarkvara arendada, et suurendada tõhusust, pääseda ligi eksperditeadmistele ja edendada projekti edu The Codest abil.

thecodest
Tarkvaraarendus

Ülim juhend Poola allhanke kohta

outsourcing kasv Poolas on tingitud majanduslikust, hariduslikust ja tehnoloogilisest arengust, mis soodustab IT kasvu ja ettevõtlussõbralikku kliimat.

TheCodest
Enterprise & Scaleups lahendused

Täielik juhend IT-auditi vahendite ja tehnikate kohta

IT-auditid tagavad turvalised, tõhusad ja nõuetele vastavad süsteemid. Lisateavet nende tähtsuse kohta leiate kogu artiklist.

The Codest
Jakub Jakubowicz CTO & kaasasutajad

Tellige meie teadmistebaas ja jääge kursis IT-sektori eksperditeadmistega.

    Meie kohta

    The Codest - rahvusvaheline tarkvaraarendusettevõte, mille tehnoloogiakeskused asuvad Poolas.

    Ühendkuningriik - peakorter

    • Büroo 303B, 182-184 High Street North E6 2JA
      London, Inglismaa

    Poola - kohalikud tehnoloogiakeskused

    • Fabryczna büroopark, Aleja
      Pokoju 18, 31-564 Kraków
    • Brain Embassy, Konstruktorska
      11, 02-673 Varssavi, Poola

      The Codest

    • Kodu
    • Meie kohta
    • Teenused
    • Case Studies
    • Tea kuidas
    • Karjäärivõimalused
    • Sõnastik

      Teenused

    • See nõuandev
    • Tarkvaraarendus
    • Backend arendus
    • Frontend arendus
    • Staff Augmentation
    • Backend arendajad
    • Pilveinsenerid
    • Andmeinsenerid
    • Muud
    • QA insenerid

      Ressursid

    • Faktid ja müüdid koostööst välise tarkvaraarenduspartneriga
    • USAst Euroopasse: Miks otsustavad Ameerika idufirmad Euroopasse ümber asuda?
    • Tech Offshore arenduskeskuste võrdlus: Euroopa (Poola), ASEAN (Filipiinid), Euraasia (Türgi).
    • Millised on CTO ja CIOde peamised väljakutsed?
    • The Codest
    • The Codest
    • The Codest
    • Privacy policy
    • Website terms of use

    Copyright © 2025 by The Codest. Kõik õigused kaitstud.

    etEstonian
    en_USEnglish de_DEGerman sv_SESwedish da_DKDanish nb_NONorwegian fiFinnish fr_FRFrench pl_PLPolish arArabic it_ITItalian jaJapanese ko_KRKorean es_ESSpanish nl_NLDutch elGreek etEstonian