app\/pakketten<\/code> map waar we al onze pakketten zullen plaatsen. Om onze pakketten te isoleren moeten we elke MVC-concept<\/strong> in \u00e9\u00e9n map. De CodeTriage project<\/a><\/strong> Als voorbeeld hebben we zoiets als de volgende afbeelding.<\/p>\n\n\n\n![\"pakketstructuur](\"\/app\/uploads\/2024\/05\/2.png\" "\\"voorbeeld")
<\/figure>\n\n\n\nAls we de server proberen te starten, zal hij de constanten niet vinden. Daarom moeten we een configuratieregel toevoegen aan onze toepassing.rb<\/code><\/p>\n\n\n\nconfig.paths.add 'app\/packages', glob: '*\/{*,*\/concerns}', eager_load:true<\/code><\/pre>\n\n\n\nNu werkt de applicatie maar kan de weergaven niet vinden, dus moeten we nog een configuratieregel toevoegen aan onze toepassing_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
De pakketten maken<\/h3>\n\n\n\n
Onze structuur is klaar, dus nu kunnen we beginnen met het maken van de pakketten. Om dat te doen, hoeven we alleen maar eenpackage.yml<\/code> naar elke map met de volgende configuratie:<\/p>\n\n\n\nprivacy afdwingen: false\nafhankelijkheden afdwingen: waar<\/code><\/pre>\n\n\n\n<\/p>\n\n\n\n![\"package.yml\"](\"\/app\/uploads\/2024\/05\/1.png\" "\\"package.yml")
<\/figure>\n\n\n\nprivacy afdwingen<\/code>geeft us<\/a> de mogelijkheid om alle constanten van het pakket te isoleren en te werken met een publieke API<\/a>. Om de publieke constanten bloot te leggen, moeten we de constanten toevoegen in bijvoorbeeld pakketten\/gebruikers\/app\/public.<\/code>Voor nu gaan we deze configuratie instellen op vals<\/em>.<\/p>\n\n\n\nafhankelijkheden afdwingen<\/code> zal de afhankelijkheid van een pakket afdwingen en controleren op alle constante verwijzingen. Als een afhankelijkheid niet expliciet is gedefinieerd, is dit een schending van de grens.<\/p>\n\n\n\nHet pakketsysteem valideren<\/h3>\n\n\n\n
Packwerk<\/strong> een criterium vastgesteld dat we moeten volgen om een geldig pakketsysteem te hebben. We kunnen beginnen met het uitvoeren van pakwerk geldig<\/code> in onze console.<\/p>\n\n\n\n Hiermee wordt onze mappenstructuur gecontroleerd, pakketconfiguratie<\/strong>en autoload padcache.<\/p>\n\n\n\nOp dit moment is onze applicatie niet geldig en moeten we de laadpaden inpakwerk.yml<\/code>.<\/strong> Om dit te doen, hoeven we alleen de ontbrekende paden toe te voegen.<\/p>\n\n\n\n# pakwerk.yml\n\nlaadpaden:\n.\n.\n.\n\n# Gebruikers\n- app\/pakketten\/gebruikers\/controllers\n- app\/pakketten\/gebruikers\/modellen\n- app\/pakketten\/gebruikers\/pakket.yml\n- app\/pakketten\/gebruikers\/weergaven<\/code><\/pre>\n\n\n\nOp dit punt zijn we klaar om grensschendingen in onze applicatie te controleren. Om schendingen te controleren kunnen we het volgende uitvoerenpackwerk update-deprecations<\/code> zal dit commando het volgende genereren verouderde_verwijzingen.yml<\/code> bestand voor elk pakket. In elk bestand vinden we de pakketnaam, het type overtreding en het bestandspad. Met al deze informatie weten we waar de schending plaatsvindt en kunnen we een beslissing nemen om de schending op te lossen.<\/p>\n\n\n\n![\"verouderde_verwijzingen.yml\"](\"\/app\/uploads\/2024\/05\/4.png\" "\\"afgeschreven_verwijzingen.yml")
<\/figure>\n\n\n\n# verouderde_verwijzingen.yml\n\n.\n.\n.\n\napp\/pakketten\/repos:\n \"::Repo\":\n schendingen:\n - afhankelijkheid\n bestanden:\n - app\/packages\/users\/models\/user.rb<\/code><\/pre>\n\n\n\nAan de hand van het voorbeeld gaan we elk deel van de gegenereerde informatie beschrijven
door Packwerk<\/strong>.<\/p>\n\n\n\n- app\/pakketten\/repos<\/code> - pakket waar de constante schending is
gevonden.<\/p>\n\n\n\n- ::Repo<\/code> - pad naar het bestand met de geschonden constante.<\/p>\n\n\n\n- afhankelijkheid<\/code> - een type schending, afhankelijkheid of privacy.<\/p>\n\n\n\n- app\/pakketten\/gebruikers\/modellen\/gebruiker.rb<\/code> - pad naar het bestand met de geschonden constante.<\/p>\n\n\n\nVergeet als laatste stap in dit onderdeel niet om de nieuwe gegenereerde bestandspaden toe te voegen aan pakwerk.ym<\/code>l en voer de validaties opnieuw uit.<\/p>\n\n\n\nVisualisatie van afhankelijkheid<\/h3>\n\n\n\n
Met alle informatie in package.yml en verouderde_verwijzingen.yml<\/code>dan kunnen we
een grafiek van afhankelijkheden visualiseren. Om dat te doen moeten we nog een gem toevoegen, in dit geval gebruiken we Pocky<\/a>.<\/p>\n\n\n\nLopende hark pocky:genereren<\/code> genereren we een bestand met de naam pakwerk.png<\/code> waar we onze eerste grafiek van afhankelijkheden kunnen visualiseren.<\/p>\n\n\n\nMet alle pakketten gedefinieerd ziet onze grafiek er als volgt uit.<\/p>\n\n\n\n![\"grafiek](\"\/app\/uploads\/2024\/05\/5.png\" "\\"grafiek")
<\/figure>\n\n\n\nafhankelijkheden bestaan al, maar dat betekent niet dat ze worden geaccepteerd door Packwerk<\/strong>. Naar
een afhankelijkheid accepteren, moeten we de afhankelijkhedenconfiguratie toevoegen aan de package.yml<\/code>
in elk pakket. We richten ons op mail_bouwers<\/code> omdat het een pakket is zonder circulaire afhankelijkheid. Het is het vermelden waard dat Packwerk<\/strong> laat ons geen circulaire afhankelijkheden accepteren.<\/p>\n\n\n\n# app\/packages\/mail_builders\/package.yml\n\n``ruby\nprivacy afdwingen: false\nafhankelijkheden afdwingen: true\nafhankelijkheden:\n- app\/pakketten\/docs\n- app\/pakketten\/problemen\n- app\/pakketten\/repos<\/code><\/pre>\n\n\n\nNa het toevoegen van deze configuratie, Pocky<\/strong> zal de geaccepteerde afhankelijkheden groen kleuren.<\/p>\n\n\n\n![\"grafiek](\"\/app\/uploads\/2024\/05\/6.png\" "\\"grafiek")
<\/figure>\n\n\n\nWe kunnen verwijderen verouderde_verwijzingen.yml<\/code> van app\/pakketten\/mail_bouwers<\/code> en ren
packwerk update-deprecations<\/code> opnieuw. Het bestand wordt niet opnieuw gegenereerd omdat alle
schendingen werden opgelost voor dit pakket. Het is belangrijk om te vermelden dat zelfs als we niet Graph met geaccepteerde afhankelijkheden<\/p>\n\n\n\nRuby<\/a> modularisatie op Rails met Packwerk<\/strong> afhankelijkheden accepteren zal onze applicatie nog steeds werken zoals voorheen, maar nu hebben we meer
informatie om beslissingen te nemen en te refactoren.<\/p>\n\n\n\nCirculaire afhankelijkheden verwijderen<\/h3>\n\n\n\n
In onze vorige grafiek hadden we veel circulaire afhankelijkheden die op de een of andere manier moesten worden opgelost. We hebben verschillende strategie\u00ebn om dat te doen:<\/p>\n\n\n\n
- Niets doen,<\/p>\n\n\n\n
- Afhankelijkheden accepteren, pakketten samenvoegen,<\/p>\n\n\n\n
- Verplaatsen code<\/a> tussen pakketten,<\/p>\n\n\n\n- Een functionaliteit dupliceren, <\/p>\n\n\n\n
- Voer afhankelijkheidsinjectie of afhankelijkheidsinjectie met typing uit.<\/p>\n\n\n\n
Een probleem hierbij is dat om een goede refactor uit te voeren, we de codebase moeten kennen. Ik ben niet zo bekend met de codebase van dit project omdat ik het als voorbeeld heb genomen, dus om praktische redenen gaan we voor de eerste strategie, niets doen. Zelfs als we het grootste deel van het refactoren vermijden, willen we werken aan de afhankelijkheden in de wortel<\/em> pakket.<\/p>\n\n\n\nHet rootpakket bevat alle lijm van de Rails raamwerk<\/strong>Alle klassen waar we van erven en laten samenwerken. Dus, om de circulaire afhankelijkheden op te lossen, gaan we een nieuw pakket maken met de naam rails in de volgende stappen:<\/p>\n\n\n\n\n- Verplaats alle applicatie_ bestanden en mappen van de app naar
app\/pakketten\/rails<\/code>.<\/li>\n\n\n\n- Maak een
package.yml<\/code> voor het pakket met dezelfde configuratie als de vorige pakketten.<\/li>\n\n\n\n- Voeg alle nieuwe bestandspaden toe aan
pakwerk.yml<\/code>.<\/li>\n\n\n\n- Voeg toe
app\/pakketten\/rails<\/code> als een afhankelijkheid van de rest van de pakketten.<\/li>\n<\/ol>\n\n\n\nZodra we het pakket hebben gemaakt, zullen we veel bestanden opmerken die opnieuw kunnen worden gestructureerd. Nadat we alles naar het overeenkomstige pakket hebben verplaatst en het
afhankelijkheden hebben we een nieuwe structuur en een schonere grafiek.<\/p>\n\n\n\n![\"Pakketstructuur](\"\/app\/uploads\/2024\/05\/graph.png\" "\\"Pakketstructuur")
<\/figure>\n\n\n\n![\"Grafiek](\"\/app\/uploads\/2024\/05\/8.png\" "\\"Grafiek")
<\/figure>\n\n\n\nAfhankelijkheden van het hoofdpakket verwijderen<\/h3>\n\n\n\n
Nu ziet onze grafiek er veel beter uit. Het zou geweldig zijn als we alle afhankelijkheden van het rootpakket kunnen verwijderen. Als we deprecated_references.yml in het rootpakket controleren, zullen we zien dat de meeste van hen van test<\/code> , lib\/taken<\/code> , db<\/code> en config<\/code>
map. Om deze afhankelijkheden op te lossen, gaan we in elk pakket een testmap maken. Iets als app\/pakketten\/gebruikers\/test<\/code>. Vervolgens gaan we lib\/taken<\/code> , db<\/code> en config<\/code>onder andere mappen van Packwerk<\/strong> analyse omdat die afhankelijkheden niet echt belangrijk zijn in onze analyse en we geen gemakkelijke manier hebben om ze op te lossen. We voegen het volgende toe aan onze pakwerk.yml<\/em>.<\/p>\n\n\n\nexclude:\n- \"{bin,node_modules,script,tmp,vendor,lib,db,config,perf_scripts}\/**\/*\"\n- \"lib\/tasks\/**\/*.rake\"<\/code><\/pre>\n\n\n\nNa het verplaatsen van alle tests uit het rootpakket en het uitsluiten van de mappen uit de analyse, hebben we een nieuwe grafiek zonder rootafhankelijkheden.<\/p>\n\n\n\n![\"Grafiek](\"\/app\/uploads\/2024\/05\/9.png\" "\\"Grafiek")
<\/figure>\n\n\n\nZoals we kunnen zien, hebben we nog steeds circulaire afhankelijkheden ingebruikers<\/code> , repo's<\/code> en docs<\/code> . Hoewel we ze niet hebben opgelost, hebben we nu belangrijke informatie om door te geven. We weten dat elke team<\/a> die wijzigingen doorvoert in \u00e9\u00e9n van die pakketten, zal waarschijnlijk ook wijzigingen moeten doorvoeren in de pakketten met de circulaire afhankelijkheid. Aan de andere kant weten we dat een team kan werken aan github_fetchers<\/code> alleen, weten welke pakketten
die op elk moment wordt be\u00efnvloed door de veranderingen.<\/p>\n\n\n\nJe kunt het eindresultaat van het project vinden hier<\/a>.<\/p>\n\n\n\nVolgende stap<\/h3>\n\n\n\n
Als volgende stap zou je constante privacy kunnen afdwingen in elk pakket en alleen de openbare API kunnen vrijgeven die toegankelijk zal zijn vanuit andere pakketten. Je kunt eenvoudig configureren waar je API wordt geplaatst in package.yml<\/em>.<\/p>\n\n\n\nprivacy afdwingen: true\nafhankelijkheden afdwingen: waar\nopenbaar_pad: mijn\/aangepast\/pad\/<\/code><\/pre>\n\n\n\n <\/code><\/p>\n\n\n\nConclusies<\/h2>\n\n\n\n
Packwerk<\/strong> geeft ons veel informatie over onze applicatie en met die informatie kunnen we beslissingen nemen om de workflow van onze teams te verbeteren. Hoewel het proces lang leek en met veel configuraties, hoeft het niet altijd zo te zijn. We kunnen beginnen met het maken van pakketten alleen voor de nieuwe code die aan onze applicatie wordt toegevoegd en dan geleidelijk modulariseren. Nu kunnen we dus beginnen te praten over geleidelijke modularisatie, een concept dat is ge\u00efntroduceerd door Stephan Hagemann. \"We kunnen voor het eerst besluiten om te beginnen met het modulariseren van een deel van de code op een aspirationele manier... Dit stelt ons in staat om een geleidelijk uitbreidend ondersteuningssysteem te cre\u00ebren in de richting van een betere applicatiestructuur\".<\/em><\/p>\n\n\n\nBronnen<\/h2>\n\n\n\n\n- Geleidelijke modularisatie voor Ruby on Rails - Stephan Hagemann<\/a><\/li>\n\n\n\n
- Modulariteit afdwingen in Rails-apps met Packwerk<\/a><\/li>\n\n\n\n
- Packwerk Github<\/a><\/li>\n\n\n\n
- Broncode van het artikel<\/a><\/li>\n<\/ol>\n\n\n\n
![\"Advies](\"\/app\/uploads\/2024\/05\/cta_2.jpeg\")
<\/a><\/figure>\n\n\n\nMeer lezen<\/strong><\/p>\n\n\n\nGraphQL Ruby. Hoe zit het met de prestaties?<\/a><\/p>\n\n\n\n