Una de las prácticas más importantes dentro del desarrollo de software sin duda alguna son los code reviews. La manera en cómo se llevan a cabo las revisiones de código no están escritas en piedra pero tienen un objetivo en común: Mejorar la calidad de código y comprobar su funcionamiento.
En lo personal he pasado por varios equipos de desarrollo los cuales por iniciativa propia establecen sus propias reglas de revision de código, también me ha tocado participar en equipos cuyo procedimiento de revisión de código ya tiene una metodología empresarial para todos sus equipos de desarrollo, pero, ¿como son los code reviews en un equipo de ingeniería de datos?
Bueno, la realidad es que los ingenieros de datos también desarrollamos software y producimos código. Este código nos ayuda en la creación de data pipelines para extraer, transformar y cargar los datos de una fuente a otra. También creamos procesos o workflows para transformar y generar nuevos datos con los ya existentes …. Y no solo eso, creamos nuestra propias librerías, paquetes, y aplicaciones, entre otras cosas, que nos facilitan la utilización de herramientas del día a día.
Dicho lo anterior, es más que necesario establecer una práctica de revisión de código que nos ayudará a entregar código de calidad y completamente funcional.
¿Como debe ser un code review?
Como lo mencione antes, no está escrito en piedra la manera en cómo se lleva a cabo esta práctica. A todos los equipos de trabajo por los que he pasado les he aprendido buenas y malas prácticas y he aquí mi humilde opinión al respecto:
Tenemos tres actores principales, el reviewer (el que revisa, pueden ser varios), el submitter (desarrollador… también pueden ser varios) y la plataforma de control de versiones (normalmente Github)
Lo que debe cumplir el submitter:
- Buenas practicas de programación:
- Código documentado
- Indentación según los estándares (tab, espacios)
- Buen/claro nombramiento de clases, funciones y variables
- Evitar repetir código
- … y muchas otras más!
- Hacer un Pull Request bien detallado
- Escribir la descripción del feature, bug, mejora, que se está mandando a revisión.
- Describir cómo se puede hacer testing del código. Lo ideal es que el reviewer pueda reproducir la funcionalidad del feature, bug, o mejora en su ambiente local para poder dar veracidad del funcionamiento.
- Asignar reviewers al pull request. Puede ser uno o varios dependiendo de las reglas que hayan establecido para ello.
Lo que debe cumplir el reviewer:
- Dar fe del funcionamiento del código. Siguiendo la serie de pasos descritos en el pull request para hacer el testing, el reviewer debe ser capaz de reproducir la funcionalidad del código en su ambiente local o de testing.
- Revisar que se cumplan las buenas prácticas de programación.
- Dar sugerencias de mejoras en cuanto a la manera en que está escrito el código.
- Requerir cambios cuando se requiera (para cumplir con las buenas prácticas y funcionalidad)
Lo que debe cumplir la plataforma de control de versiones… (esto tampoco está escrito en piedra)
- Tener branches de desarrollo, staging y producción
- Opcional. Tener actions que ejecuten tests definidos para la integración continua o de chequeo de estilo (linters)
- Tener tags para identificar las diferentes actividades: releases, bugs, new features, etc.
Por supuesto que lo que acabo de describir es muy general, la metodología de code reviews puede ser tan estricta como se quiera y lo mejor de todo es que puede ser diseñada a la medida de las circunstancias.
Algo clave para el éxito de los code reviews es el trabajo en equipo, la metodología debe de ser clara para todos los integrantes y a su vez cada uno de ellos debe tomar las responsabilidades correspondientes.
¿Quiénes de ustedes pensaban que los code reviews eran solo para software engineers o software developers?
¿En qué otros escenarios se puede aplicar esta práctica? …. Leo sus comentarios!
De-todología 