featured image

Mi amigo Guillermo me remitió un email hace poco en el que detallaba un concepto que ya conocía hace tiempo, pero que no había visto tan bien explicado hasta el momento (sí, tenía que haber leído antes a Cunningham), el tema era: La deuda técnica en scrum, ¿lo revisamos?

En resumen y tal y como lo enunció Ward Cunningham:

Hacer código de mala calidad a toda prisa, es como pedir un crédito: puede que obtengamos un beneficio a corto plazo pero si tenemos que seguir desarrollando ese código, tarde o temprano tendremos que pagar todo el tiempo que nos habíamos ahorrado y los intereses. Refactorizar código mal escrito es siempre más difícil que escribirlo bien desde el principio.

Quien es desarrollador desde hace tiempo lo sabe. Lo conoce. Programar rápido suele ser sinónimo de desarrollar mal y no porque al desarrollar rápido intrínsecamente lo desarrollado sea peor sino porque la velocidad no nos deja tiempo a realizar más comprobaciones, estudiar mejores formas de diseño o solventar problemas encontrados por el camino. El objetivo es conseguir que funcione aunque solo sea una vez.

Pero la deuda técnica afecta directamente a la mantenibilidad. Un código mal desarrollado es difícil de mantener y requiere de más sesiones de refactorización que un código bien escrito. El código mal escrito debe corregirse si quiere ampliarse sin que aparezcan nuevos errores o sin romper algo que anteriormente funcionaba.

El mal código además es muy difícil de probar de forma unitaria. Sin seguir buenas prácticas un mal código puede ser imposible de probar e imposible de modificar. Perdemos la certeza de saber si el código hace su función o no. Una modificación debe modificar no solo el código sino también la prueba sobre el código (en caso de existir) y esto puede originar incluso más problemas, más tiempo invertido. Más gasto.

¿Cómo podemos hacerlo mejor?

Invirtiendo en lugar de gastando. Invertir más tiempo al inicio del desarrollo nos permite comenzar estructurando la base de nuestro código. Nos permite pensar cómo iniciar el proyecto e intentar ahorrarnos malas decisiones de diseño.

Las metodologías ágiles además señalan algo obvio. Trabajar en pequeñas tareas nos garantiza la calidad. Si una pequeña tarea es desarrollada creando o cambiando código existente y hacemos que nuestro código cumpla una finalidad. Solo una. Además de seguir buenas prácticas recomendadas para el entorno en el que trabajamos (lenguaje, herramientas, metodología y/o paradigma) podemos garantizar una reducción desde el principio de la deuda técnica cambiándola por una inversión inicial más pequeña.

El ciclo de desarrollo basado en prueba (rojo), desarrollar (verde) y refactorizar (mantener verde o azul) nos garantiza un ciclo donde agregamos la prueba sobre cómo debe comportarse el código, proyecto o producto, revisando en la ejecución de las pruebas que falla por no estar implementado. Desarrollamos el código que nos permita superar la prueba y volver al estado verde. En este punto habríamos acabado pero, para evitar deuda técnica es indispensable revisar el código, pensar de nuevo en la arquitectura y desafiarnos a nosotros mismos preguntándonos: ¿Cómo podemos hacerlo mejor? En este punto realizamos la refactorización para cambiar el código comprobando con las pruebas que nada falle.

El ciclo azul suele ser un ciclo donde a través de las pruebas se comprueban factores como código cubierto por los tests o tiempo empleado en la ejecución de los tests e intentamos mejorar esas métricas además para incrementar el rendimiento y optimizar nuestro la ejecución de nuestro código.

¿Y tú empleas el ciclo rojo-verde-azul? ¿Tienes algún método para evitar la deuda técnica? ¿Quieres saber formas de medirla con más efectividad? ¡Déjanos un comentario!