«Publicar rápido» no significa escribir código de forma temeraria. Significa:
-
Decisiones tomadas una vez, aplicadas en todas partes. Un patrón de validación. Una estructura de respuesta. Un formato de error. Sin debates, sin excepciones, sin casos especiales.
-
Gente nueva productiva en días. Lee un endpoint. Entiéndelos todos.
-
Se resuelven problemas reales, no imaginarios. Construye para hoy. Optimiza cuando choques con restricciones reales.
-
Las revisiones se centran en la lógica, no en el estilo. La consistencia elimina las discusiones estructurales.
-
Los despliegues no te aterran. La previsibilidad convierte depurar y revertir en rutina, no en drama.
Publicar rápido es publicar de forma predecible, fiable y repetida. Es velocidad que se compone.
La disciplina como velocidad, no como restricción
Las restricciones habilitan la velocidad.
El instinto de un desarrollador suele ser «libertad». Sin reglas. Constrúyelo como te parezca. Pero sin restricción no obtienes libertad: obtienes caos. Y el caos es lento.
Piensa en una autopista: los conductores no van más rápido sin reglas; van más despacio, porque cada conductor es impredecible.
Esto es lo que pasa cuando un equipo acuerda unos patrones:
Dedicas treinta minutos a decidir cómo estructurar la validación. Luego usas ese enfoque en todas partes. Has tomado una decisión y has ahorrado decenas de horas de tiempo colectivo.
Dedicas una hora a definir tu Response Wrapper. Todas las respuestas lo siguen. Sin sorpresas para los consumidores. Sin depurar siete formas de respuesta distintas.
Eliges tu estrategia de errores una vez. Todos los errores la siguen. Códigos de estado, mensajes y cargas consistentes.
Esto no es restricción. Es libertad frente a la tiranía de la elección.
Los equipos más rápidos con los que he trabajado no eran los más listos. Eran los más consistentes. Decidían una vez, aplicaban en todas partes y seguían adelante.
Eso es lo que enseña este libro: los patrones que permiten a tu equipo moverse con velocidad.
El mito de lo «avanzado»
Todo desarrollador pasa por una fase:
Descubres los microservicios. Descubres CQRS. Descubres event sourcing. Descubres la arquitectura hexagonal. Y de pronto todo lo que has construido te parece «mal».
Así que reconstruyes. Y vuelves a reconstruir.
Lo que era un simple endpoint POST /orders ahora exige seis capas de abstracción, tres transformadores, dos librerías de DTOs y un documento de diseño más largo que tu esquema.
Estos patrones resuelven problemas reales, pero no los problemas que tú tienes todavía.
Netflix usa microservicios porque Netflix rompió su monolito. No empezaron ahí. Empezaron simple, chocaron con límites reales y luego evolucionaron.
Esto es complejidad accidental: complejidad que añades porque anticipas problemas que nunca llegaron, o porque quieres lucir conocimiento.
El código ingenioso sienta bien. Impresiona a otros desarrolladores. Pero el ingenio se acumula. Cada abstracción añade otra capa que entender, otra que depurar, otra que mantener.
Multiplica eso por un equipo de cinco. Multiplícalo por dos años.
Acabas con código más difícil de leer, más difícil de cambiar y más difícil de probar. Cuanto más abstracto es tu código, menos gente lo entiende de verdad. Cuando quien lo escribió se va, te quedas manteniendo un sistema que apenas comprendes.
Eso no es arquitectura. Es arqueología.
La verdad incómoda es esta:
La mayoría de las APIs no fracasan por no estar arquitecturadas como Netflix. Fracasan porque nunca se publicaron, nunca se simplificaron o nunca se mantuvieron.
Hay una diferencia.
Resuelve el problema que tienes delante con el código más simple que funcione. Cuando choques con un límite real —rendimiento, escalabilidad, mantenibilidad— añade el patrón sofisticado que resuelve ese problema concreto. Para entonces entenderás por qué lo necesitas. El patrón deja de ser teórico: es la solución a un dolor real.
La complejidad se siente productiva. Publicar es productivo.