Preparar la revisión: alcance, riesgo y mapa del código

Leer un repositorio de arriba abajo parece lo más completo y es lo menos útil. El orden alfabético no tiene nada que ver con el riesgo, y cuando se acaba el tiempo lo que quedó sin leer es justo lo que estaba al final de la lista, no lo menos importante. Una revisión con método hace primero un mapa: qué módulos hay, cuáles se alcanzan desde fuera, qué datos tocan, qué cambió y cuánto mide cada uno.

Con ese mapa se decide el orden y también lo que no se va a revisar. Eso último se escribe en el informe, con nombre y apellido. Una revisión que no dice lo que dejó fuera hace creer que todo quedó revisado, y ese error es peor que no haber revisado.

Abre el laboratorio y lee criterios-equipo.txt con inventario-modulos.txt al lado. Los criterios son una escalera: el segundo solo decide entre los que empatan en el primero, y el tercero solo entre los que siguen empatados. El módulo más grande, o el que más problemas dio en el pasado, no sube por eso en la escalera.

El tiempo de una revisión se presupuesta como cualquier otro trabajo. Del total asignado se descuenta lo que se reserva para escribir comentarios e informe, y lo que queda se multiplica por el ritmo real de lectura cuidadosa del equipo, no por el ritmo de alguien que pasa la vista por encima. El resultado no es una meta: es el techo de lo que se puede leer bien.

Dentro de un módulo, las rutas que cualquiera puede llamar sin iniciar sesión son la primera puerta. No todas son un problema —iniciar sesión tiene que ser público—, pero cada una es código que se ejecuta para un desconocido, y por eso se lee antes que el resto. En rutas-expuestas.txt la columna de protección dice qué exige cada ruta antes de llegar al código.

Ya tienes el orden, el techo de líneas y las puertas públicas. Compara el tamaño del primer módulo con lo que cabe, y decide qué hacer con lo que sobra y con lo que no entra. Recuerda la última regla de los criterios: lo que no se leyó no se da por bueno.