Alguien está a punto de ponerte un codebase en las manos — a través de una adquisición, una inversión, una entrega de proveedores, o un nuevo puesto. Tienes tiempo limitado, y la gente que lo escribió está motivada para parecer competente.
Este es el orden en el que trabajo, y deliberadamente no es el orden en que los engineers naturalmente empiezan. La pregunta de nadie debería ser sobre el estilo del código.
1. ¿Puedes construirlo?
Clona el repositorio en una máquina limpia y sigue el README. Mide el tiempo.
Si un engineer nuevo no puede conseguir una build ejecutable en menos de una hora sin preguntar a alguien, ese es tu hallazgo principal. Significa que los costos de onboarding son de semanas, el conocimiento está en las cabezas de la gente en lugar de en el repo, y cada estimación que te dan es optimista. Todo lo demás en esta lista es menos importante que esto.
2. ¿Puedes desplegarlo?
Pide ver un deploy. No la descripción de uno — un deploy actual, en vivo.
- ¿Cuánto tiempo desde merge hasta producción?
- ¿Cuántos humanos tienen que hacer algo?
- ¿Cuál es el rollback, y alguna vez se ha usado?
- ¿Quién tiene las claves de firma y las credenciales de la tienda? Esta es la que ha matado más adquisiciones que el código malo.
Un equipo que no puede desplegar bajo demanda no puede arreglar nada bajo demanda tampoco. Eso no es un problema de calidad de código; es un problema de continuidad del negocio.
3. ¿Dónde se va el dinero?
Pon la factura de infraestructura al lado del conteo de usuarios. Las anomalías aquí son las victorias más baratas que encontrarás, y te dicen cuán cuidadosamente se construyó la cosa.
4. ¿Qué sucede cuando se rompe?
Pide los últimos tres incidentes. No una página de estado — la historia real. Si no hay respuesta, o nada se monitorea o nada se escribe, y ambas conducen al mismo hallazgo: serás sorprendido, y no sabrás por qué.
Verifica crash reporting y error tracking, y si alguien mira cualquiera de los dos. Una app ejecutándose con una tasa de crash-free del 96% sin que nadie lo sepa te dice exactamente cómo funciona el equipo.
Una agenda de dos días que funciona
Si genuinamente tienes dos días, gástalos así en lugar de leer código desde la hora uno:
- Mañana uno — build y deploy. Clona, build, mira un deploy. Dos hallazgos al mediodía, y usualmente son los dos que importan.
- Tarde uno — habla con los engineers. Individualmente, no como grupo. Pregunta qué arreglarían si les dieran un mes libre. La consistencia de las respuestas te dice tanto como las respuestas.
- Mañana dos — muestra del código. Auth, payments, el archivo más grande, la test suite, la lista de dependencias. Con límite de tiempo de tres horas.
- Tarde dos — acceso y propiedad. Cuentas, claves, licencias, contratos, datos. La mitad aburrida, y la mitad que bloquea tratos.
Nota que el muestreo de código es un cuarto de esto. Esa proporción sorprende a los engineers y tranquiliza a todos los demás, y es correcta.
Preguntas que obtienen respuestas honestas
Cómo preguntas determina qué aprendes. Estos funcionan:
- "¿Qué arreglarías si tuvieras un mes libre?" A la gente le encanta responder esto y saca a la superficie la deuda real en noventa segundos. "Nada" es en sí misma una respuesta, y no es una buena.
- "¿Cuál es la parte de la que advertirías a un hire nuevo?" Cada codebase tiene una. Ser advertido sobre esto sin ser preguntado es una buena señal sobre el equipo.
- "¿Cuándo salió algo mal en producción por última vez, y qué pasó?" Prueba si tienen incidentes y si aprenden de ellos.
- "¿Qué se rompería si el tráfico subiera 10×?" Un buen equipo responde instantáneamente con un componente específico. La vaguedad significa que nadie lo ha pensado.
Evita "¿es el código bueno?". Obtendrás una respuesta defensiva que no te dice nada, y habrás gastado la buena voluntad que necesitabas para las preguntas útiles.
5. Ahora mira el código — pero solo estos
No vas a leer un codebase en dos días, así que no lo intentes. Muestra deliberadamente:
- Los caminos de autenticación y pago. Donde viven los bugs de seguridad y la exposición legal. Lee estos adecuadamente.
- El archivo más grande en el repo. Cada codebase tiene un monstruo. Su tamaño te dice cuánto tiempo el equipo ha estado bajo presión sin poder pagar la deuda.
- La suite de pruebas — ¿funciona, y alguien le confía? El porcentaje de cobertura es casi sin significado. "¿Ejecutas pruebas antes de desplegar, y alguna vez atrapan algo?" es la pregunta real.
- Edad de dependencias. Una dependencia tres versiones principales atrás es un proyecto programado que nadie ha programado.
- Historial de commits. ¿Quién realmente escribió esto? Si el 80% de los commits vienen de una persona que se va, no estás comprando un codebase — estás comprando una reescritura.
6. La capa legal que todos olvidan
- Auditoría de licencia. Una licencia copyleft dentro de un producto comercial es un problema real, siempre descubierto demasiado tarde.
- ¿Tienen ellos el código? Los acuerdos de contratista sin asignación de IP son comunes y caros.
- ¿Dónde están los datos personales, y quién puede alcanzarlos? Bajo GDPR esto se convierte en tu problema en el momento en que firmas.
- Cuentas de terceros. Listados de tienda, dominios, cuentas en la nube, análisis. Cualquier cosa registrada en un email personal es un desastre anunciado.
Hallazgos que deberían cambiar el precio
La mayoría de lo que una auditoría revela es normal — cada codebase real lleva deuda. Estos son los que son genuinamente materiales:
- Nadie actualmente empleado puede desplegarlo.
- Las claves de firma, cuentas de tienda o dominios no están controlados por la empresa.
- La cadena de IP está rota.
- Una persona que se va escribió la mayoría.
- Una dependencia o requisito de plataforma fuerza una reescritura dentro de doce meses.
Solo uno de esos es sobre código. Technical due diligence es principalmente no técnica — se trata de si el conocimiento, el acceso y la propiedad realmente se transfieren con el trato.
Cómo se ve lo bueno
Sabrás dentro de una hora. Los buenos equipos te ceden un repositorio que funciona, un documento explicando por qué las cosas son como son, y un engineer que voluntariamente señala los puntos débiles antes de que los encuentres. Esa última es la señal más fuerte que hay: la gente que te dice dónde están los problemas reales son personas que han estado pensando en esos problemas.
Si prefieres no hacerlo tú mismo, es exactamente para qué sirve una auditoría de producto — una hora fija, una opinión externa, y sin razón para suavizar la respuesta.