Auditar una aplicación ajena

Qué cambia respecto a la propia

El paso previo

Y el que no existe en la propia: entender qué hace la aplicación antes de juzgar cómo lo hace.

• Instálala y úsala media hora. Nivel 49.4: sin saber para qué sirve, un permiso amplio no se puede evaluar — puede ser innecesario o puede ser exactamente lo que la aplicación necesita.
• Lee su documentación, si la tiene, buscando qué promete.
• Y mira su tamaño y su antigüedad: una aplicación de tres años con veinte contribuyentes se juzga distinto de un prototipo de dos meses.

Sin ese paso, la auditoría produce hallazgos técnicamente correctos y contextualmente equivocados — que es la forma más rápida de que un informe se ignore.

Las dos cosas que se añaden

Y solo aparecen al auditar algo ajeno:

Y la segunda se contesta rápido: mirar si el core menciona Tauri por todas partes, si los comandos son finos, y si hay pruebas que corran sin arrancar. Nivel 70.5.

Fallo o decisión distinta

Y la distinción del nivel 33.1, que aquí es imprescindible:

• Un fallo es algo que está mal según cualquier criterio: un comando sin validar, una migración sin copia, un secreto en claro.
• Una decisión distinta es algo que tú harías de otra forma: otro reparto, otro marco, otra estructura.
• Y la mayoría de lo que encuentras es lo segundo.

Un informe que mezcla las dos pierde credibilidad, porque quien lo lee ve una preferencia presentada como un defecto y descuenta el resto.

Entregarlo

Lo del nivel 33.3, con más cuidado todavía:

• Empieza por lo que está bien, y en serio: si las capabilities están partidas o el reparto es correcto, alguien lo hizo a conciencia.
• Separa lo urgente de lo demás, y que lo urgente sean pocas cosas.
• Da el coste de cada una.
• Y marca claramente qué es preferencia tuya, si lo incluyes.

Y una regla de tono: escribes sobre el trabajo de alguien que probablemente hizo lo que pudo con lo que sabía — que es lo mismo que se dirá de tu código dentro de dos años.