Blog de Miguel Llopis

December 2009 - Artículos

Por qué no me gusta la métrica LOC (Lines Of Code)

[ Aprovechando las vacaciones navideñas y las 15 horas de vuelos desde Seattle hasta España para redactar unos cuantos posts que tenía en mente desde hace tiempo… ]

Hoy os hablaré sobre por qué considero que LOC no es una métrica de código demasiado útil (por decirlo eufemísticamente), algo sobre lo que estoy seguro de que habréis leído ya en bastantes ocasiones pero me gustaría aportar mi visión particular.

De vez en cuando me he encontrado con gente que me realiza preguntas del tipo: “¿Cuántas líneas de código tiene el proyecto Oslo SQL Server Modeling Services?" (cambiad esta última parte por Windows 7, o Visual Studio 2010, o SQL Server 2008, etc), o también “Miguel, ¿cuantas líneas de código escribes al día?”…

En el caso de la segunda pregunta, mi respuesta suele ser: “En algunos de los mejores días de mi vida como desarrollador, mi LOC ha sido un valor negativo. Afortunadamente, LOC no es directamente proporcional a mi productividad”.   : )

Hay dos matices que considero bastante descriptivos en cuanto a LOC:

  1. Para lo único que LOC es una medida válida es para medir el tamaño de la base de código de un proyecto.
  2. Un valor de LOC enorme en nuestra codebase no resulta ser, en muchas ocasiones, algo bueno.

Mi opinión personal es que LOC es prácticamente inútil para gestión de proyectos, para lo único que nos sirve es para hacer análisis del tipo:

  1. El módulo A es el doble de grande que el módulo B. (considerando que ambos están escritos en el mismo lenguaje (aunque esto sería también discutible, hay estudios que afirman que LOC es independiente del lenguaje empleado, pero no estoy de acuerdo en la mayoría de casos), que las coding guidelines son las mismas para ambos, etc… En cualquier otro caso, ni siquiera serían comparables)
  2. El módulo C ha crecido un 25% en los últimos 6 meses.
  3. Podemos ver cómo el módulo D tiene un elevado número de bugs, debido a su gran tamaño.

Para cuestiones relacionadas con el análisis del crecimiento/progreso en un determinado proyecto, es claramente mejor fijarse en otras métricas diferentes a LOC, como por ejemplo el número de features completadas/pendientes, etc. Si empleáramos LOC, el análisis sería incorrecto ya que alguien podría añadir 1.000 líneas de código a un proyecto sin completar una feature concreta, de igual forma que alguien podría eliminar 1.000 líneas de código y ser capaz de completar tres features.

Respecto a este último ejemplo, comentar que un índice LOC negativo es en bastantes casos el resultado de un trabajo de refactorización de código realizado como parte de la implementación de una nueva feature y puede tener un impacto significativo en el tamaño global de nuestra base de código.

Ahora que ya os he dado mi opinión personal, veamos qué dicen otras fuentes más documentadas que yo al respecto. Por ejemplo, la siguiente tabla (extraída del libro “Code Complete”) nos muestra la relación entre el tamaño del proyecto y el LOC por persona/año:

Tamaño del proyecto (LOC) LOC por persona/año
1.000 2.5K - 25K
10.000 2K - 25K
100.000 1K - 20K
1.000.000 0.7K - 10K
10.000.000 0.3K - 5K

El aspecto a destacar en esta tabla es que la cantidad de líneas de código que un desarrollador es capaz de escribir disminuye a medida que el proyecto aumenta de tamaño. Esto se debe a diversos factores, como son el hecho de que la complejidad aumenta, el impacto de las modificaciones realizadas es mucho mayor en otras partes del proyecto, el esfuerzo de testing necesario aumenta, el número de bugs aumenta, etc.

Por tanto, idealmente, un buen desarrollador no es aquel con mayor LOC, sino con mayor ratio Feature/LOC ya que eso significaría que el desarrollador está implementando nuevas funcionalidades (y por tanto aportando valor añadido para el cliente) a la vez que mantiene el tamaño de code base en unos límites razonables, lo cual permite incrementar la productividad de él mismo y del resto de compañeros en el equipo de desarrollo del proyecto.

Otros factores negativos sobre LOC los podemos encontrar en el libro “Applied Software Measurement” de Capers Jones, entre los que destacaré los siguientes:

  1. Las métricas LOC penalizan a los lenguajes de programación de alto nivel.
  2. Análisis comparativos de proyectos en los que se ha empleado más de un lenguaje de programación y que se fundamenten en LOC deberán ser considerados una mala práctica profesional.
  3. Las métricas de “Coste por bug” penalizan la calidad y hacen que un software lleno de bugs pueda parecer mejor de lo que en realidad es, a juzgar por los resultados de un estudio basado en LOC. Para este tipo de estudios, es mejor emplear métricas de Puntos de Función.

Por último, me gustaría recomendar otro libro bastante interesante “Measuring and Managing Performance in Organizations”, de Robert Austin. En este libro, Austin entrevista a varios expertos de la industria del software que aportan su opinión acerca de qué cosas conviene (o no) medir. Al final, casi todos ellos coinciden en que medir todo aquello que convendría medir en el desarrollo software es prácticamente imposible…

Merry Christmas!

Posted: 21/12/2009 20:15 por Miguel LLopis | con 3 comment(s)
Archivado en: