Ingeniero de Software: pregunta de entrevista
¿Qué buscas en una revisión de código?
Revisa primero corrección y casos ausentes, luego seguridad, consistencia, fallos, concurrencia, rendimiento, pruebas, claridad y compatibilidad. Explica el impacto y propone un cambio concreto, no preferencias personales.
Respuesta directa
Qué debe cubrir una buena respuesta
Cómo funciona
Una revisión empieza por entender qué se supone que hace el cambio, y luego comprueba si lo hace en todos los casos, incluidos el vacío, el concurrente y el que falla. Después vienen las cosas que las pruebas rara vez atrapan: huecos de autorización, datos que pueden acabar inconsistentes, recursos que se fugan, compatibilidad hacia atrás de APIs y esquemas, y rendimiento con tamaños de datos realistas. Solo entonces legibilidad y nombres. Los comentarios declaran el impacto y proponen una alternativa concreta; los debates de estilo van al linter. El trabajo del revisor es atrapar lo que dolerá en producción, no reescribir el cambio a su gusto.
Ejemplo
Un pull request que añadía un endpoint de exportación parecía correcto hasta que la revisión preguntó qué pasa con un usuario de 500.000 filas; el bucle lo cargaba todo en memoria. El comentario propuso streaming con cursor y un límite duro de filas con un enlace al helper de paginación, y el autor entregó eso en lugar de una versión reformateada del original.
Errores frecuentes
- Aprobar porque las pruebas pasan sin leer qué afirman realmente.
- Dejar veinte comentarios de estilo y no ver la comprobación de autorización que falta.
- Bloquear un cambio por preferencia personal sin impacto en el comportamiento.
Una estructura útil para responder
Responde desde tu propia experiencia.
No memorices un guion: usa solo ejemplos que puedas explicar con honestidad en preguntas posteriores.
Abre el espacio de trabajo de escritorio y ensaya una respuesta clara con tus propias palabras.