Este documento presenta la metáfora de la arqueología de software como un enfoque para analizar y comprender sistemas de software existentes de gran tamaño y complejidad. Explica conceptos como métricas, herramientas y métodos para mapear la estructura y dependencias del sistema, identificar áreas frágiles y de alto riesgo, y analizar la historia de desarrollo para entender cómo evolucionó el sistema. El objetivo final es generar una comprensión profunda del sistema que permita realizar cambios de manera segura y efectiva.

2. Motivación.
La metáfora de la arqueología.
Conceptos, principios y métricas útiles.
Antes de comenzar…
Métodos y herramientas de la arqueología de
software.
¿Qué falta?

4. De varios miles de líneas de código (KLOC)
Que no tiene documentación de diseño
O está obsoleta.
Los diseñadores/desarrolladores originales
posiblemente ya emigraron a pasturas más
verdes.

6. Con serios problemas de calidad.
Medidos por el número e impacto de defectos.
Resulta muy difícil / costoso realizar cambios.
Los dueños o desarrolladores están pensando en
rehacerlo.
Lo cual probablemente resultará en la misma
situación.
¿Por qué? Bueno…

10. Analizando desarrollos de otras personas.
Posiblemente a partir de un proyecto de código
abierto.
¿Qué patrones, tecnologías y estilos de
programación son realmente efectivos y en qué
situaciones?
¿Qué métodos producen que tipo de productos?

12. Entender sociedades y culturas antiguas
Principalmente a través de la recuperación y análisis
de los artefactos que dejaron.
Intenta responder a las siguientes preguntas:
¿Para qué sirve este artefacto?
¿Cómo lo crearon y usaron sus autores?
¿Qué estaban pensando cuando lo hicieron?
¿Cómo vivían quienes lo desarrollaron?
Parece aplicable a nuestros 3 escenarios =)

13. Es una metáfora útil para describir un enfoque y
método que permite abordar los escenarios
planteados anteriormente.
Pero hay unas diferencias muy obvias:
Las escalas de tiempo.
En el software,
Sin embargo…

16. Como mínimo:
Cohesión
Acoplamiento
Inestabilidad
Abstracción
Complejidad ciclomática

17. ingle responsibility principle
pen-Closed principle
iskov substitution principle
nterface segregation principle
ependency inversion principle
Robert C. Martin (Uncle Bob)
(Uncle
http://bit.ly/ooprinciples

19. Vas a experimentar, asegúrate que todo el
código está en control de versiones y que
siempre puedes regresar a la versión original.
Asegúrate de que todos los binarios pueden
generarse a partir del código fuente.

20. Tendrás que leer código, mucho y
probablemente de muy poca calidad.
Tendrás que programar, no hay herramientas
que contesten todas tus dudas.

21. Es mucha la
información que se
debe procesar para
realizar una
excavación y análisis.
Lo mejor es tomar
notas de todo, sin
repetir lo que ya
existe en el código
(DRY).

23. Es un acercamiento
“a vista de pájaro” a la
zona arqueológica.
Permite crear un
primer mapa donde se
identifican las
características
principales del
conjunto.

26. En software, el tamaño importa, ¡y mucho!
10 KLOC es muy distinto a 1 MLOC
¿Cuántas versiones “vivas” existen?
Debe medirse la distribución del
código desde diferentes perspectivas
Por lenguaje de programación.
Por estereotipo o capa de componentes.
Por módulo.

27. Por estereotipo o capa de componentes.
Stereotype files # lines of # lines of # blanks # code + % Total
code comment comment
Clients 1978 917530 39860 82610 957390 75.92%
Services 943 109535 9182 19264 118717 9.41%
PL/SQL 690 71292 7314 8009 78606 6.23%
Common 434 63036 6071 10298 69107 5.48%
Admin 82 34204 1403 4280 35607 2.82%
Installer 23 1287 317 161 16 04 0.13%
Total 4150 1196884 64147 124622 1261031
% Total
Clients
Services
PL/SQL
Common
Admin
Installer
Total

28. El “copy & paste” es en general un feo hábito.
Pero muy permeado.
Si hay mucho código duplicado, nos da una
indicación de que:
Los hábitos de los programadores no eran los
mejores.
El tamaño del sistema podría reducirse
considerablemente.

29. Código C#
Similarity threshold (lines) 15
Total number of duplicate lines 58177
Total number of duplicate blocks 1584
Total number of files with duplicates 658
Total number of files 2237
Total number of significant lines 214833
% Duplication 13.82%
Código SQL
Similarity threshold (lines) 15
Total number of duplicate lines 28358
Total number of duplicate blocks 644
Total number of files with duplicates 154
Total number of files 636
Total number of significant lines 56027
% Duplication 26.56%

30. Scatter Plot (demo)

31. Identificar módulos (de grano grueso) y sus
relaciones (grafo de dependencias).
Entender las responsabilidades, tamaño y
complejidad de cada módulo.
Identificar y caracterizar las fronteras del
sistema.
Determinar características como estabilidad,
fragilidad y flexibilidad al cambio.
A nivel sistema y a nivel módulo.

33. Métricas.
Cohesión
Acoplamiento
Abstracción
Estabilidad/Inestabilidad
Tamaño de clases y métodos.
Duplicación de código.
Evaluación de que tanto se aplican los principios
de buen diseño modular.
Matriz de dependencias (Design Structure Matrix)

35. Puede usarse para relacionar distintas capas.

36. Muchos módulos.
Muy pocos módulos en un sistema muy grande.
Demasiadas dependencias
Dependencias cíclicas
Cadenas muy largas de dependencias.
¿Qué constituye una modularización efectiva?
http://slidesha.re/cEwkuK
http://modularity.kirkk.com/

37. En tu mapa, debes tener perfectamente
identificadas las partes del sistema que:
Son más frágiles e inestables.
Son más propensas a tener bugs.
Han sufrido más cambios.
¿Cómo?
Métricas de complejidad, tamaño e inestabilidad.
Historial de cambios en el repositorio de código.
Los que más cambian, suelen ser muy importantes o tener
mal diseño ocasionado por corrección de muchos bugs.

38. Ejemplo: métodos con mayor complejidad

39. La historia te da una E-3.0.1
buena idea del proceso E-3.0.0 E-3.0.x-mtto
que llevó al sistema
actual, el cual puede E-2.0.2
ser sencillo o muy E-2.0.1
accidentado.
E-2.0.0 E-2.0.x-mtto
E-2.0.0-RC2
merge
E-2.0.0-RC1
Este es un ejemplo de
E-1.0.1
una historia sencilla E-1.0.1-RC2
E-1.0.1-RC1
E-1.0.0 E-1.0.x-mtto
E-1.0.0-RC1

40. Ejemplo de una historia muy accidentada
(micro-fragmento)

41. Commits (por 4º anual) en proyectos con desarrollo en
cascada
Commits (semanales) en proyectos con desarrollo
iterativo e incremental.
Count of Commits
Proyectos 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 Grand Total
Proyecto-1 5 7 82 89 109 265 13 85 120 187 197 82 39 59 38 24 1401

42. Una vista dinámica puede dar pistas cualitativas
sobre el ritmo de desarrollo.
Evolución de eclipse http://bit.ly/vO4Wc

43. http://www.spinellis.gr/codereading/

44. Recuerda que estás viendo el resultado de capa
tras capa de modificaciones.
Puede ser difícil descubrir la intención /
estructura original.

45. Probablemente aún puedes conocer a
programadores que participaron en el desarrollo
original (los nativos).
Haz amistad con ellos, que te cuenten su historia y
su tradición.
Aprende su
vocabulario y
dialecto.
Respétalos.

47. Herramientas más integradas.
Mejores visualizadores de código y repositorios.
Más herramientas open-source.
Publicaciones de arquéologos de software.
Más arqueólogos =)

49. Medición de LOC
cloc
Duplicación de código
PMD’s CPD, Checkstyle, Simian, CCFinder
Grafos de dependencias
JarAnalyzer, AssAnalyzer, NDepend, XDepend, SonarJ
Análisis de dependencias
NDepend, XDepend, SonarJ, Structure 101, Lattix DSM
Métricas de diseño
PMD, FxCop, NDepend, XDepend, Structure 101, SonarJ
Visualización de repositorios de código
gource, codeswarm

50. http://machinesareus.blogspot.com
Twitter: @MachinesAreUs
Twitter: @MachinesAreUs