app\/pacotes<\/code> onde colocaremos todos os nossos pacotes. Para isolar os nossos pacotes, temos de separar cada Conceito MVC<\/strong> numa pasta. Pegar no CodeTriage projeto<\/a><\/strong> como exemplo, teremos algo parecido com a seguinte imagem.<\/p>\n\n\n\n![\"estrutura](\"\/app\/uploads\/2024\/05\/2.png\" "\\"exemplo")
<\/figure>\n\n\n\nSe tentarmos executar o servidor, ele n\u00e3o conseguir\u00e1 encontrar as constantes. \u00c9 por isso que precisamos adicionar uma linha de configura\u00e7\u00e3o ao nosso aplica\u00e7\u00e3o.rb<\/code><\/p>\n\n\n\nconfig.paths.add 'app\/packages', glob: '*\/{*,*\/concerns}', eager_load:true<\/code><\/pre>\n\n\n\nAgora a aplica\u00e7\u00e3o funciona mas n\u00e3o consegue encontrar as vistas, por isso precisamos de adicionar outra linha de configura\u00e7\u00e3o ao nosso application_controller.rb<\/code><\/p>\n\n\n\nappend_view_path(Dir.glob(Carris<\/a>.root.join('app\/packages\/*\/views')))<\/code><\/pre>\n\n\n\n<\/p>\n\n\n\n
Criar os pacotes<\/h3>\n\n\n\n
A nossa estrutura est\u00e1 pronta, por isso agora podemos come\u00e7ar a criar os pacotes. Para isso, s\u00f3 precisamos de adicionar umpackage.yml<\/code> para cada pasta com a seguinte configura\u00e7\u00e3o:<\/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\" "\\"exemplo")
<\/figure>\n\n\n\nimpor_privacidade<\/code>d\u00e1 n\u00f3s<\/a> a possibilidade de isolar todas as constantes do pacote e trabalhar com uma constante p\u00fablica API<\/a>. Para expor as constantes p\u00fablicas, precisamos de adicionar as constantes, por exemplo packages\/users\/app\/public.<\/code>Para j\u00e1, vamos definir esta configura\u00e7\u00e3o para falso<\/em>.<\/p>\n\n\n\nimpor_depend\u00eancias<\/code> ir\u00e1 impor a depend\u00eancia de um pacote e verificar todas as refer\u00eancias constantes. Se uma depend\u00eancia n\u00e3o for explicitamente definida, ser\u00e1 uma viola\u00e7\u00e3o do limite.<\/p>\n\n\n\nValida\u00e7\u00e3o do sistema de pacotes<\/h3>\n\n\n\n
Packwerk<\/strong> estabeleceu um crit\u00e9rio que temos de seguir para termos um sistema de pacotes v\u00e1lido. Podemos come\u00e7ar a executar packwerk validado<\/code> na nossa consola.<\/p>\n\n\n\n Isto ir\u00e1 verificar a nossa estrutura de pastas, configura\u00e7\u00e3o do pacote<\/strong>e cache de caminho de carregamento autom\u00e1tico.<\/p>\n\n\n\nNeste momento, a nossa aplica\u00e7\u00e3o n\u00e3o \u00e9 v\u00e1lida e temos de corrigir os caminhos de carregamento empackwerk.yml<\/code>.<\/strong> Para o fazer, s\u00f3 temos de acrescentar os caminhos em falta.<\/p>\n\n\n\n# packwerk.yml\n\nload_paths:\n.\n.\n.\n\n# Utilizadores\n- app\/pacotes\/utilizadores\/controladores\n- app\/pacotes\/utilizadores\/modelos\n- app\/pacotes\/utilizadores\/pacote.yml\n- app\/pacotes\/utilizadores\/visualiza\u00e7\u00f5es<\/code><\/pre>\n\n\n\nNesta altura, estamos prontos para verificar as viola\u00e7\u00f5es de limites na nossa aplica\u00e7\u00e3o. Para verificar as viola\u00e7\u00f5es, podemos executarpackwerk update-deprecations<\/code> , este comando ir\u00e1 gerar deprecated_references.yml<\/code> para cada pacote. Em cada ficheiro, encontraremos o nome do pacote, o tipo de viola\u00e7\u00e3o e o caminho do ficheiro. Com todas estas informa\u00e7\u00f5es, sabemos onde est\u00e1 a ocorrer a viola\u00e7\u00e3o e podemos tomar uma decis\u00e3o para a resolver.<\/p>\n\n\n\n![\"deprecated_references.yml\"](\"\/app\/uploads\/2024\/05\/4.png\" "\\"exemplo")
<\/figure>\n\n\n\n# deprecated_references.yml\n\n.\n.\n.\n\napp\/packages\/repos:\n \"::Repo\":\n viola\u00e7\u00f5es:\n - depend\u00eancia\n ficheiros:\n - app\/packages\/users\/models\/user.rb<\/code><\/pre>\n\n\n\nTomando o exemplo, vamos descrever cada parte da informa\u00e7\u00e3o gerada
por Packwerk<\/strong>.<\/p>\n\n\n\n- app\/pacotes\/repos<\/code> - pacote onde a viola\u00e7\u00e3o constante \u00e9
encontrado.<\/p>\n\n\n\n- ::Repo<\/code> - caminho para o ficheiro que cont\u00e9m a constante violada.<\/p>\n\n\n\n- depend\u00eancia<\/code> - um tipo de viola\u00e7\u00e3o, seja de depend\u00eancia ou de privacidade.<\/p>\n\n\n\n- app\/packages\/users\/models\/user.rb<\/code> - caminho para o ficheiro que cont\u00e9m a constante violada.<\/p>\n\n\n\nComo passo final nesta sec\u00e7\u00e3o, n\u00e3o se esque\u00e7a de adicionar os novos caminhos de ficheiros gerados ao packwerk.ym<\/code>l e executar novamente as valida\u00e7\u00f5es.<\/p>\n\n\n\nVisualiza\u00e7\u00e3o de depend\u00eancias<\/h3>\n\n\n\n
Com todas as informa\u00e7\u00f5es em package.yml e deprecated_references.yml<\/code>podemos ent\u00e3o
visualizar um gr\u00e1fico de depend\u00eancias. Para isso, precisamos de adicionar outra gem, neste caso vamos usar Pocky<\/a>.<\/p>\n\n\n\nAncinho de corrida pocky:gerar<\/code> vamos gerar um ficheiro chamado packwerk.png<\/code> onde podemos visualizar o nosso primeiro gr\u00e1fico de depend\u00eancias.<\/p>\n\n\n\nCom todos os pacotes definidos, o nosso gr\u00e1fico ter\u00e1 o seguinte aspeto.<\/p>\n\n\n\n![\"gr\u00e1fico](\"\/app\/uploads\/2024\/05\/5.png\" "\\"exemplo")
<\/figure>\n\n\n\nas depend\u00eancias j\u00e1 existem, mas isso n\u00e3o significa que sejam aceites pelo Packwerk<\/strong>. Para
aceitar uma depend\u00eancia, precisamos de adicionar a configura\u00e7\u00e3o das depend\u00eancias ao package.yml<\/code>
em cada pacote. Concentrar-nos-emos em criadores de correio<\/code> uma vez que se trata de um pacote sem depend\u00eancia circular. Vale a pena mencionar que Packwerk<\/strong> n\u00e3o nos deixa aceitar depend\u00eancias circulares.<\/p>\n\n\n\n# app\/packages\/mail_builders\/package.yml\n\n```rubi\nenforce_privacy: false\nenforce_dependencies: true\ndepend\u00eancias:\n- app\/packages\/docs\n- app\/pacotes\/assuntos\n- app\/pacotes\/repos<\/code><\/pre>\n\n\n\nDepois de adicionar esta configura\u00e7\u00e3o, Pocky<\/strong> ir\u00e1 colorir de verde as depend\u00eancias aceites.<\/p>\n\n\n\n![\"gr\u00e1fico](\"\/app\/uploads\/2024\/05\/6.png\" "\\"exemplo")
<\/figure>\n\n\n\nPodemos apagar deprecated_references.yml<\/code> de app\/packages\/mail_builders<\/code> e executar
packwerk update-deprecations<\/code> novamente. O ficheiro n\u00e3o ser\u00e1 gerado novamente, uma vez que todos os
foram corrigidas para este pacote. \u00c9 importante mencionar que mesmo que n\u00e3o fa\u00e7amos o Graph com depend\u00eancias aceites<\/p>\n\n\n\nRubi<\/a> modulariza\u00e7\u00e3o em Rails com Packwerk<\/strong> aceitar depend\u00eancias, a nossa aplica\u00e7\u00e3o continuar\u00e1 a funcionar como antes, mas agora temos mais
informa\u00e7\u00f5es para tomar decis\u00f5es e refactorizar.<\/p>\n\n\n\nRemover depend\u00eancias circulares<\/h3>\n\n\n\n
No nosso gr\u00e1fico anterior, t\u00ednhamos muitas depend\u00eancias circulares que precisavam de ser resolvidas de alguma forma. Temos diferentes estrat\u00e9gias para o fazer:<\/p>\n\n\n\n
- N\u00e3o fazer nada,<\/p>\n\n\n\n
- Aceitar depend\u00eancias, Mesclar pacotes,<\/p>\n\n\n\n
- Mover c\u00f3digo<\/a> entre pacotes,<\/p>\n\n\n\n- Duplicar uma funcionalidade, <\/p>\n\n\n\n
- Executar inje\u00e7\u00e3o de depend\u00eancia ou inje\u00e7\u00e3o de depend\u00eancia com tipagem.<\/p>\n\n\n\n
Uma quest\u00e3o aqui \u00e9 que, para fazer uma refac\u00e7\u00e3o adequada, precisamos de conhecer a base de c\u00f3digo. N\u00e3o estou muito familiarizado com a base de c\u00f3digo deste projeto, uma vez que o tomei como exemplo, por isso, por raz\u00f5es pr\u00e1ticas, vamos optar pela primeira estrat\u00e9gia, n\u00e3o fazer nada. Mesmo que evitemos a maior parte da refatora\u00e7\u00e3o, queremos trabalhar nas depend\u00eancias do raiz<\/em> pacote.<\/p>\n\n\n\nO pacote raiz cont\u00e9m toda a cola do pacote Estrutura Rails<\/strong>Todas as classes de que herdamos e fazemos com que todas trabalhem em conjunto. Assim, para resolver as depend\u00eancias circulares, vamos criar um novo pacote chamado rails nos seguintes passos:<\/p>\n\n\n\n\n- Mover todos os ficheiros e pastas da aplica\u00e7\u00e3o_ da aplica\u00e7\u00e3o para
app\/pacotes\/rails<\/code>.<\/li>\n\n\n\n- Criar um
package.yml<\/code> para o pacote com a mesma configura\u00e7\u00e3o que os pacotes anteriores.<\/li>\n\n\n\n- Adicione todos os novos caminhos de ficheiro a
packwerk.yml<\/code>.<\/li>\n\n\n\n- Adicionar
app\/pacotes\/rails<\/code> como uma depend\u00eancia do resto dos pacotes.<\/li>\n<\/ol>\n\n\n\nAssim que criarmos o pacote, come\u00e7aremos a reparar em muitos ficheiros que podem ser reestruturados. Depois de mover tudo para o pacote correspondente e aceitar o
teremos uma nova estrutura e um gr\u00e1fico mais limpo.<\/p>\n\n\n\n![\"Estrutura](\"\/app\/uploads\/2024\/05\/graph.png\" "\\"Estrutura")
<\/figure>\n\n\n\n![\"Gr\u00e1fico](\"\/app\/uploads\/2024\/05\/8.png\" "\\"Exemplo")
<\/figure>\n\n\n\nRemover depend\u00eancias do pacote raiz<\/h3>\n\n\n\n
Agora nosso gr\u00e1fico parece muito melhor, seria \u00f3timo se pud\u00e9ssemos remover todas as depend\u00eancias do pacote raiz. Se verificarmos o deprecated_references.yml no pacote raiz, notaremos que a maioria delas s\u00e3o do teste<\/code> , lib\/tasks<\/code> , db<\/code> e configura\u00e7\u00e3o<\/code>
pasta. Para resolver estas depend\u00eancias, vamos criar uma pasta de teste dentro de cada pacote. Ter algo como app\/pacotes\/utilizadores\/teste<\/code>. De seguida, vamos excluir lib\/tasks<\/code> , db<\/code> e configura\u00e7\u00e3o<\/code>entre outras pastas de Packwerk<\/strong> uma vez que essas depend\u00eancias n\u00e3o s\u00e3o realmente importantes na nossa an\u00e1lise e n\u00e3o temos uma forma f\u00e1cil de as resolver. Vamos adicionar o seguinte ao nosso packwerk.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\nDepois de mover todos os testes do pacote raiz e excluir as pastas da an\u00e1lise, teremos um novo gr\u00e1fico sem as depend\u00eancias raiz.<\/p>\n\n\n\n![\"Gr\u00e1fico](\"\/app\/uploads\/2024\/05\/9.png\" "\\"Gr\u00e1fico")
<\/figure>\n\n\n\nComo podemos ver, continuamos a ter depend\u00eancias circulares emutilizadores<\/code> , reposit\u00f3rios<\/code> e documentos<\/code> . Embora n\u00e3o as tenhamos resolvido, temos informa\u00e7\u00f5es importantes para transmitir agora. Sabemos que todos os equipa<\/a> que realiza mudan\u00e7as em um desses pacotes provavelmente ter\u00e1 que realizar mudan\u00e7as nos pacotes com a depend\u00eancia circular. Por outro lado, sabemos que uma equipa pode trabalhar em github_fetchers<\/code> apenas, saber quais s\u00e3o os pacotes
sendo afetado pelas mudan\u00e7as em cada momento.<\/p>\n\n\n\nPode encontrar o resultado final do projeto aqui<\/a>.<\/p>\n\n\n\nPr\u00f3ximo passo<\/h3>\n\n\n\n
Como pr\u00f3ximo passo, pode impor uma privacidade constante em cada pacote e expor apenas a API p\u00fablica que ser\u00e1 acess\u00edvel a partir de outros pacotes. Voc\u00ea pode facilmente configurar onde sua API ser\u00e1 colocada em package.yml<\/em>.<\/p>\n\n\n\nenforce_privacy: true\nenforce_dependencies: true\npublic_path: my\/custom\/path\/<\/code><\/pre>\n\n\n\n <\/code><\/p>\n\n\n\nConclus\u00f5es<\/h2>\n\n\n\n
Packwerk<\/strong> d\u00e1-nos muitas informa\u00e7\u00f5es sobre a nossa aplica\u00e7\u00e3o e, com essas informa\u00e7\u00f5es, podemos tomar decis\u00f5es para melhorar o fluxo de trabalho das nossas equipas. Embora o processo pare\u00e7a ser longo e com muitas configura\u00e7\u00f5es, n\u00e3o precisa de ser sempre assim. Podemos come\u00e7ar a criar pacotes apenas para o novo c\u00f3digo adicionado \u00e0 nossa aplica\u00e7\u00e3o e depois modularizar gradualmente. Ent\u00e3o agora podemos come\u00e7ar a falar sobre Modulariza\u00e7\u00e3o Gradual, este \u00e9 o conceito introduzido por Stephan Hagemann \"Podemos, pela primeira vez, decidir come\u00e7ar a modularizar uma parte do c\u00f3digo de uma forma aspiracional... Isto permite-nos criar um sistema de apoio que se expande gradualmente em dire\u00e7\u00e3o a uma melhor estrutura de aplica\u00e7\u00e3o\".<\/em><\/p>\n\n\n\nFontes<\/h2>\n\n\n\n\n- Modulariza\u00e7\u00e3o gradual para Ruby on Rails - Stephan Hagemann<\/a><\/li>\n\n\n\n
- Impondo modularidade em aplica\u00e7\u00f5es Rails com Packwerk<\/a><\/li>\n\n\n\n
- Packwerk Github<\/a><\/li>\n\n\n\n
- C\u00f3digo fonte do artigo<\/a><\/li>\n<\/ol>\n\n\n\n
![\"Consultoria](\"\/app\/uploads\/2024\/05\/cta_2.jpeg\")
<\/a><\/figure>\n\n\n\nLer mais<\/strong><\/p>\n\n\n\nRuby GraphQL. E quanto ao desempenho?<\/a><\/p>\n\n\n\n