Auditoría de código base
El valor de una auditoría reside en la clasificación y la evidencia, no en su extensión. Un hallazgo sin una ruta de archivo, resultado de consulta, número de PR o recuento de filas es una hipótesis — etiquétalo como tal.
Fundamenta la auditoría en el código y la producción, no en documentos
Las notas del proyecto, planes y documentos de estado son puntos de control, no autoridad. Comienza con ellos para aprender lo que se afirmó, luego verifica contra la realidad: el commit en vivo, el estado de la base de datos, los checks de PR, las cabezas de rama.
Cuando los documentos y el código discrepan, esa discrepancia es en sí misma un hallazgo — a menudo el más valioso de la auditoría.
Una afirmación sobre producción requiere una consulta contra producción. Combínalo con una habilidad de puerta de verificación para los detalles mecánicos.
Estructura
# Auditoría de <Alcance> (AAAA-MM-DD)
## Resumen ejecutivo
<Las tres cosas que importan y qué harías primero.>
## Parte 1 — Lo que no estás viendo (puntos ciegos, clasificados)
## Parte 2 — Capacidades faltantes (clasificadas, cada una con una estimación de esfuerzo aproximada)
## Parte 3 — Capacidades existentes que necesitan mejora (clasificadas)
## Parte 4 — Cambios de arquitectura (clasificados, en lenguaje sencillo)
## Parte 5 — Si yo dirigiera los próximos 30 días
## Lista de verificación (discrepancias encontradas durante la auditoría)
Clasifícalo todo. Una lista no clasificada de 40 hallazgos es una lista de 40 hallazgos no accionables.
Busca andamios inactivos antes de estimar
Adjunta una estimación de esfuerzo aproximada a cada brecha y explica qué la hace barata o costosa.
El hallazgo de auditoría más valioso suele ser este: la mayoría de las "brechas" de alto valor son días de trabajo, no semanas, porque los andamios ya existen en el repositorio sin llamantes. Una función que ya está construida al 80% es una decisión completamente diferente a una que no lo está.
Busca la cosa antes de declararla ausente. Una función con cero llamantes es el caso canónico: el código está ahí, nada lo invoca, y cada documento de estado describe la función como ausente.
La lista de verificación
Toda auditoría termina con las discrepancias que no pudo resolver. Cada entrada nombra:
- lo que se afirmó
- lo que se observó
- qué consulta o verificación lo resolvería
Esta es la sección que la siguiente sesión realmente utiliza. Escríbela incluso cuando sea corta.
La sección de lo explícitamente no vale la pena hacer
Nombra lo que examinaste y rechazaste deliberadamente, con la razón.
Las auditorías que solo añaden a la lista de pendientes vuelven inútil la lista. Un hallazgo que miraste y descartaste vale más que uno que nunca mencionas, porque evita que la próxima auditoría lo vuelva a plantear.
Los elementos retenidos no son brechas
Cualquier cosa ya marcada como diferida deliberadamente, o retenida para una decisión humana explícita, está retenida a propósito. No lo incluyas como brecha.
Volver a sacar a la superficie una retención deliberada como hallazgo es cómo las decisiones retenidas se ejecutan por accidente.
Salida
Escribe la auditoría donde el proyecto las guarda. Si reemplaza una auditoría anterior, indica cuál y qué cambió — una carpeta de auditorías debe mantenerse legible como una secuencia, no como un montón.