Ya se acabaron las vacaciones, es hora de volver a nuestros posts.

Tengo bastante ideas para esta nueva temporada, pero voy a empezar con un ‘quiz’.

Se te pide clasificar una aplicación según su tamaño, el número de líneas de código (LOC) o el número de objetos. ¿Cuál es tu estimación de una pequeña aplicación? Cuando dices que una aplicación es grande? Con qué valores crees que es ‘monstruosa’ o atípica?

Esta cuestión se encuentra bastante y, en mi experiencia, es difícil responder con precisión y certeza.

Se te pide ‘200 000 líneas de código Java, es una aplicación de gran tamaño?’ o ‘500 programas Cobol, es grande? ‘. Puede ser tu jefe o un vendedor a quien un cliente solicita una idea de los costes de mantenimiento para una aplicación de este tamaño. Puede ser un responsable de proyecto en tu empresa que quiere una auditoría de calidad de su aplicación, pero le gustaría saber cuánto tiempo se necesita para analizar el código.

No estoy hablando de esfuerzo de desarrollo o del mantenimiento de una aplicación o de la productividad del programador. Algunas personas consideran que la métrica LOC es una ‘malpractice’ y estoy totalmente de acuerdo en que no se debe utilizar para medir la productividad, el esfuerzo de desarrollo o las funcionalidades de una aplicación. Sin embargo, cuando se analiza el código de una aplicación, me gusta saber si se trata de una pequeña aplicación o de un enorme monstruo. Todos los consultores en Calidad de código tienen esta pregunta, y cada uno su propia estimación, que siempre es interesante compartir.

A continuación, los valores que utilizo:

Tamaño en KLoc

Por ejemplo, una aplicación J2EE es:

• De tamaño reducido por debajo de 50 000 LOC.
• De tamaño medio entre 50 KLoc et 200 KLoc.
• De tamaño alto entre 200 KLoc et 400 Kloc.
• De tamaño muy alto hasta 1 000 Kloc.

Más allá de 1 millón de líneas de código J2EE, creo que una aplicación es ‘monstruosa’. Nota: en la mayoría de los casos, no será una aplicación única, sino más bien un sistema compuesto por varios módulos aplicativos. Pero cualquiera que sea el nombre, aplicación o sistema, si este código está entre las manos de un único equipo de proyecto, entonces se enfrenta a un Everest. Con los problemas específicos a la gestión de esta montaña de código.

La siguiente tabla muestra la misma evaluación, pero basada en el número de objetos.

Tamaño en numero de objetos

Muy a menudo, el número de objetos es la única indicación que tenemos: pocos clientes o jefes de proyecto conocen el número de líneas de código de su aplicación. Y esta información puede ser engañosa.

Por ejemplo, tienes una aplicación con 800 programas Cobol, y la persona encargada de realizar esta extracción entrega además los 20 000 Copy-books que se encuentran en el mainframe, porque no sabia cuales son los utilizados por la aplicación. A primera vista, esta es más que super-monstruosa, pero probablemente hay solamente 2 o 3% de las Copys que trabajan con esta aplicación, por lo tanto, de tamaño medio. Pero si decides analizar todos las Copys, entonces tienes un gran trabajo por delante para un resultado que no tiene mucho sentido, en términos de auditoría de aplicación, porque el perimetro de análisis no se corresponde con una aplicación o un equipo de proyecto.

A veces hay una aplicación J2EE con un montón de páginas JSP o un gran número de archivos de configuración XML (especialmente con algunos frameworks) y pocas clases. De nuevo, el número de objetos o líneas de código no será realmente representativo.

He tenido muchas conversaciones sobre este tema con profesionales de auditoría de calidad de código, y todos estamos de acuerdo que esto es una indicación que puede variar considerablemente como se muestra en los ejemplos anteriores. Pero a veces hay que responder a la pregunta ‘¿Es una aplicación grande?’ sin más datos.

Y tú, ¿cómo clasificas a una aplicación?

Esta entrada está disponible también en Lire cet article en français y Read that post in english.