El freelancer que me hizo esperar tres días
Hace unos años un cliente me llamó frustrado. Había contratado a un desarrollador freelance para construir una calculadora de descuentos para su tienda online. El código ya estaba listo. Funcionaba en las pruebas. Pero el freelance dijo que quería "un día más" para que un colega revisara el código antes de publicarlo.
Mi cliente estaba molesto. Pagaba por hora, y esto le parecía pagar para que alguien se sentara a leer el trabajo de otra persona. Me preguntó si eso era normal, o si le estaban tomando el pelo.
Le dije que dejara que la revisión ocurriera. Menos mal que lo hizo.
El revisor encontró un error de redondeo en la lógica de descuentos. Bajo una combinación específica de cupón y cantidad, la calculadora aplicaba el descuento dos veces. Los clientes con ese carrito exacto recibían el doble del descuento que la tienda quería dar. Nada se habría roto. Ningún mensaje de error habría aparecido. La tienda simplemente habría perdido dinero en silencio, en cada pedido que tocara esa combinación, hasta que alguien lo notara.
Ese día de "estar sentado sin hacer nada" le ahorró a mi cliente dinero real, quizás durante meses.
Qué es en realidad una revisión de código
Una revisión de código es simple: antes de que el código nuevo salga a producción, un segundo desarrollador lo lee. No solo revisa que funcione. Revisa si hace lo correcto, en cada situación que un cliente real podría generar.
Piénselo como enviar un contrato a un segundo abogado antes de firmarlo. El primer abogado escribió algo que funciona. Un segundo par de ojos lo revisa buscando las trampas que el primero pudo no haber pensado en buscar, porque escribir algo y revisar algo usan partes distintas del cerebro.
Esa es toda la idea. Una persona construye. Otra persona revisa. No es burocracia. Es la misma razón por la que una segunda persona relee un correo importante antes de enviarlo a toda su lista de clientes.
Lo que un segundo par de ojos detecta y las pruebas no
Los dueños de negocio suelen asumir que si el software "pasa las pruebas", está seguro. Las pruebas importan, y ya escribí sobre por qué vale la pena invertir en pruebas automatizadas. Pero las pruebas solo revisan las situaciones que alguien pensó en probar. Una revisión de código detecta una categoría distinta de problema: la que nadie probó, porque nadie imaginó que pasaría.
Un revisor lee la lógica en sí, no solo el resultado. Así detectan cosas como:
- Suposiciones equivocadas. El desarrollador original asumió que todas las direcciones de los clientes estarían dentro del país. El revisor sabe que la tienda envía a otros países, y pregunta qué pasa cuando no es así.
- Huecos de seguridad. El código acepta la carga de un archivo sin revisar qué tipo de archivo es. Un revisor con experiencia en seguridad marca eso antes de que se convierta en una forma de que alguien suba algo peligroso.
- Lógica confusa que se romperá después. Código que funciona hoy pero que fallará en silencio la próxima vez que alguien lo edite, porque nunca quedó claro qué se suponía que debía hacer.
Ninguno de estos aparece como un mensaje de error. Aparecen como una fuga lenta: cobros incorrectos, datos expuestos, o una función que se rompe seis meses después, cuando ya nadie recuerda por qué se construyó así.
La calculadora de descuentos es un buen ejemplo. Las pruebas automatizadas solo habrían detectado el error de redondeo si alguien hubiera pensado en probar exactamente esa combinación de cupón y cantidad. Un solo desarrollador, concentrado en que la función funcione, difícilmente va a inventar cada caso límite con el que un cliente real va a tropezar por accidente. Un segundo desarrollador, que lee la lógica con ojos nuevos y sin apego al enfoque original, es mucho más probable que se pregunte "¿qué pasa si alguien hace esto?" — y esa pregunta vale más que cualquier cantidad de pruebas adicionales hechas después.
Por qué "más lento" suele significar "más barato"
Aquí está la parte difícil de ver cuando se está mirando un reloj y un presupuesto: detectar un error antes de que llegue a sus clientes casi siempre es más barato que detectarlo después.
Antes del lanzamiento, corregir un error significa cambiar algo de código. Después del lanzamiento, significa cambiar el código, además de reembolsar a los clientes, además de explicarle a alguien por qué su pedido estaba mal, además de reconstruir la confianza. Las investigaciones sobre errores de software muestran una y otra vez el mismo patrón: cuanto antes se detecta un error, más pequeña es la limpieza. La revisión de código es uno de los puntos más baratos de todo el proceso para detectarlo, porque todavía no se publicó nada.
El día extra que pidió el freelance de mi cliente no retrasó el proyecto. Evitó un retraso mucho mayor después: el de tener que pausar la tienda, investigar un problema de facturación y reconstruir la confianza de los clientes.
El problema de conocimiento del que nadie habla
Hay un segundo beneficio que no tiene nada que ver con errores. Cuando solo una persona ha visto su código alguna vez, solo esa persona lo entiende. Si esa persona no está disponible, está de vacaciones o se fue, usted queda atrapado. Ya escribí antes sobre qué pasa cuando un negocio depende de una sola persona que sabe cómo funciona todo, y un freelance solitario sin proceso de revisión es exactamente ese riesgo, integrado en su software desde el primer día.
Una revisión de código significa que al menos dos personas entienden cómo funciona su sistema. Eso no es un lujo. Es un seguro.
Una pregunta para hacerle a cualquier desarrollador que contrate
Si trabaja con un freelance solitario, o con un estudio pequeño, pregunte esto antes de que empiece el proyecto: "¿Quién revisa su código antes de publicarlo?"
Una respuesta segura suena así: "Se lo envío a otro desarrollador" o "Uso un servicio donde un segundo ingeniero revisa los cambios críticos". Una respuesta débil suena así: "Yo mismo lo pruebo" o, peor, silencio.
No se trata de intentar atrapar a nadie haciendo algo mal. Se trata de averiguar si un segundo par de ojos alguna vez va a mirar el código que hace funcionar su negocio. Si la respuesta es no, usted es la única red de seguridad. Ese es un riesgo real, y vale la pena tenerlo en cuenta en su decisión.