Leer código que no escribiste
Hoy pedir código es fácil. Lo difícil —y lo que te van a pagar— es darte cuenta de cuándo ese código está mal. Y casi nunca está mal de forma escandalosa: normalmente funciona en la prueba, se ve ordenado, y falla cuando ya está en producción con datos de verdad.
Vamos a entrenar ese ojo. Este código lo escribió una IA a la que le pidieron "muéstrame el total de los pedidos con el nombre del cliente". Funciona. Pero tiene un problema serio.
Toca la línea donde crees que está el problema.
Esa línea consulta la base de datos dentro del bucle: con 10 pedidos son 10 consultas, con 5000 son 5000. Es el error de rendimiento más común del mundo y tiene nombre: problema N+1. La solución es traer todos los clientes de una sola vez antes del bucle, o pedir los pedidos ya con su cliente incluido. En pruebas con tres registros nunca lo vas a notar; en producción tumba el sitio.
Fíjate en lo que acaba de pasar: el código no tiene ningún error de sintaxis. Ningún programa te va a avisar. Solo lo detecta alguien que sabe qué está caro y qué está barato.
Aquí va el segundo, más sutil. Es una función que calcula el promedio de una lista de notas.
Toca la línea donde crees que está el problema.
Si la lista llega vacía, count($notas) vale 0 y estás dividiendo entre cero. El código es correcto para el caso normal y explota en el caso borde. Lo mismo pasa con textos vacíos, fechas nulas o listas que aún no cargaron. Antes de aceptar cualquier función, pregúntate siempre: *¿y si esto viene vacío?*
Con el tiempo vas a desarrollar una lista mental de sospechas. Estas son las que más se repiten cuando revisas código generado:
¿Cuál es la mejor forma de revisar código que escribió una IA?
Que ejecute sin error solo prueba que la sintaxis está bien. El criterio está en imaginar la realidad: listas vacías, miles de registros, usuarios con mala intención y conexiones que se caen a la mitad.
Esa pregunta —*¿y si...?*— es, en una sola frase, todo el oficio.
