La revisión de código, tal como la conocemos, tiene casi 20 años. Es hora de evolucionar.

El modelo tradicional de pull request (PR) ha sido el estándar durante dos décadas: los desarrolladores escriben código, lo envían a revisión y, tras iterar sobre los comentarios, se fusiona. Pero este enfoque tiene un coste oculto: el tiempo de espera, los cambios tardíos y la fricción entre equipos. La propuesta es simple y poderosa: mover la revisión de código antes de que el código exista.

¿Qué significa revisar antes del código?

En lugar de revisar después de escribir, se revisa el diseño, la arquitectura y los tests antes de implementar. Esto se logra mediante revisiones de diseño asíncronas, donde los equipos comentan sobre documentos de diseño, diagramas de flujo o incluso pseudocódigo. Herramientas como RFCs, ADRs (Architecture Decision Records) o simples documentos compartidos permiten detectar problemas antes de que se conviertan en código costoso de cambiar.

Impacto para SysAdmins y DevOps

Para los administradores de sistemas y equipos de operaciones, este cambio reduce drásticamente los despliegues fallidos y las ventanas de mantenimiento. Al validar la arquitectura y los requisitos de infraestructura antes de codificar, se evitan sorpresas en producción. Además, se alinea con prácticas como Infrastructure as Code (IaC) y GitOps, donde la revisión temprana de cambios en configuraciones evita incidentes. Para el negocio, se traduce en menor time-to-market y menor coste de desarrollo, ya que corregir un error en diseño cuesta mucho menos que en producción.

Cómo empezar

No se trata de eliminar las PR, sino de complementarlas. Algunas acciones prácticas:

• Incluir una fase de revisión de diseño en el flujo de trabajo (por ejemplo, antes de crear la rama).
• Usar plantillas para documentos de diseño que incluyan impacto en infraestructura, seguridad y rendimiento.
• Automatizar la generación de diagramas a partir del diseño (con herramientas como Mermaid o PlantUML) para facilitar la revisión.

Este enfoque encaja con la tendencia de desplazar la calidad hacia la izquierda (shift-left), que ya aplicamos en testing y seguridad. Ahora toca aplicarlo a la revisión de código.

Fuente: The New Stack. Análisis ForgeNEX.