Métricas: LOC

LOC es un acrónimo de “Lines of Code”. Se utiliza como métrica en diversas situaciones, en las que se mide el número de líneas de código. Usualmente, se utiliza la variante “KLOC”, que son miles de líneas de código.

¿Que qué le pasa a esta métrica? Pues que está maldita. Sí, sí, maldita. Ni el exhorcista más aguerrido podría devolverle el honor a esta defenestrada medida. Pero en fin, como me gustan las causas perdidas…ahí vamos.

¿Porqué está maldita? Pues porque basta presentarla para que la gente ponga caras raras, empiece a generar excusas, exponga argumentos en su contra, etc. Sin embargo, esta métrica tiene cosas a su favor, al menos en apariencia:

  • Es fácil de medir. Pues sí, eso es cierto. Prácticamente cualquier entorno lo ofrece, y todos los plugins de métricas lo ofrecen.
  • Es fácil de combinar: muchas otras métricas pueden venir referidas a ella (Ejemplo: “nº de defectos por cada mil líneas de código”).
  • Ofrece una medida aproximada del tamaño de un software, y de su complejidad. Pues vaya, esto también es cierto. Un programa de 1000 líneas no sé si será el doble de grande que otro de 500, pero más grande, sí.

Sin embargo, en este mundillo se encuentran muchos argumentos en su contra:

  • No es una medida fiable de productividad personal. La respuesta obvia sería: “pues claro”. En este mundillo de las métricas, uno aprende que lo primero que hace un programador es ver en qué medida la métrica puede valorar su trabajo. Es el caso típico de: “pensar mal”. El problema es que las métricas están siempre para conocer el proyecto, y no siempre para ver el rendimiento de las personas. Sin embargo, sí puede obtenerse (y se debe, de hecho) métricas del estilo: LOC totales por persona, LOC modificadas por persona en un período, LOC nuevas por persona en un período, etc.
  • Penaliza a lenguajes de alto nivel. Toma, pues claro. Los lenguajes de alto nivel están para eso. Para que con menos líneas, se hagan más cosas. Lo mismo que los frameworks y las librerías: para ahorrar líneas de código. Pero de nuevo volvemos a lo mismo: esta métrica permite comparar sólo en el caso de que se pueda comparar. No podemos comparar solamente lenguajes similares, sino proyectos en que la arquitectura sea equivalente.
  • La complejidad de un software no depende de su tamaño. Hay programas muy pequeños, endiabladamente retorcidos, mientras que hay otros muy grandes, pero muy simples en concepción y ejecución. De nuevo, la respuesta es “pues claro”. El problema es que una métrica no es más que un número. Para obtener conclusiones, normalmente hay que usar varias métricas e indicadores de los proyectos.

La conclusión vendría a ser que esta medida es para lo que es, para apoyo, para dar una visión orientativa que por sí sola nunca puede ser concluyente (lo que no deja de ser cierto en general para prácticamente todas las métricas).

Desde luego, si no podemos medir algo, no podremos decir que esté bajo control.

Anuncios

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s