English

Revisa primero los tests y divide los diffs grandes

Deja de leer el código primero en el code review. Lee los tests antes que la implementación. Los tests te dicen qué se supone que hace el cambio — intención, casos borde y cobertura — antes de que juzgues cómo lo hace. Y con asistentes de IA generando diffs cada vez más grandes y rápidos, la segunda mitad del tip importa igual: vigila el tamaño y divide todo lo que crezca más allá de un cambio lógico.

Por qué los tests primero

Una implementación te muestra el cómo; los tests muestran el qué y el por qué. Leerlos primero te da una especificación contra la cual revisar, en vez de deducir la intención desde el código:

• Intención — los nombres de los tests y sus aserciones expresan el comportamiento esperado en términos claros: test_refund_rejects_expired_card te dice más en una línea que 40 líneas de un handler.
• Cobertura — los tests faltantes se ven de inmediato. Si el diff toca manejo de errores pero ningún test ejercita la ruta de fallo, ya encontraste tu primer comentario de review antes de leer una sola línea de implementación.
• Validez — los tests no se prueban a sí mismos. La guía de reviewers de Google pregunta: ¿estos tests realmente fallarán cuando el código esté roto? ¿Cada uno hace aserciones simples y útiles? Eso lo tiene que verificar un humano, y es más fácil cuando los tests son tu primera lectura fresca.

Esto coincide con cómo la guía de Google recomienda navegar un cambio: lee la descripción y luego los archivos principales primero, porque las partes grandes dan contexto a todo lo demás. En la mayoría de los cambios, los tests son ese contexto.

La escalera de tamaños

La calidad del review se degrada con el tamaño del diff — el estudio de SmartBear sobre reviews de código en Cisco encontró que los reviewers detectan el 70–90% de los defectos al revisar 200–400 líneas durante 60–90 minutos, y la efectividad cae rápido después de eso. La guía propia de Google: 100 líneas suele ser un cambio razonable, 1,000 suele ser demasiado.

El conteo de líneas no es el único eje: 200 líneas en un archivo se leen bien; las mismas 200 líneas repartidas en 50 archivos, normalmente no.

Tres formas de dividir

1. Apila cambios pequeños. Escribe un cambio pequeño, mándalo a review, y de inmediato empieza el siguiente basado en el primero. Sigues avanzando mientras los reviewers trabajan, y cada eslabón de la cadena sigue siendo revisable.
2. Divide por grupo de archivos. Envía el cambio de esquema o interfaz en un diff, y el código que lo usa en un follow-up. Los reviewers pueden aprobar el contrato antes de meterse en los call sites.
3. Corta rebanadas verticales. Para una funcionalidad, aterriza primero un camino delgado de extremo a extremo — de la UI al almacenamiento — y luego amplíalo. Cada rebanada es testeable y demostrable por sí sola, lo que también hace que sus tests se lean como especificación.

Trucos de usuario avanzado

• Haz que la IA divida por ti. Cuando un asistente proponga un cambio de 900 líneas, pídele reorganizar el trabajo como una secuencia apilada — "primero el esquema, luego el handler, luego la UI, cada uno con sus tests" — antes de abrir un solo archivo.
• Mira el diff de los tests solos. git diff main -- '*test*' te muestra la capa de intención de una rama en aislamiento. Si ese diff está vacío en un cambio de comportamiento, el review empieza con "¿dónde están los tests?"
• Rechaza el "tests después". Los tests pertenecen al mismo cambio que el código que cubren; la promesa de un follow-up es como se despliegan los huecos de cobertura.
• Presupuesta tiempo de review, no solo líneas. Menos de una hora por sesión — la detección de defectos se desploma con la fatiga del reviewer, sin importar qué tan disciplinado fue el autor.

Recursos

• Small CLs — Google Engineering Practices
• What to look for in a code review (sección de tests) — Google Engineering Practices
• Navigating a CL in review — Google Engineering Practices
• Best practices for peer code review — SmartBear

Read this article in English