Acaba de heredar un código Laravel. Léalo en este orden.

Alguien se ha ido, o han comprado una empresa, o se ha acabado la relación con una agencia. Hay un repositorio, acceso a producción, y una pregunta sobre cuánto va a tardar algo.

El instinto es abrir los controladores y empezar a leer. Es la ruta más lenta hacia la comprensión, porque un controlador le dice lo que hace una pantalla y nada sobre lo que es el sistema.

Este es el orden que funciona.

1. El esquema, antes que nada de PHP

La base de datos es el documento más honesto del repositorio. El código se refactoriza por capricho; el esquema es lo que el negocio hace de verdad, y sus partes incómodas son donde los requisitos eran incómodos.

Lea las migraciones en orden, o vuelque la estructura actual y lea eso. Busque las tablas con más claves foráneas apuntándolas: ese es el núcleo del dominio. Busque las que no referencia nadie, que suelen ser funcionalidades abandonadas. Busque cuatro columnas que parezcan todas guardar un estado, porque eso es una decisión tomada tres veces por tres personas.

Al terminar suele poder nombrar los cinco sustantivos que le importan al negocio, que es más de lo que contiene la mayoría de los documentos de traspaso.

2. Los trabajos, porque ahí vive el riesgo

Los controladores hacen el trabajo visible. Los trabajos hacen el trabajo que cuesta dinero cuando sale mal: cobrar tarjetas, emitir facturas, mandar cosas a otros sistemas, exportar datos.

Lea todas las clases de trabajo. De cada una, pregúntese qué pasa si se ejecuta dos veces, porque en algún momento todas lo harán. Después mire la tabla de trabajos fallidos en producción y averigüe cuáles fallan ya, con qué frecuencia, y si alguien lo está mirando.

La tabla de trabajos fallidos de una aplicación es un resumen de sus problemas sin resolver, y es casi siempre el primer sitio que nadie ha mirado.

3. El despliegue, porque le dice qué puede cambiar

Averigüe cómo llega el código a producción. Una tubería, un script, o alguien con acceso SSH y una costumbre.

Busca respuestas concretas: ¿se ejecutan las migraciones automáticamente?, ¿se reinician los workers de cola?, ¿hay vuelta atrás?, ¿la ha usado alguien? Las respuestas deciden cuánto puede atreverse en su primer cambio.

Si el despliegue es una persona siguiendo pasos de memoria, eso es lo primero que hay que arreglar independientemente de para qué le contrataran. Todo lo demás que haga depende de poder entregar con seguridad.

4. Composer, para las dependencias que se han ido

composer outdated --direct

Busca dos cosas. Paquetes varias versiones mayores por detrás, que limitan lo que puede hacer. Y paquetes abandonados, que son una decisión esperando a ocurrir y no un número de versión.

Compruebe qué versiones de Laravel y de PHP ejecuta la aplicación, y si alguna sigue recibiendo arreglos de seguridad. Ese solo dato reordena todos los planes.

5. Producción, para lo que ocurre de verdad

No el código: el comportamiento. Qué endpoints son lentos, qué errores se repiten, cuánto se llena la cola en su peor hora, y cómo de grandes son las tablas más grandes.

Si no hay monitorización, ponerla es el trabajo de su primera semana. Una aplicación que nadie puede observar es una donde toda estimación es una adivinanza y todo incidente es una sorpresa.

6. El historial de git, al final y con provecho

Ahora que conoce la forma de las cosas, el historial le dice el porqué. Qué partes se remueven constantemente: ahí los requisitos son inestables. Qué partes llevan tres años sin tocarse: eso o es estable o da miedo. Quién escribió qué, y si sigue estando.

Los mensajes de commit de la semana anterior a un lanzamiento son la documentación más informativa de casi todos los repositorios, y no los lee nadie.

Qué no hacer en la primera quincena

No reformatee nada. Un commit de espacios en blanco destruye el historial de autoría que está a punto de necesitar.

No arregle cosas que parezcan mal. El cuarto día, el código raro parece un error. El vigésimo, la mitad resulta ser una regla que alguien aprendió por las malas.

No dé un número hasta haber terminado. La estimación que todo el mundo quiere el primer día es la que le van a repetir en el tercer mes.

Lo que esto produce es un documento: qué hace la aplicación, qué es frágil, qué está fuera de soporte, y qué pasaría a las tres de la mañana. Es lo mismo que entrega nuestra auditoría, y lo haga usted o lo hagamos nosotros, es de lo que depende toda decisión posterior.