La primera semana de alguien nuevo decide más sobre el futuro de tu base de código que cualquier diagrama de arquitectura. Que pueda trazar una petición de punta a punta antes de comer y escribirá código que encaja. Que pase tres días adivinando y escribirá código que pelea con todo lo que le rodea, y convivirás con ese desajuste durante años.
Este capítulo cubre la primera hora en una base de código nueva, por qué la instalación tiene que ser un solo comando, cómo las convenciones permiten a quien llega adivinar correctamente en lugar de preguntar, por qué la documentación tiene que sobrevivir a que el código cambie bajo ella, qué le debe un error a quien lo lee, por qué las herramientas tienen que estar de acuerdo entre sí y cómo un equipo deja de rediscutir el estilo en cada revisión.
La experiencia de desarrollo es una propiedad del código, no un documento sobre el código. No puedes atornillarla después con una página de wiki. Se construye igual que todo lo demás en este libro: una decisión aburrida y repetible cada vez.
La primera hora
¿Qué hace realmente alguien nuevo en su primera hora en api-license? Lo clona, abre un fichero y necesita que ese fichero le diga la verdad sobre el sistema entero.
<!-- README.md -->
## Project Review Summary
- Framework and runtime: Laravel 13, PHP 8.4.
- Route surface: 4 API routes, one public health check and three behind bearer auth.
- Integration pattern: `LicenseFacade` -> `LicenseManager` -> driver (`StatamicAPI`).
- Test status: `95 passed (332 assertions)` via `php artisan test --compact`.
Cuatro rutas. Un patrón de integración. Un recuento de pruebas que puede reproducir en treinta segundos. Eso no es texto de marketing: es un mapa, y a diferencia de un documento de incorporación rancio, cada número puede verificarlo por sí mismo en los cinco minutos siguientes.
El mismo README enumera el flujo de petición de cada ruta protegida como una tubería recta, no como un párrafo:
SetRequestLocaleMiddleware
↓
GzipResponseMiddleware
↓
EnsureTokenIsValidMiddleware
↓
throttle:api-token
↓
AddRateLimitHeadersMiddleware
↓
LogApiRequestsMiddleware
↓
Controller → Facade → Manager → Driver
Lee eso una vez y sabrás adónde va una petición antes de llegar a la lógica de negocio, y qué capa tocar cuando la cadena tenga que cambiar. Quien entiende ese diagrama entiende más que quien se ha leído todos los controladores, porque el diagrama es la forma y los controladores son sólo el detalle rellenado.