Code review

¿Qué es el code review?

El code review es el paso en el que otro ingeniero lee un cambio antes de que se fusione en el código. Comprueba si hace lo que dice hacer, si encaja con el resto del sistema y si alguien será capaz de entenderlo dentro de seis meses. Luego lo aprueba o pide cambios.

La mayoría de los equipos hacen esto a través de un pull request. El autor propone un cambio, un revisor comenta, los dos van y vienen, y el cambio se fusiona una vez aguanta. Las comprobaciones automáticas corren en paralelo: linters, type checks y la suite de pruebas atrapan los problemas mecánicos para que el humano pueda centrarse en los de criterio. Un revisor detecta que una nueva consulta a base de datos no tiene límite y escanearía una tabla que crece cada día. Las pruebas pasaron. El código funcionaba. Aun así habría tumbado producción bajo tráfico real, y eso es exactamente el tipo de cosa que la revisión atrapa y la automatización se pierde.

Bien hecha, difunde conocimiento tanto como atrapa bugs. Ahora dos personas entienden el cambio en lugar de una. Mal hecha, se vuelve un sello de goma o un sitio para quisquilleos. La diferencia está en si el equipo lo trata como propiedad compartida de la calidad.

Code review en Dallonses

Nada llega a producción en Dallonses sin que otro ingeniero lo lea. No es una formalidad que mencionamos para sonar rigurosos. Es cómo el trabajo se mantiene bueno cuando el equipo va rápido y las personas cambian. La revisión es donde se enseñan los estándares, no en un documento que nadie abre.

Mantenemos las revisiones centradas en lo que importa. Corrección, claridad y si el cambio hace el sistema más fácil o más difícil de mantener. Las comprobaciones mecánicas corren automáticas en nuestros pipelines CI/CD, así los revisores gastan su atención en las decisiones que una máquina no puede tomar. Cuando trabajamos junto a los ingenieros de un cliente, nuestras revisiones se vuelven una forma de compartir cómo pensamos, y las suyas afinan las nuestras. Ese intercambio es parte de por qué los equipos salen de un proyecto más fuertes de lo que entraron.

¿Quieres un segundo par de ojos sénior sobre tu código? Hablemos.

Hablemos de calidad