app\/paquetes<\/code> donde colocaremos todos nuestros paquetes. Para aislar nuestros paquetes tenemos que separar cada Concepto MVC<\/strong> en una carpeta. Tomando la CodeTriage proyecto<\/a><\/strong> como ejemplo tendremos algo como la siguiente imagen.<\/p>\n\n\n\n![\"estructura](\"\/app\/uploads\/2024\/05\/2.png\" "\\"ejemplo")
<\/figure>\n\n\n\nSi intentamos ejecutar el servidor, no encontrar\u00e1 las constantes. Es por eso que tenemos que a\u00f1adir una l\u00ednea de configuraci\u00f3n a nuestra application.rb<\/code><\/p>\n\n\n\nconfig.paths.add 'app\/paquetes', glob: '*\/{*,*\/preocupaciones}', eager_load:true<\/code><\/pre>\n\n\n\nAhora la aplicaci\u00f3n funciona, pero no puede encontrar las vistas, por lo que tenemos que a\u00f1adir otra l\u00ednea de configuraci\u00f3n a nuestro application_controller.rb<\/code><\/p>\n\n\n\nappend_view_path(Dir.glob(Rieles<\/a>.root.join('app\/paquetes\/*\/vistas')))<\/code><\/pre>\n\n\n\n<\/p>\n\n\n\n
Crear los paquetes<\/h3>\n\n\n\n
Nuestra estructura est\u00e1 lista, as\u00ed que ahora podemos empezar a crear los paquetes. Para ello, s\u00f3lo tenemos que a\u00f1adir unpaquete.yml<\/code> a cada carpeta con la siguiente configuraci\u00f3n:<\/p>\n\n\n\nenforce_privacy: false\nenforce_dependencies: true<\/code><\/pre>\n\n\n\n<\/p>\n\n\n\n![\"paquete.yml\"](\"\/app\/uploads\/2024\/05\/1.png\" "\\"package.yml")
<\/figure>\n\n\n\nreforzar_la_privacidad<\/code>da us<\/a> la posibilidad de aislar todas las constantes del paquete y trabajar con un p\u00fablico API<\/a>. Para exponer las constantes p\u00fablicas, necesitamos a\u00f1adir las constantes en, por ejemplo packages\/users\/app\/public.<\/code>Por ahora vamos a establecer esta configuraci\u00f3n en falso<\/em>.<\/p>\n\n\n\naplicar_dependencias<\/code> impondr\u00e1 la dependencia de un paquete y comprobar\u00e1 todas las referencias constantes. Si una dependencia no est\u00e1 definida expl\u00edcitamente ser\u00e1 una violaci\u00f3n del l\u00edmite.<\/p>\n\n\n\nValidaci\u00f3n del sistema de paquetes<\/h3>\n\n\n\n
Packwerk<\/strong> estableci\u00f3 un criterio que debemos seguir para tener un sistema de paquetes v\u00e1lido. Podemos empezar a ejecutar packwerk validate<\/code> en nuestra consola.<\/p>\n\n\n\n Esto comprobar\u00e1 nuestra estructura de carpetas, configuraci\u00f3n del paquete<\/strong>y autocargar la cach\u00e9 de rutas.<\/p>\n\n\n\nAhora mismo, nuestra aplicaci\u00f3n no es v\u00e1lida y tenemos que arreglar las rutas de carga enpackwerk.yml<\/code>.<\/strong> Para ello, s\u00f3lo tenemos que a\u00f1adir las rutas que faltan.<\/p>\n\n\n\n# packwerk.yml\n\nrutas_carga:\n.\n.\n.\n\n# Usuarios\n- app\/paquetes\/usuarios\/controladores\n- app\/paquetes\/usuarios\/modelos\n- app\/paquetes\/usuarios\/paquete.yml\n- app\/paquetes\/usuarios\/vistas<\/code><\/pre>\n\n\n\nEn este punto, estamos listos para comprobar las violaciones de los l\u00edmites en nuestra aplicaci\u00f3n. Para comprobar las violaciones podemos ejecutarpackwerk update-deprecations<\/code> este comando generar\u00e1 deprecated_references.yml<\/code> para cada paquete. En cada archivo encontraremos el nombre del paquete, el tipo de violaci\u00f3n y la ruta del archivo. Con toda esta informaci\u00f3n sabemos d\u00f3nde se est\u00e1 produciendo la infracci\u00f3n y podemos tomar una decisi\u00f3n para resolverla.<\/p>\n\n\n\n![\"deprecated_references.yml\"](\"\/app\/uploads\/2024\/05\/4.png\" "\\"deprecated_references.yml")
<\/figure>\n\n\n\n# deprecated_references.yml\n\n.\n.\n.\n\napp\/paquetes\/repos:\n \"::Repo\":\n :\n - dependencia\n files:\n - app\/paquetes\/usuarios\/modelos\/usuario.rb<\/code><\/pre>\n\n\n\nTomando el ejemplo vamos a describir cada parte de la informaci\u00f3n generada
por Packwerk<\/strong>.<\/p>\n\n\n\n- app\/paquetes\/repos<\/code> - donde la violaci\u00f3n constante es
encontrado.<\/p>\n\n\n\n- ::Repo<\/code> - ruta al archivo que contiene la constante violada.<\/p>\n\n\n\n- dependencia<\/code> - un tipo de violaci\u00f3n, ya sea de la dependencia o de la intimidad.<\/p>\n\n\n\n- app\/paquetes\/usuarios\/modelos\/usuario.rb<\/code> - ruta al archivo que contiene la constante violada.<\/p>\n\n\n\nComo paso final de esta secci\u00f3n, no olvide a\u00f1adir las nuevas rutas de archivo generadas a packwerk.ym<\/code>l y vuelva a ejecutar las validaciones.<\/p>\n\n\n\nVisualizaci\u00f3n de la dependencia<\/h3>\n\n\n\n
Con toda la informaci\u00f3n en package.yml y deprecated_references.yml<\/code>podemos entonces
visualizar un gr\u00e1fico de dependencias. Para ello necesitamos a\u00f1adir otra gema, en este caso usaremos Pocky<\/a>.<\/p>\n\n\n\nRastrillo pocky:generar<\/code> generaremos un archivo llamado packwerk.png<\/code> donde podemos visualizar nuestro primer gr\u00e1fico de dependencias.<\/p>\n\n\n\nCon todos los paquetes definidos nuestro gr\u00e1fico tendr\u00e1 este aspecto.<\/p>\n\n\n\n![\"gr\u00e1fico](\"\/app\/uploads\/2024\/05\/5.png\" "\\"ejemplo")
<\/figure>\n\n\n\ndependencias ya existen, pero eso no significa que sean aceptadas por Packwerk<\/strong>. A
aceptar una dependencia tenemos que a\u00f1adir la configuraci\u00f3n de dependencias al archivo paquete.yml<\/code>
en cada paquete. Nos centraremos en mail_builders<\/code> ya que es un paquete sin dependencia circular. Cabe mencionar que Packwerk<\/strong> no nos permitir\u00e1 aceptar dependencias circulares.<\/p>\n\n\n\n# app\/paquetes\/mail_builders\/paquete.yml\n\n```ruby\nenforce_privacy: false\nenforce_dependencies: true\ndependencias:\n- app\/paquetes\/docs\n- app\/paquetes\/temas\n- app\/paquetes\/repositorios<\/code><\/pre>\n\n\n\nDespu\u00e9s de a\u00f1adir esta configuraci\u00f3n, Pocky<\/strong> colorear\u00e1 en verde las dependencias aceptadas.<\/p>\n\n\n\n![\"gr\u00e1fico](\"\/app\/uploads\/2024\/05\/6.png\" "\\"ejemplo")
<\/figure>\n\n\n\nPodemos eliminar deprecated_references.yml<\/code> de app\/paquetes\/mail_builders<\/code> y ejecuta
packwerk update-deprecations<\/code> de nuevo. El archivo no se generar\u00e1 de nuevo ya que todos los
para este paquete. Es importante mencionar que aunque no Graph con dependencias aceptadas<\/p>\n\n\n\nRuby<\/a> modularizaci\u00f3n on Rails con Packwerk<\/strong> aceptar dependencias nuestra aplicaci\u00f3n seguir\u00e1 funcionando como antes, pero ahora tenemos m\u00e1s
informaci\u00f3n para tomar decisiones y refactorizar.<\/p>\n\n\n\nEliminar las dependencias circulares<\/h3>\n\n\n\n
En nuestro gr\u00e1fico anterior, ten\u00edamos muchas dependencias circulares que hab\u00eda que resolver de alguna manera. Tenemos diferentes estrategias para hacerlo:<\/p>\n\n\n\n
- No hacer nada,<\/p>\n\n\n\n
- Aceptar dependencias, Fusionar paquetes,<\/p>\n\n\n\n
- Desplazamiento c\u00f3digo<\/a> entre paquetes,<\/p>\n\n\n\n- Duplicar una funcionalidad, <\/p>\n\n\n\n
- Realizar inyecci\u00f3n de dependencias o inyecci\u00f3n de dependencias con tipado.<\/p>\n\n\n\n
Una cuesti\u00f3n aqu\u00ed es que para hacer una refactorizaci\u00f3n adecuada, necesitamos conocer el c\u00f3digo base. No estoy muy familiarizado con la base de c\u00f3digo de este proyecto, ya que lo tom\u00e9 como ejemplo, as\u00ed que por razones pr\u00e1cticas vamos a ir con la primera estrategia, no hacer nada. Incluso si vamos a evitar la mayor parte de la refactorizaci\u00f3n, queremos trabajar en las dependencias en el ra\u00edz<\/em> paquete.<\/p>\n\n\n\nEl paquete ra\u00edz contiene toda la cola del Marco Rails<\/strong>, todas las clases de las que heredamos y hacemos que funcionen todas juntas. Por lo tanto, con el fin de resolver las dependencias circulares, vamos a crear un nuevo paquete llamado rieles dentro de los siguientes pasos:<\/p>\n\n\n\n\n- Mueve todos los archivos y carpetas de la aplicaci\u00f3n_ a
app\/paquetes\/rails<\/code>.<\/li>\n\n\n\n- Crear un
paquete.yml<\/code> para el paquete con la misma configuraci\u00f3n que los paquetes anteriores.<\/li>\n\n\n\n- A\u00f1ade todas las nuevas rutas de archivos a
packwerk.yml<\/code>.<\/li>\n\n\n\n- A\u00f1adir
app\/paquetes\/rails<\/code> como dependencia del resto de paquetes.<\/li>\n<\/ol>\n\n\n\nUna vez creado el paquete empezaremos a notar una gran cantidad de archivos que pueden ser reestructurados. Despu\u00e9s de mover todo al paquete correspondiente y aceptar
dependencias tendremos una nueva estructura y un gr\u00e1fico m\u00e1s limpio.<\/p>\n\n\n\n![\"Estructura](\"\/app\/uploads\/2024\/05\/graph.png\" "\\"Ejemplo")
<\/figure>\n\n\n\n![\"Gr\u00e1fico](\"\/app\/uploads\/2024\/05\/8.png\" "\\"Ejemplo")
<\/figure>\n\n\n\nEliminar dependencias del paquete ra\u00edz<\/h3>\n\n\n\n
Ahora nuestro gr\u00e1fico se ve mucho mejor, ser\u00eda genial si pudi\u00e9ramos eliminar todas las dependencias del paquete ra\u00edz. Si comprobamos deprecated_references.yml en el paquete ra\u00edz, nos daremos cuenta de que la mayor\u00eda de ellas son de prueba<\/code> , lib\/tareas<\/code> , db<\/code> y config<\/code>
carpeta. Para resolver estas dependencias, vamos a crear una carpeta de prueba dentro de cada paquete. Tener algo como app\/paquetes\/usuarios\/prueba<\/code>. A continuaci\u00f3n, vamos a excluir lib\/tareas<\/code> , db<\/code> y config<\/code>entre otras carpetas de Packwerk<\/strong> ya que esas dependencias no son realmente importantes en nuestro an\u00e1lisis y no tenemos una forma f\u00e1cil de resolverlas. A\u00f1adiremos lo siguiente a nuestro packwerk.yml<\/em>.<\/p>\n\n\n\nexcluir:\n- \"{bin,node_modules,script,tmp,vendor,lib,db,config,perf_scripts}\/**\/*\"\n- \"lib\/tasks\/**\/*.rake\"<\/code><\/pre>\n\n\n\nDespu\u00e9s de mover todas las pruebas del paquete ra\u00edz y excluir las carpetas del an\u00e1lisis tendremos un nuevo gr\u00e1fico sin dependencias ra\u00edz.<\/p>\n\n\n\n![\"Gr\u00e1fico](\"\/app\/uploads\/2024\/05\/9.png\" "\\"Gr\u00e1fico")
<\/figure>\n\n\n\nComo vemos, seguimos teniendo dependencias circulares enusuarios<\/code> , repos<\/code> y docs<\/code> . Aunque no los resolvimos, ahora tenemos informaci\u00f3n importante que transmitir. Sabemos que cada equipo<\/a> que realice cambios en uno de esos paquetes probablemente tendr\u00e1 que realizar cambios en los paquetes con la dependencia circular. Por otro lado, sabemos que un equipo puede trabajar en github_fetchers<\/code> \u00fanicamente, saber qu\u00e9 paquetes son
vi\u00e9ndose afectado por los cambios de cada momento.<\/p>\n\n\n\nPuede consultar el resultado final del proyecto aqu\u00ed<\/a>.<\/p>\n\n\n\nSiguiente paso<\/h3>\n\n\n\n
Como siguiente paso, podr\u00edas imponer una privacidad constante en cada paquete y exponer s\u00f3lo la API p\u00fablica que ser\u00e1 accesible desde otros paquetes. Puedes configurar f\u00e1cilmente d\u00f3nde se colocar\u00e1 tu API en paquete.yml<\/em>.<\/p>\n\n\n\nenforce_privacy: true\nenforce_dependencies: true\npublic_path: mi\/ruta\/personalizada\/<\/code><\/pre>\n\n\n\n <\/code><\/p>\n\n\n\nConclusiones<\/h2>\n\n\n\n
Packwerk<\/strong> nos da mucha informaci\u00f3n sobre nuestra aplicaci\u00f3n y con esa informaci\u00f3n podemos tomar decisiones para mejorar el flujo de trabajo de nuestros equipos. Aunque el proceso parec\u00eda largo y con muchas configuraciones, no tiene por qu\u00e9 ser as\u00ed siempre. Podemos empezar creando paquetes s\u00f3lo para el nuevo c\u00f3digo que se a\u00f1ada a nuestra aplicaci\u00f3n y luego modularizar poco a poco. As\u00ed que ahora podemos empezar a hablar de Modularizaci\u00f3n Gradual este es el concepto introducido por Stephan Hagemann \"Podemos, por primera vez, decidir empezar a modularizar una parte del c\u00f3digo de forma aspiracional... Esto nos permite crear un sistema de apoyo que se ampl\u00eda gradualmente hacia una mejor estructura de la aplicaci\u00f3n\".<\/em><\/p>\n\n\n\nFuentes<\/h2>\n\n\n\n\n- Modularizaci\u00f3n gradual para Ruby on Rails - Stephan Hagemann<\/a><\/li>\n\n\n\n
- Modularidad en aplicaciones Rails con Packwerk<\/a><\/li>\n\n\n\n
- Packwerk Github<\/a><\/li>\n\n\n\n
- C\u00f3digo fuente del art\u00edculo<\/a><\/li>\n<\/ol>\n\n\n\n
![\"Consultor\u00eda](\"\/app\/uploads\/2024\/05\/cta_2.jpeg\")
<\/a><\/figure>\n\n\n\nSeguir leyendo<\/strong><\/p>\n\n\n\nGraphQL Ruby. \u00bfY el rendimiento?<\/a><\/p>\n\n\n\nFerrocarriles y otros medios de transporte<\/a><\/p>\n\n\n\n