app\/pakker<\/code> mappen der vi skal plassere alle pakkene v\u00e5re. For \u00e5 isolere pakkene v\u00e5re m\u00e5 vi skille hver MVC-konseptet<\/strong> i \u00e9n mappe. Ved \u00e5 ta CodeTriage prosjekt<\/a><\/strong> som et eksempel vil vi ha noe som ligner p\u00e5 f\u00f8lgende bilde.<\/p>\n\n\n\n![\"pakkestruktur](\"\/app\/uploads\/2024\/05\/2.png\" "\\"eksempel")
<\/figure>\n\n\n\nHvis vi pr\u00f8ver \u00e5 kj\u00f8re serveren, vil den ikke finne konstantene. Derfor m\u00e5 vi legge til en konfigurasjonslinje i application.rb<\/code><\/p>\n\n\n\nconfig.paths.add 'app\/packages', glob: '*\/{*,*\/concerns}', eager_load:true<\/code><\/pre>\n\n\n\nN\u00e5 fungerer applikasjonen, men den finner ikke visningene, s\u00e5 vi m\u00e5 legge til en ny konfigurasjonslinje i application_controller.rb<\/code><\/p>\n\n\n\nappend_view_path(Dir.glob(Rails<\/a>.root.join('app\/packages\/*\/views')))<\/code><\/pre>\n\n\n\n<\/p>\n\n\n\n
Opprett pakkene<\/h3>\n\n\n\n
Strukturen v\u00e5r er klar, s\u00e5 n\u00e5 kan vi begynne \u00e5 opprette pakkene. For \u00e5 gj\u00f8re det trenger vi bare \u00e5 legge til enpackage.yml<\/code> til hver mappe med f\u00f8lgende konfigurasjon:<\/p>\n\n\n\nenforce_privacy: false\nenforce_dependencies: true<\/code><\/pre>\n\n\n\n<\/p>\n\n\n\n![\"package.yml\"](\"\/app\/uploads\/2024\/05\/1.png\" "\\"eksempel")
<\/figure>\n\n\n\nenforce_privacy<\/code>gir oss<\/a> muligheten til \u00e5 isolere alle konstantene i pakken og arbeide med en offentlig API<\/a>. For \u00e5 eksponere de offentlige konstantene m\u00e5 vi legge til konstantene i for eksempel pakker\/brukere\/app\/public.<\/code>Forel\u00f8pig skal vi sette denne konfigurasjonen til falsk<\/em>.<\/p>\n\n\n\nenforce_dependencies<\/code> vil h\u00e5ndheve avhengigheten til en pakke og se etter alle konstante referanser. Hvis en avhengighet ikke er eksplisitt definert, vil det v\u00e6re et brudd p\u00e5 grensene.<\/p>\n\n\n\nValidering av pakkesystemet<\/h3>\n\n\n\n
Packwerk<\/strong> etablert et kriterium vi m\u00e5 f\u00f8lge for \u00e5 ha et gyldig pakkesystem. Vi kan begynne \u00e5 kj\u00f8re packwerk validere<\/code> i konsollen v\u00e5r.<\/p>\n\n\n\n Dette vil sjekke mappestrukturen v\u00e5r, pakkekonfigurasjon<\/strong>og autoload banebuffer.<\/p>\n\n\n\nAkkurat n\u00e5 er ikke applikasjonen v\u00e5r gyldig, og vi m\u00e5 fikse lastestiene ipackwerk.yml<\/code>.<\/strong> For \u00e5 gj\u00f8re dette trenger vi bare \u00e5 legge til de manglende stiene.<\/p>\n\n\n\n# packwerk.yml\n\nload_paths:\n.\n.\n.\n\n#-brukere\n- app\/packages\/users\/controllers\n- app\/pakker\/brukere\/modeller\n- app\/pakker\/brukere\/package.yml\n- app\/pakker\/brukere\/visninger<\/code><\/pre>\n\n\n\nN\u00e5 er vi klare til \u00e5 sjekke grenseoverskridelser i applikasjonen v\u00e5r. For \u00e5 sjekke brudd kan vi kj\u00f8repackwerk update-deprecations<\/code> vil denne kommandoen generere utdaterte_referanser.yml<\/code> fil for hver pakke. I hver fil finner vi pakkenavn, type brudd og filbane. Med all denne informasjonen vet vi hvor overtredelsen skjer, og vi kan ta en beslutning om \u00e5 l\u00f8se den.<\/p>\n\n\n\n![\"utdaterte_referanser.yml\"](\"\/app\/uploads\/2024\/05\/4.png\" "\\"eksempel")
<\/figure>\n\n\n\n# deprecated_references.yml\n\n.\n.\n.\n\napp\/packages\/repos:\n \"::Repo\":\n brudd:\n - avhengighet\n filer:\n - app\/packages\/users\/models\/user.rb<\/code><\/pre>\n\n\n\nI dette eksemplet skal vi beskrive alle deler av informasjonen som genereres
av Packwerk<\/strong>.<\/p>\n\n\n\n- app\/packages\/repos<\/code> - pakke der konstantbruddet er
funnet.<\/p>\n\n\n\n- ::Repo<\/code> - stien til filen som inneholder den brutte konstanten.<\/p>\n\n\n\n- avhengighet<\/code> - en type krenkelse, enten avhengighet eller personvern.<\/p>\n\n\n\n- app\/packages\/users\/models\/user.rb<\/code> - stien til filen som inneholder den brutte konstanten.<\/p>\n\n\n\nSom et siste trinn i denne delen, ikke glem \u00e5 legge til de nye genererte filbanene i packwerk.ym<\/code>l og kj\u00f8r valideringene p\u00e5 nytt.<\/p>\n\n\n\nVisualisering av avhengighet<\/h3>\n\n\n\n
Med all informasjonen i package.yml og utdaterte_referanser.yml<\/code>Vi kan da
visualisere en graf over avhengigheter. For \u00e5 gj\u00f8re det m\u00e5 vi legge til en annen perle, i dette tilfellet vil vi bruke Pocky<\/a>.<\/p>\n\n\n\nL\u00f8pende rive pocky:generere<\/code> vil vi generere en fil som heter packwerk.png<\/code> der vi kan visualisere v\u00e5r f\u00f8rste graf over avhengigheter.<\/p>\n\n\n\nN\u00e5r alle pakkene er definert, ser grafen v\u00e5r slik ut.<\/p>\n\n\n\n![\"graf](\"\/app\/uploads\/2024\/05\/5.png\" "\\"graf")
<\/figure>\n\n\n\navhengigheter allerede eksisterer, men det betyr ikke at de er akseptert av Packwerk<\/strong>. Til
akseptere en avhengighet, m\u00e5 vi legge til avhengighetskonfigurasjon i package.yml<\/code>
i hver pakke. Vi vil fokusere p\u00e5 mail_builders<\/code> siden det er en pakke uten sirkul\u00e6r avhengighet. Det er verdt \u00e5 nevne at Packwerk<\/strong> lar oss ikke akseptere sirkul\u00e6re avhengigheter.<\/p>\n\n\n\n# app\/packages\/mail_builders\/package.yml\n\n```ruby\nenforce_privacy: false\nenforce_dependencies: true\ndependencies:\n- app\/packages\/docs\n- app\/packages\/issues\n- app\/packages\/repos<\/code><\/pre>\n\n\n\nEtter at du har lagt til denne konfigurasjonen, Pocky<\/strong> vil farge de aksepterte avhengighetene med gr\u00f8nt.<\/p>\n\n\n\n![\"graf](\"\/app\/uploads\/2024\/05\/6.png\" "\\"graf")
<\/figure>\n\n\n\nVi kan slette utdaterte_referanser.yml<\/code> fra app\/packages\/mail_builders<\/code> og kj\u00f8re
packwerk update-deprecations<\/code> igjen. Filen vil ikke bli generert p\u00e5 nytt, siden alle
brudd ble rettet for denne pakken. Det er viktig \u00e5 nevne at selv om vi ikke bruker Graph med aksepterte avhengigheter<\/p>\n\n\n\nRuby<\/a> on Rails-modularisering med Packwerk<\/strong> akseptere avhengigheter vil applikasjonen v\u00e5r fortsatt fungere som f\u00f8r, men n\u00e5 har vi flere
informasjon for \u00e5 ta beslutninger og gj\u00f8re endringer.<\/p>\n\n\n\nFjern sirkul\u00e6re avhengigheter<\/h3>\n\n\n\n
I den forrige grafen v\u00e5r hadde vi mange sirkul\u00e6re avhengigheter som m\u00e5tte l\u00f8ses p\u00e5 en eller annen m\u00e5te. Vi har ulike strategier for \u00e5 gj\u00f8re det:<\/p>\n\n\n\n
- Gj\u00f8r ingenting,<\/p>\n\n\n\n
- Godta avhengigheter, Sl\u00e5 sammen pakker,<\/p>\n\n\n\n
- Flytte kode<\/a> mellom pakkene,<\/p>\n\n\n\n- Dupliser en funksjonalitet, <\/p>\n\n\n\n
- Utf\u00f8r avhengighetsinjeksjon eller avhengighetsinjeksjon med typing.<\/p>\n\n\n\n
Et problem her er at vi m\u00e5 kjenne kodebasen for \u00e5 kunne gj\u00f8re en skikkelig refaktorering. Jeg er ikke s\u00e5 godt kjent med kodebasen til dette prosjektet siden jeg tok det som et eksempel, s\u00e5 av praktiske grunner vil vi g\u00e5 for den f\u00f8rste strategien, \u00e5 ikke gj\u00f8re noe. Selv om vi vil unng\u00e5 det meste av refaktorering, \u00f8nsker vi \u00e5 jobbe med avhengighetene i rot<\/em> pakke.<\/p>\n\n\n\nRotpakken inneholder alt limet fra Rails-rammeverket<\/strong>, alle klassene vi arver fra og f\u00e5r alle til \u00e5 fungere sammen. S\u00e5 for \u00e5 l\u00f8se de sirkul\u00e6re avhengighetene, skal vi opprette en ny pakke kalt rails i f\u00f8lgende trinn:<\/p>\n\n\n\n\n- Flytt alle applikasjonsfiler og -mapper fra appen til
app\/packages\/rails<\/code>.<\/li>\n\n\n\n- Opprett en
package.yml<\/code> for pakken med samme konfigurasjon som de foreg\u00e5ende pakkene.<\/li>\n\n\n\n- Legg til alle de nye filbanene i
packwerk.yml<\/code>.<\/li>\n\n\n\n- Legg til
app\/packages\/rails<\/code> som en avhengighet fra resten av pakkene.<\/li>\n<\/ol>\n\n\n\nN\u00e5r vi har opprettet pakken, vil vi begynne \u00e5 legge merke til mange filer som kan struktureres p\u00e5 nytt. Etter \u00e5 ha flyttet alt til den tilsvarende pakken og akseptert
avhengigheter f\u00e5r vi en ny struktur og en renere graf.<\/p>\n\n\n\n![\"Pakningsstruktur](\"\/app\/uploads\/2024\/05\/graph.png\" "\\"Eksempel")
<\/figure>\n\n\n\n![\"Graf](\"\/app\/uploads\/2024\/05\/8.png\" "\\"Eksempel")
<\/figure>\n\n\n\nFjern avhengigheter fra rotpakken<\/h3>\n\n\n\n
N\u00e5 ser grafen v\u00e5r mye bedre ut, og det ville v\u00e6rt flott hvis vi kunne fjerne alle avhengighetene fra rotpakken. Hvis vi sjekker deprecated_references.yml i rotpakken, vil vi legge merke til at de fleste av dem er fra test<\/code> , lib\/tasks<\/code> , db<\/code> og konfigurasjon<\/code>
mappe. For \u00e5 l\u00f8se disse avhengighetene skal vi opprette en testmappe i hver pakke. \u00c5 ha noe s\u00e5nt som app\/pakker\/brukere\/test<\/code>. Deretter skal vi ekskludere lib\/tasks<\/code> , db<\/code> og konfigurasjon<\/code>blant andre mapper fra Packwerk<\/strong> siden disse avhengighetene egentlig ikke er viktige i analysen v\u00e5r, og vi ikke har noen enkel m\u00e5te \u00e5 l\u00f8se dem p\u00e5. Vi vil legge til f\u00f8lgende i v\u00e5r packwerk.yml<\/em>.<\/p>\n\n\n\nekskluder:\n- \"{bin,node_modules,script,tmp,vendor,lib,db,config,perf_scripts}\/**\/*\"\n- \"lib\/tasks\/**\/*.rake\"<\/code><\/pre>\n\n\n\nN\u00e5r vi har flyttet alle testene fra rotpakken og ekskludert mappene fra analysen, f\u00e5r vi en ny graf uten rotavhengigheter.<\/p>\n\n\n\n![\"Graf](\"\/app\/uploads\/2024\/05\/9.png\" "\\"Graf")
<\/figure>\n\n\n\nSom vi ser, har vi fortsatt sirkul\u00e6re avhengigheter ibrukere<\/code> , repos<\/code> , og dokumenter<\/code> . Selv om vi ikke l\u00f8ste dem, har vi viktig informasjon \u00e5 formidle n\u00e5. Vi vet at alle team<\/a> som utf\u00f8rer endringer i en av disse pakkene, vil sannsynligvis m\u00e5tte utf\u00f8re endringer i pakkene med den sirkul\u00e6re avhengigheten. P\u00e5 den annen side vet vi at et team kan jobbe med github_fetchers<\/code> utelukkende \u00e5 vite hvilke pakker som er
blir p\u00e5virket av endringene i hvert \u00f8yeblikk.<\/p>\n\n\n\nDet endelige resultatet av prosjektet finner du her her<\/a>.<\/p>\n\n\n\nNeste trinn<\/h3>\n\n\n\n
Som et neste trinn kan du h\u00e5ndheve konstant personvern i hver pakke og bare eksponere det offentlige API-et som vil v\u00e6re tilgjengelig fra andre pakker. Du kan enkelt konfigurere hvor API-et ditt skal plasseres i package.yml<\/em>.<\/p>\n\n\n\nenforce_privacy: true\nenforce_dependencies: true\npublic_path: min\/tilpasset\/sti\/<\/code><\/pre>\n\n\n\n <\/code><\/p>\n\n\n\nKonklusjoner<\/h2>\n\n\n\n
Packwerk<\/strong> gir oss mye informasjon om applikasjonen v\u00e5r, og med den informasjonen kan vi ta beslutninger for \u00e5 forbedre arbeidsflyten til teamene v\u00e5re. Selv om prosessen s\u00e5 ut til \u00e5 v\u00e6re lang og med mange konfigurasjoner, trenger det ikke alltid \u00e5 v\u00e6re slik. Vi kan begynne med \u00e5 opprette pakker bare for den nye koden som legges til i applikasjonen, og deretter modulere gradvis. S\u00e5 n\u00e5 kan vi begynne \u00e5 snakke om gradvis modularisering, et konsept introdusert av Stephan Hagemann \"For f\u00f8rste gang kan vi bestemme oss for \u00e5 begynne \u00e5 modularisere en del av koden p\u00e5 en ambisi\u00f8s m\u00e5te ... Dette gj\u00f8r det mulig for oss \u00e5 skape et gradvis voksende st\u00f8ttesystem mot en bedre applikasjonsstruktur.\"<\/em><\/p>\n\n\n\nKilder<\/h2>\n\n\n\n\n- Gradvis modularisering for Ruby on Rails - Stephan Hagemann<\/a><\/li>\n\n\n\n
- H\u00e5ndhevelse av modularitet i Rails-apper med Packwerk<\/a><\/li>\n\n\n\n
- Packwerk Github<\/a><\/li>\n\n\n\n
- Kildekoden til artikkelen<\/a><\/li>\n<\/ol>\n\n\n\n
![\"R\u00e5dgivning](\"\/app\/uploads\/2024\/05\/cta_2.jpeg\")
<\/a><\/figure>\n\n\n\nLes mer<\/strong><\/p>\n\n\n\nGraphQL Ruby. Hva med ytelse?<\/a><\/p>\n\n\n\n