Si conoces lo bueno, serás bueno.
Llevo años diciéndolo, normalmente a alguien inquieto por si este trabajo seguirá existiendo para él. Quiero terminar este libro explicando qué quiero decir con eso, porque la inquietud es real y casi todo el consuelo que se ofrece no vale nada.
Plausible es el modo de fallo
Empecemos con una confesión sobre el libro anterior.
Laravel, shipping fast. salió con trece defectos de una especie concreta. No erratas. Llamadas a API inventadas, seguras de sí mismas y bien formadas. Una enseñaba un método de limitación de frecuencia como si devolviera un contador vivo —devuelve un closure, y el código tal como estaba impreso habría lanzado una excepción. Otra referenciaba un enum que no existe en ninguna parte del framework ni de la base de código.
Todas se leían maravillosamente. Tenían la forma correcta, la nomenclatura correcta, el idioma correcto. Eran exactamente lo que ese código debería parecer, y estaban mal.
Las atrapó una persona que sabe cómo es el buen Laravel, leyendo con la sospecha concreta que da haberse quemado antes. No una prueba —no había nada que probar. No un linter. El gusto.
Eso es lo que conviene entender sobre trabajar con estas herramientas. No producen tonterías que puedas detectar. Producen trabajo que se parece exactamente a lo auténtico. Lo equivocado es barato de atrapar. Lo plausible es caro, y lo plausible es la salida por defecto.
La habilidad escasa es discriminar, no producir
Si el modo de fallo es plausible-pero-mal, entonces la habilidad valiosa ya no es producir el artefacto. Es saber distinguir.
Eso es lo que significa «conocer lo bueno». No conocer una manera: saber cuál es la correcta aquí, para este sistema, bajo estas restricciones, y ser capaz de notar que algo está sutilmente torcido antes de poder articular por qué.
Ese gusto no se descarga. Viene de haberse equivocado en público, repetidamente, en un dominio concreto, y de haber tenido que convivir con las consecuencias el tiempo suficiente para aprender lo que cuestan. Cada anécdota de este libro es un recibo: la credencial que nadie podía validar, el turno pausado que se mostró como terminado, los dos sitios de una sola petición, el ordenamiento listo que midió peor. No leí ninguna de ellas. Ocurrieron, dolieron, y ahora las huelo venir.
De qué trataban en realidad los dieciocho capítulos
Repasa lo que este libro te pidió decidir.
Si esa frontera está en el sitio correcto. Si ese tope es el adecuado para este cliente. Si ese fallo es transitorio o tuyo. Si esta herramienta es segura de ejecutar dos veces. Si el modelo se equivoca o se equivoca la tubería que lo rodea. Si ese salto merece una semana de trabajo.
Un modelo responderá a todas esas preguntas al instante y con fluidez. Producirá un gestor, un driver, una política de reintentos, un esquema de herramienta —y el código será bueno. Uso estas herramientas todos los días; son extraordinarias en esto.
Lo que no puede hacer es decirte qué respuesta es la correcta para un sistema en el que no ha vivido. Y —esta es la parte que importa— no puede darse cuenta de cuándo se equivoca. No tiene un sentido acumulado de a qué sabe una mala idea a las tres de la mañana, porque nunca le ha sonado el busca.