¿Cómo organizar y mantener nuestros repositorios Ruby/Rails?
Al desarrollar aplicaciones Ruby/Rails, solemos utilizar Git como gestor de versiones (de hecho, al crear una aplicación Rails automáticamente se genera un repositorio Git en el directorio). Como todo proceso colaborativo e iterativo, es muy importante que mantengamos el orden y la documentación pertinentes en nuestro proyecto, así como también respetar todas las buenas prácticas de las tecnologías utilizadas.
Estos aspectos no son exclusivos de un desarrollo Ruby, sino que es válido para todo proyecto de software. Incluso aplica cuando la única persona que forma parte del mismo somos nosotros, ya que nuestras versiones del futuro van a tener que volver al repositorio, y si eso sucede es mejor tenerlo ordenado y documentado (créanme, no es lindo enojarse con nuestras versiones del pasado).
Dicho todo lo anterior, propongo algunas máximas para seguir a la hora de construir y mantener proyectos Ruby/Rails, que nos ayudarán a mantenerlo a lo largo del tiempo.
Usemos las versiones estables más recientes de forma prudencial
Tanto Ruby como Rails tienen una inmensa comunidad de personas que apoyan y mantienen los proyectos, así como también agregando nuevas características, mejorando su rendimiento o implementando parches de seguridad. Es por eso que deberíamos siempre usar las versiones más recientes de Ruby y de Rails.
Obviamente es importante usar las versiones de forma prudencial, considerando los major versions de cada tecnología (ejemplos: salto de Ruby 2 a Ruby 3, o de Rails 6 a Rails 7). Por ejemplo, a día de la fecha, Rails 7 fue lanzado hace algunos meses: no tiene mucho uso en el mercado que justifique pegar el salto, ni tampoco gente con experiencia en nuestras empresas como para dar soporte a las dudas de compatibilidad que surjan en las resoluciones de las unidades.
Esto no significa que tengamos que esperar años hasta usar la última versión Rails, y de hecho está bueno probarlo, pero siempre decidamos a consciencia. ¿Dónde conviene probarlo? Sistemas internos o con muy poca dependencia respecto a gemas y librerías externas, trainings o workshops para chequear las nuevas funcionalidades.
¿Querés saber qué novedades traen en Ruby 3.1 y Rails 7? Podés verlas en este artículo (en inglés).
Respetemos estilos de código
En todo lenguaje de programación, existen guías de estilo que sirven como orientación para que todos las personas dentro de una organización o comunidad utilicen las mismas reglas a la hora de escribir código. La idea detrás de una guía de estilos no es que todas las personas programen igual, sino que sigan los mismos patrones, estándares y reglas para colaborar con un lenguaje común de forma tal de favorecer la mantenibilidad y expresividad.
Ruby es un lenguaje de programación sumamente expresivo, pero no por ello está exento de código ilegible o poco mantenible. Al fin y al cabo, ¡los que programamos somos humanos! Para suerte de toda la comunidad, contamos con la guía de estilos de Rubocop. No es imprescindible sabérsela toda de memoria (¿es realmente posible eso?), pero es muy valioso leerla al menos una vez, e intentar seguir sus reglas. Pero esto no termina acá, ya que también disponemos de una guía de estilos para Ruby on Rails (sí, también estaría bueno leerla al menos una vez, y luego volver a ella e incorporarla con la práctica).
Todo esto es muy bueno, pero es cierto que es prácticamente imposible acordarnos de todas las reglas existentes, y más cuando recién las estamos incorporando. Es por ello que contamos con una gema Ruby que analiza nuestro código, lo compara con las guías de estilo y nos indica las ofensas que cometimos.
Para empezar a usar Rubocop como analizador de código en nuestros proyectos, basta con agregar estas gemas al Gemfile (si es un proyecto Rails, deberían ubicarse dentro del grupo de development).
Luego, disponemos de varios comandos para detectar y potencialmente auto-corregir ofensas (en función de su naturaleza, algunas las tendremos que corregir manualmente):
Aunque exista Rubocop, esto no significa que uno debe seguir todos los estilos que propone, sino que debe verse como una herramienta para estandarizar ciertas prácticas en un proyecto. Dado que cada empresa u organización tiene sus propias convenciones y gustos para programar, Rubocop permite la edición de sus reglas para amoldarlas a cada preferencia. Para tal fin, es necesario crear en la raíz de nuestro proyecto un archivo .rubocop.yml indicando qué reglas queremos sobrescribir (considerando que estas son las que vienen por defecto).
Puede servir como ejemplo este archivo de configuración.
Documentemos
Los proyectos siempre funcionan bien en la computadora de quien lo implementa, pero eso no es necesariamente así para quienes lo tienen que poner en marcha. Ya sea en el README del proyecto como con archivos de configuración, debemos indicar qué versión de cada tecnología estamos utilizando.
Para el caso de aplicaciones Ruby/Rails, tenemos que agregar un archivo .ruby-version que indique la versión de Ruby. A su vez, para los proyectos de Rails en los que se use Webpacker (podría ser en cualquier Rails 5+, y por defecto en todos los Rails 6+), deberíamos agregar un archivo .nvmrc para determinar la versión de Node.
El archivo ruby-version es el que lee y usa rbenv, mientras que el .nvmrc es el propio de nvm.
Más allá de lo anterior, nunca está de más indicar en el README de un repositorio qué tecnologías principales se utilizan, junto con las versiones de cada una de ellas. ¿Tu proyecto tiene alguna particularidad en su puesta en marcha? Bueno, es un gran indicio para agregarlo también al README.
Usemos Git correctamente
Este punto no es exclusivo de repositorios Ruby/Rails, y seguramente necesitará un artículo aparte para abordarlo correctamente, pero no por eso vamos a obviarlo: el buen uso de Git es tan relevante como el de cada una de las tecnologías implicadas en el repositorio.
Es muy importante mantener la consistencia y la prolijidad a la hora de usar ramas o definir nombres de commits. Como punto de partida, todos los repositorios deberían tener una rama por defecto main (no usemos master), de la cual partirán nuestras ramas de desarrollo: features, hotfixes/bugs, dependencies, documentation y demás, en función de lo que queramos resolver en cada una de ellas.
En cuanto a los commits, idealmente deberíamos escribirlos en inglés conjugados en presente simple. Tienen que ser representativos de lo que están encapsulando. ¿Y qué pasa si resolví dos cosas? Bueno, serán dos commits, si es que no necesitás dos ramas. Algunos ejemplos de nombres de commits pueden ser los siguientes:
Nuestro repositorio tiene que ser visto como la historia de modificación de nuestro código a lo largo del tiempo, donde cada commit resume qué es lo que cambia. Después podremos analizar si es mejor y más legible usar rebase en lugar de merge, pero lo más básico es cómo nomenclar y ordenar tanto nuestras ramas como sus commits.
Conclusión
Los repositorios son espacios donde se aloja el código, y más allá de que luego sea ejecutado por una máquina, es trabajado y mantenido por humanos. Es por eso que necesitamos que sea legible, fácil de interpretar y que entregue toda la información relevante como para que otra persona no solo lo entienda rápidamente, sino también ejecutarlo en su computadora.
Espero que encuentres este artículo útil y nos encantaría escuchar acerca de tu experiencia y sugerencias en el mantenimiento de repositorios Ruby/Rails.
Si te gustó este artículo, entonces quizás te podría interesar alguno de estos:
