El Código de Seis Meses que Nadie Podía Tocar
Un cliente me llamó el año pasado por un sitio web que le había pagado a otro desarrollador. El sitio funcionaba, más o menos. Pero cada vez que pedía un cambio pequeño, el desarrollador necesitaba una semana y se quedaba callado en las llamadas. Al final admitió la verdad: tenía miedo de tocar el código, porque ya no lo entendía del todo. Se había convertido en un laberinto, incluso para él.
Esto no es raro. Lo veo varias veces al año. Un negocio contrata a alguien barato o rápido, obtiene una aplicación que funciona, y después descubre que "funcionar" y "estar sano" son dos cosas muy distintas. Esa diferencia siempre se paga, casi siempre en el peor momento posible.
Este artículo trata sobre esa diferencia. Explica qué quieren decir los desarrolladores cuando hablan de "código limpio", por qué cuesta un poco más construirlo así, y cómo usted, como dueño de negocio sin conocimientos técnicos, puede notar la diferencia antes de firmar un contrato.
Qué Significa Realmente "Código Limpio"
Usted no puede leer código. Está bien. No lo necesita. Pero sí puede entender las cuatro ideas detrás de él, porque en realidad no tratan de programación. Tratan de organización.
Nombres claros. Un buen desarrollador nombra las cosas de forma que su propósito sea obvio. Una función que calcula el descuento de un cliente podría llamarse CalcularDescuentoCliente. Una versión descuidada la llamaría hacerAlgo2. Las dos pueden funcionar hoy. Solo una seguirá teniendo sentido para otra persona dentro de un año, incluyendo al nuevo desarrollador que contrate cuando el primero se vaya.
Piezas pequeñas y enfocadas. El código limpio se divide en piezas pequeñas que hacen una sola cosa. Imagine una cocina donde la persona que corta las verduras también sirve los platos, sazona la salsa y contesta el teléfono. Puede funcionar para un plato, pero se derrumba en cuanto el restaurante se llena. El software construido de forma igual de enredada se derrumba de la misma manera, justo cuando su negocio está creciendo y más lo necesita.
Consistencia. En el código limpio, problemas parecidos se resuelven de la misma forma en todo el proyecto. El código desordenado resuelve el mismo problema de cinco maneras distintas en cinco archivos distintos, porque cinco personas diferentes, o la misma persona cansada en cinco semanas distintas, hicieron lo que les pareció más rápido en ese momento.
Poca duplicación. Cuando la misma lógica, digamos un cálculo de impuestos, se escribe una vez y se reutiliza, un cambio de tasa significa actualizar un solo lugar. Cuando se copia y pega en diez pantallas distintas, alguien tiene que encontrar y corregir las diez, y casi siempre se le escapa una.
Nada de esto cambia lo que su cliente ve en la pantalla hoy. Cambia lo que pasa la próxima vez que algo necesite cambiar, y siempre hay algo que necesita cambiar.
Por Qué Cuesta Más al Principio
Aquí está la parte que sorprende a los dueños de negocio: el código limpio es más lento de escribir al principio. Nombrar bien las cosas, dividir el trabajo en piezas pequeñas y evitar atajos requieren pensar más. Un desarrollador que corre contra un plazo puede saltarse estos pasos sin problema y aun así entregar algo que se ve terminado.
Por eso algunos presupuestos son más bajos que otros. Una construcción apurada y una bien hecha pueden verse idénticas en una demostración. La diferencia no aparece hasta tres, seis o doce meses después, cuando usted pide el primer cambio real.
No todo presupuesto bajo es malo, ni la velocidad siempre significa descuido. Pero cuando un presupuesto parece inusualmente bajo para el alcance del trabajo, vale la pena preguntar cómo piensa el desarrollador mantener el código organizado a medida que crece. Su respuesta le dice mucho.
Por Qué Ahorra Dinero Después
Aquí es donde el código limpio recupera su costo, muchas veces varias veces. El mantenimiento de software, es decir corregir errores, agregar funciones y actualizar cosas conforme cambia su negocio, representa la mayor parte de lo que cuesta un software durante su vida, normalmente mucho más que la construcción original. La mayor parte de ese trabajo continuo consiste en que los desarrolladores lean y entiendan el código existente antes de poder tocarlo con seguridad.
Cuando el código está limpio, esa lectura es rápida: un desarrollador puede abrir un archivo, entender qué hace solo por los nombres, y hacer un cambio con confianza en una hora. Cuando el código está desordenado, la misma tarea puede tomar un día entero, porque el desarrollador tiene que rastrear una lógica enredada solo para averiguar qué es seguro tocar.
Multiplique esa diferencia por cada cambio que vaya a pedir, durante todo el tiempo que el software exista, y la construcción limpia "cara" suele ganar por un margen amplio. Escribí más sobre cómo estos costos pequeños e ignorados se acumulan en el costo oculto de la deuda técnica; vale la pena leerlo si esto le suena familiar.
Cómo Juzgar la Calidad sin Leer una Línea de Código
Usted nunca va a leer el código por su cuenta, y no debería tener que hacerlo. Esto es lo que sí puede revisar.
Pregunte si hay pruebas automatizadas. Las pruebas son pequeños programas que verifican si el software sigue funcionando después de un cambio. Un desarrollador que escribe pruebas espera que el código se vuelva a tocar, y quiere saber de inmediato si un cambio rompe algo. No tener ninguna prueba, en un proyecto que no sea diminuto, es una señal de alerta.
Pida documentación básica. No necesita ser un manual. Incluso una nota corta que explique cómo encajan las piezas, o comentarios dentro del código, muestra que el desarrollador construyó esto para entregarlo, no solo para terminarlo.
Pregunte qué pasa si el desarrollador desaparece mañana. Suena directo, pero es la pregunta correcta. ¿Podría otro desarrollador abrir este proyecto y entenderlo en uno o dos días? Si la respuesta honesta es "no, solo yo entiendo esto", usted tiene un solo punto de fallo, y es usted quien carga con ese riesgo.
Fíjese en cómo hablan del trabajo. Un desarrollador que puede explicar, en lenguaje simple, por qué construyó algo de cierta manera, suele estar organizado también en el código. Alguien que se pone vago o a la defensiva cuando usted pregunta "por qué" merece una segunda mirada.
El Ejemplo Que No Se Me Olvida
Volviendo al cliente que mencioné antes. Terminamos reconstruyendo una parte de su sitio desde cero, pieza por pieza, porque la solución más rápida casi siempre era reemplazar una sección enredada en lugar de repararla. Le costó más que la construcción original "rápida y barata". Pero seis meses después, cuando pidió una función nueva, tomó tres días en lugar de tres semanas. Esa es toda la idea en una sola historia.
Antes de Firmar Cualquier Cosa
Si está eligiendo un desarrollador o una agencia ahora mismo, no compare solo precios. Pregunte sobre pruebas, documentación, y qué pasa si su desarrollador principal deja de estar disponible. Preparé un desglose más completo de qué buscar en cómo elegir un socio de desarrollo de software, que combina bien con las preguntas de arriba.
El código limpio no es un lujo. Es más parecido a una fundación. No se ve desde la calle, pero decide si el edificio sigue en pie, y cuánto cuesta renovarlo, dentro de cinco años.