Aplicación Legacy C – ¿Refactorización o reingeniería? (II)

WordCLegacy_UseCases2Continuamos esta serie sobre los diferentes casos de uso que puedan surgir en relación con la transferencia de una aplicación Lecagy en C, desde el análisis del código fuente de Word 1.1a, la primera versión de este software de Microsoft publicado en 1990.

Los dos primeros articulos se dedicaron a las métricas cuantitativas de tamaño (LOCs), de complejidad (CC), el nivel de comentarios y de duplicación, así como los diferentes tipos de ‘Issues’ Blocker, Critical, Major y Minor.

Con el fin de poder medir el coste de diferentes estrategias, incluyendo refactorización y reingenieria, hemos empezado a trabajar en la Complejidad Ciclomática (CC ) de las funciones y su distribución. Ahora vamos a realizar el mismo trabajo con los programas para identificar cuáles son los más complejos y / o que incorporan también funciones complejas.

Complejidad

Programas

La siguiente tabla presenta la distribución de la complejidad entre los archivos:

Tabla 4 – Complejidad Ciclomática de los programas de la aplicación Word Opus

Word_Files_Distrib171 ficheros no tienen Complejidad Ciclomática (CC). Encontré 130 archivos .h en la aplicación, la mayoría de ellos con definición de estructuras de datos y constantes, sin ningún algoritmo que corresponde a una regla funcional o técnica. Por otro lado, 156 archivos tienen una CC por encima de 90 puntos, por lo que esta aplicación es extremadamente polarizada entre archivos con un bajo nivel o incluso cero complejidad y archivos con alta complejidad. O muy elevada, ya que de nuevo, una regla de tipo ‘Major’ me permite identificar 159 archivos con más de 80 puntos de CC.

Word_Avoid_Cplx_FilesAl igual que con la funciones, he calculado la distribución de los archivos más complejos.

Tabla 5 – Distribución de los ficheros más complejos

Word_Files_Distrib2159 programs, o el 45,6% de los 349 archivos que cuenta esta aplicaciòn, tienen más de 80 puntos de CC, para un total entre ellos de 43 058 puntos de CC, el 98,2 % del total de la Complejidad Ciclomática (43 846). ¡Cuando os digo que esta aplicación está muy polarizada en términos de complejidad de los programas!

Podemos notar 24 archivos con más de 400 puntos de CC, por lo que de nuevo – al igual que las funciones – un número limitado de objetos (15%) constituye una parte importante (30%) de la complejidad general. Si sumamos los 27 archivos con más de 300 puntos de CC, tenemos 51 programas (14,6% de todos los 349 ficheros de la aplicación) por encima de 300 CC y una complejidad total de (12 860 + 9 472) igual a 22 332, o sea 51% de toda la Complejidad Ciclomática para toda la aplicación (43 846).

También comprobé cómo se reparten las funciones más complejas en estos programas:

  • 3 archivos de más de 400 CC tienen al menos una función de más de 200 CC y una función de más de 100 CC (en rojo en la figura siguiente).
  • 1 archivo de más de 400 CC y 2 archivos de más de 300 CC con al menos una función de más de 200 CC (naranja oscuro).
  • 7 archivos con más de 400 CC con al menos una función de más de 100 CC (naranja claro).
  • 6 archivos con más de 300 CC con al menos una función de más de 100 CC (amarillo).

Figura 1 – Convergencia de las funciones y de los programas más complejos

Word_Fn_Distrib Ahora conocemos las funciones y los programas que tratar con prioridad, en los que debemos enfocar primero nuestros esfuerzos, con una evaluación de su nivel de complejidad.

Tamaño

Como lo hemos visto en el post anterior, el tamaño es también un elemento de evaluación de los esfuerzos de refactorización o de reingeniería.

Funciones

De nuevo tengo una regla que me permite identificar las funciones que superan un umbral de tamaño más allá de 100 líneas de código (LOCs).Word_AvoidFnsSizeDe nuevo he calculado la distribución de funciones con el mayor número de LOCs.

Tabla 6 – Distribución de las funciones por tamaño

Word_FunctionsSize_DistribEn 478 funciones con más de 100 LOCs:

  • 3 funciones superan las 1 000 líneas de código.
  • 21 tienen más de 500 líneas de código.
  • 126 están entre 200 et 500 líneas de código.

También he buscado una convergencia entre el tamaño (LOC) y la Complejidad Ciclomática, con los siguientes resultados :

  • La función más compleja, con 355 puntos de CC, cuenta con 2 063 líneas de código (en el archivo ‘Opus\RTFOUT.c’).
  • En las 6 más complejas funciones, más allá de 200 CC, 3 tienen un tamaño superior a 1 000 LOCs (incluida la anterior), otras dos exceden las 700 líneas y la última llega a 393 líneas.
  • De las 30 funciones identificadas anteriormente con más de 100 CC, 15 tienen un tamaño entre 500 y 1 000 LOCs, y el resto entre 250 y 500 LOCs.

Sin sorpresa, encontramos estas funciones en los archivos marcado en rojo/naranja en la Figura 1 anterior.

Programas

Hemos visto que la complejidad era muy polarizada entre los programas, con 159 de ellos más allá de los 80 puntos de CC. Una otra regla nos permite también identificar 149 archivos con más de 1 000 líneas de código.

Word_AvoidPgmSizeTenemos 9 ficheros más allá de 3 000 líneas, incluyendo 1 con 4 117 LOCs, y 36 archivos entre 2 000 y 3 000 líneas. He comprobado si estos 9 programas más importantes incluyen funciones también grandes, y en qué proporción (número y tamaño de estas funciones).

Tabla 7 – Convergencia de los programas más voluminosos con las funciones de tamaño alto

Word_FilesFns_SizeLa columna ‘Nbr. Functions’ lista el número de funciones de más de 100 LOCs en el archivo, y luego las 3 columnas ‘Funcion size’ el número de funciones más allá de 1 000 / 500 / 200 LOCs. Por ejemplo:

  • El programa ‘Opus\Wordtech\select.c’ tiene 7 funciones de más de 100 líneas, 1 de ellas con más de 500 líneas y 5 con más de 200 líneas.
  • El programa ‘Opus\interp\elcore.c’ tiene 5 funciones de más de 100 líneas, 1 con más de 1 000 líneas y 1 de más de 500 líneas.

Podemos ver que el número de funciones de grande tamaño disminuye en proporción con el tamaño del programa. Encontré dos excepciones:

  • El archivo ‘RTFOUT.c’ con 2 222 LOCs y la función más compleja, con 355 puntos de CC y 2 063 líneas de código.
  • El archivo ‘formula.c’ con 2 179 LOCs y una función de más de 1000 líneas de código.

También, en los 36 archivos entre 2 000 y 3 000 LOCs:

  • 8 progamas entre 2 000 y 3 000 LOCs tienen 10 funciones con más de 500 LOCs, incluyendo 6 con al menos una función adicional de más de 200 LOCs.
  • 25 ficheros entre 2 000 y 3 000 LOCs tienen 25 funciones entre 200 y 500 LOCs.PictComplexity

Hemos identificado las funciones y los programas que pesan más en el esfuerzo y por lo tanto en los costes de refactorización y reingenieria, por su complejidad y tamaño.

En el próximo post, vamos a comprobar si estos archivos también contienen defectos estructurales (bloques anidados, Goto, etc.) que podrían hacer aún más difícil la comprensión y la evolución del código.

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

Deja una respuesta

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