Revisar una solicitud de cambio y no el proyecto entero

Un diff muestra tres clases de líneas: las añadidas, las quitadas y las de contexto que no cambian. La tentación es leer solo las añadidas, que son las que el autor quiere que mires. Pero en seguridad las líneas quitadas pesan tanto o más: un control que desaparece no deja ningún código nuevo que revisar, solo un hueco. Y las de contexto enseñan qué rodea al cambio.

Después del diff vienen dos comprobaciones que no están en él. La primera, comparar la descripción con la lista de archivos tocados: todo lo que se cambia y no se cuenta merece una pregunta. La segunda, buscar quién usa lo que cambió: si una función devuelve otra cosa, todos sus llamadores cambian de comportamiento aunque el diff no los toque.

Abre el laboratorio, lee solicitud-PR-812.txt y después diff-PR-812.patch. La descripción promete que solo las empresas pequeñas se saltan el segundo aprobador. Busca en el diff la línea quitada y la condición que la reemplaza, y compara el dato que se usa para decidir con lo que dice la descripción. Si las dos cosas no hablan de lo mismo, una empresa grande puede quedar del lado equivocado de la condición.

Ahora cruza archivos-cambiados.txt con la descripción. Cada archivo de la lista debería tener su explicación en el texto del autor; los de pruebas se explican solos si prueban lo que se describe. Fíjate en lo que el autor afirma que no cambia.

El diff también cambia lo que devuelve una función de cálculo: antes redondeaba con centavos y ahora corta la parte decimal. El autor pensó en los pagos, pero la función la usan otros. En busqueda-llamadas.txt está la búsqueda de todas sus llamadas. Cuenta las que están en código de la aplicación, fuera de los archivos que toca el diff. No cuentes la definición, ni las pruebas, ni lo que no es una llamada de verdad.

En el contexto del diff aparece una función que el autor no tocó salvo por un mensaje de registro, y que compara la firma del banco con el operador de igualdad de siempre. Una comparación de secretos debe hacerse en tiempo constante, y esa no lo es. El fallo es real, pero no lo trajo esta solicitud. Bloquear una solicitud por deuda vieja enseña al equipo a esconder el contexto; ignorarla porque «no es de este PR» la deja viva.