La revisión de un cambio

Una solicitud de cambio se lee en tres capas: el motivo (el ticket y por qué se pide), la diferencia (qué líneas cambian de verdad) y la evidencia (qué casos de prueba pasan o fallan con el cambio). Revisar solo la diferencia es leer código sin saber si hace lo que se prometió; revisar solo el motivo es confiar en la intención.

Hay además una regla de oficio: quien revisa no es quien escribió. Una revisión de la propia autora no encuentra lo que ella no vio al escribir.

Una diferencia marca con - cada línea que sale, con + cada línea que entra y con = las líneas sin cambios que se muestran para dar contexto. Lo primero que se hace es contar y ubicar: cuántas líneas cambian y dónde. Un cambio que dice «excluir una cuenta» y toca diez líneas merece sospecha; uno que toca la condición y no menciona el motivo, también.

Abre el panel, mira la tabla diferencia y cuenta las líneas que el cambio añade.

Entre las líneas modificadas hay una que cambia el comportamiento. Las demás explican (la descripción) o documentan (los falsos positivos conocidos). Una buena revisión separa lo que explica de lo que decide. La línea que decide es la del filtro: antes nombraba a una cuenta exacta y ahora acepta cualquiera que cumpla un patrón.

El motivo de la solicitud es razonable: unas 40 alertas al mes que no valen nada. Pero la solicitud no añade casos de prueba (casos_nuevos_en_el_cambio vale 0), así que la evidencia hay que pedirla a los casos que ya existen. La tabla casos_afectados los ejecuta contra la versión actual y la propuesta. Un patrón de cuentas es más amplio que una cuenta: lo que antes se vigilaba puede quedar dentro de la excepción.

El caso que falla es un positivo: una cuenta de servicio que no es la de inventario se agrega al grupo de administradores sin autorización. Es justo la conducta que la regla existe para ver, y con la v1.3 quedaría dentro de la excepción. Aprobar el cambio tal cual cegaría la regla para cualquier cuenta cuyo nombre empiece igual.