¿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í.
- 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.
Desde luego, si no podemos medir algo, no podremos decir que esté bajo control.
Hola me agrada la forma en la que lo explicas lo haces entendible pero me podrías decir cuales son tus fuentes de referencia (Bibliografías ) Gracias
ResponderEliminarHola Fernando, el problema es que en casos como éste, menciono que estoy en contra de tendencias de opinión que he leído en un período. Pero no de un artículo o blog o libro en particular. Simplemente cuando me canso de ver referencias con las que no estoy totalmente alineado, me animo a defender esa "causa perdida", yendo en contra de dichos artículos. Pero para cuando me animo a escribir el artículo, ya no recuerdo dónde lo leí, o no lo encuentro y directamente prefiero no mencionarlo ya que tampoco tengo un interés específico en ir contra nadie, sino en expresar una opinión basada en diversos factores (experiencia, metodologías distintas, etc). Si buscas en google sobre esta métrica en particular (LOC o KLOC), fácilmente encontrarás artículos que desprecian o critican esta métrica en particular. Ocurre mucho en el mundo de las metodologías ágiles. Pero como lo que busco es dejar escritas mis reflexiones, y no un artículo como tal, pues no me molesto. En el fondo este blog para mí no es más que eso, un registro de mi experiencia profunda, no trato de vender nada ni convencer a nadie. Pero se agradece que me hayas leído y te pueda ayudar.
Eliminar