Mide tu deuda técnica… ¡en 5 min!

Fácil (detectarla, otra cosa es eliminarla). Ya hubo en su día, hace años, varios post relacionados con este. Sí, pero años después, he creído conveniente volver a sacar del armario el tema.

Sí, porque se ha puesto de moda la “deuda técnica”, ya sabes, eufemismo que habla de los intereses que vas a pagar por hacer, o dejar hacer, mal y mala tecnología, desde mala programación a mal diseño, pasando por pruebas, etc. Problemón nacional que no saldrá en los periódicos, pero que está frenando la competitividad de un altísimo número de organizaciones que ya saben que hoy, se dediquen a lo que se dediquen, compiten en negocios basados en software, donde la velocidad es vital. Empresas que venden “cosas”, servicios, por internet, o que necesitan Apps, etc.

Y pareciera que esto es algo nuevo, que hubiera crecido de repente, pero no, no, llevaba años ahí, incubando, germinando, para manifestarse hoy y hacer que cambiar una línea de código sea un infierno.

Como te he contado en muchas ocasiones, te puedes perder en un mar de métricas y datos que indican cómo de mal o bien se ha hecho el software que soporta tu negocio, e incluso perder el horizonte, pero no… nosotros vayamos a lo práctico, vayamos a una aproximación rápida y barata.

Te propongo lo siguiente. Pídele a alguien con mínimos conocimientos técnicos que haga uso de algún software de evaluación de la calidad del código, puedes usar librerías de software libre, fáciles de encontrar, software más complicado, como Sonar, o software en “cloud”, más fácil aún, como es Kiuwan (si todos estos te suenan a chino, habla con alguien técnico que rápidamente sabrá identificarlos). Para lenguajes como Java es fácil encontrar software de uso gratuito, para otros lenguajes puedes hacerte con alguna versión de evaluación.

Y calcula, te aseguro que es cuestión de minutos, tres métricas, sólo tres, sé que los nombres suenan raros pero confía, no es nada del otro mundo, mide el “porcentaje de código repetido”, la “complejidad ciclomática” y el tamaño en líneas de código de la clase con más líneas de código. Ya está. A ver qué sale.

Más de un 0% de “porcentaje de código repetido”, mal asunto, venga más de un 10%, seamos flexibles (muy flexibles). Algoritmos con más de 30 en “complejidad ciclomática” mal asunto. Clases con… aquí hay debate… ¿más de 300 líneas de código?.. mal asunto.

¿Qué? ¿Cómo te ha ido? ¿Alguna sorpresa? Esto es como los análisis del médico, si los valores del análisis son buenos, enhorabuena. Si son malos… difícil solución. Si son muy malos quizá ya no seas humano, quizás… te hayas convertido en un zombi, algo con apariencia humana pero que más que un software es algo que va errando por la faz de la tierra, medio vivo, medio muerto.

Si esta aproximación (sí, sé que se puede hilar más fino, pero las anteriores métricas te van a dar una buena foto) no salió muy bien… ve tirando del hilo, porque los problemas de productividad en tu organización no vienen de echar más horas, o de poner un sistema de fichar… vienen de software malo generado durante años que se está comiendo tu organización.

Javier Garzás

3 comentarios en “Mide tu deuda técnica… ¡en 5 min!”

  1. Nicolás Bersieri

    Hola Javier, este parrafo está muy poco claro:
    «Más de un 0% de “porcentaje de código repetido”, mal asunto, venga más de un 10%, seamos flexibles (muy flexibles). Algoritmos con más de 30 en “complejidad ciclomática” mal asunto. Clases con… aquí hay debate… ¿más de 300 líneas de código?.. mal asunto.»
    Parece más hablado que escrito. Si puedieras modificarlo para hacerlo más claro, te lo agradecería. Crítica constructica 🙂 Saludos!!

  2. Muy de acuerdo con las métricas. Yo añadiría el tamaño de método. Si tienes muchos métodos de más de 20 líneas, malo.
    Si controlas el tamaño de los métodos, controlarás la CC y te guiará a tener un código más autodocumentado.

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Ir arriba