Motivación.
La metáfora de la arqueología.
Conceptos, principios y métricas útiles.
Antes de comenzar…
Métodos y herramien...
De varios miles de líneas de código (KLOC)
Que no tiene documentación de diseño
   O está obsoleta.
Los diseñadores/desarr...
Con serios problemas de calidad.
   Medidos por el número e impacto de defectos.
Resulta muy difícil / costoso realizar ca...
Analizando desarrollos de otras personas.
Posiblemente a partir de un proyecto de código
abierto.
¿Qué patrones, tecnologí...
Entender sociedades y culturas antiguas
   Principalmente a través de la recuperación y análisis
   de los artefactos que ...
Es una metáfora útil para describir un enfoque y
método que permite abordar los escenarios
planteados anteriormente.
Pero ...
Como mínimo:

 Cohesión
 Acoplamiento
 Inestabilidad
 Abstracción
 Complejidad ciclomática
ingle responsibility principle
 pen-Closed principle
iskov substitution principle
nterface segregation principle
 ependenc...
Vas a experimentar, asegúrate que todo el
código está en control de versiones y que
siempre puedes regresar a la versión o...
Tendrás que leer código, mucho y
probablemente de muy poca calidad.
Tendrás que programar, no hay herramientas
que contest...
La cantidad de
información que se
debe procesar para
realizar una
excavación y análisis
es mucha.
Lo mejor es tomar
notas ...
Es un acercamiento
“a vista de pájaro” a la
zona arqueológica.

Permite crear un
primer mapa donde se
identifican las
cara...
En software, el tamaño importa, ¡y mucho!
   10 KLOC es muy distinto a 1 MLOC

¿Cuántas versiones “vivas” existen?

Debe m...
Por estereotipo o capa de componentes.
  Stereotype        files   # lines of # lines of # blanks # code +    % Total
    ...
El “copy & paste” es en general un feo hábito.
   Pero muy permeado.

Si hay mucho código duplicado, nos da una
indicación...
Código C#
Similarity threshold (lines)                15
Total number of duplicate lines          58177
Total number of du...
Scatter Plot (demo)
Identificar módulos (de grano grueso) y sus
relaciones (grafo de dependencias).
Entender las responsabilidades, tamaño y
c...
Métricas.
   Cohesión
   Acoplamiento
   Abstracción
   Estabilidad/Inestabilidad
   Tamaño de clases y métodos.
   Duplic...
Puede usarse para relacionar distintas capas.
Muchos módulos.
Muy pocos módulos en un sistema muy grande.
Demasiadas dependencias
Dependencias cíclicas
Cadenas muy larg...
En tu mapa, debes tener perfectamente
identificadas las partes del sistema que:
   Son más frágiles e inestables.
   Son m...
Ejemplo: métodos con mayor complejidad
La historia te da una                   E-3.0.1

buena idea del proceso       E-3.0.0                   E-3.0.x-mtto
que l...
Ejemplo de una historia muy accidentada
(micro-fragmento)
Commits en proyectos con desarrollo en cascada




Commits en proyectos con desarrollo iterativo e
incremental.
  Count of...
Una vista dinámica puede dar pistas cualitativas
sobre el ritmo de desarrollo.
Video (http://bit.ly/vO4Wc)
Recuerda que estás viendo es el resultado de
capa tras capa de modificaciones.
Puede ser difícil descubrir la intención /
...
http://www.spinellis.gr/codereading/
Probablemente aún puedes conocer a
programadores que participaron en el desarrollo
original (los nativos).
   Haz amistad ...
Herramientas más integradas.

Mejores visualizadores de código y repositorios.

Más herramientas open-source.

Publicacion...
Medición de LOC
    cloc
Duplicación de código
   PMD’s CPD, Checkstyle, Simian, CCFinder
Grafos de dependencias
   JarAna...
http://machinesareus.blogspot.com
        Twitter: @MachinesAreUs
        Twitter: @MachinesAreUs
Arqueología de software
Arqueología de software
Arqueología de software
Arqueología de software
Arqueología de software
Arqueología de software
Arqueología de software
Arqueología de software
Arqueología de software
Arqueología de software
Arqueología de software
Arqueología de software
Arqueología de software
Arqueología de software
Arqueología de software
Arqueología de software
Arqueología de software
Próxima SlideShare
Cargando en…5
×

Arqueología de software

2.616 visualizaciones

Publicado el

Presentada durante el SG Virtual Conference
http://www.sg.com.mx/sgvirtual/sesion/certum

Publicado en: Tecnología
0 comentarios
1 recomendación
Estadísticas
Notas
  • Sé el primero en comentar

Sin descargas
Visualizaciones
Visualizaciones totales
2.616
En SlideShare
0
De insertados
0
Número de insertados
16
Acciones
Compartido
0
Descargas
1
Comentarios
0
Recomendaciones
1
Insertados 0
No insertados

No hay notas en la diapositiva.

Arqueología de software

  1. 1. 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?
  2. 2. 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.
  3. 3. 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…
  4. 4. 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?
  5. 5. 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 =)
  6. 6. 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…
  7. 7. Como mínimo: Cohesión Acoplamiento Inestabilidad Abstracción Complejidad ciclomática
  8. 8. 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
  9. 9. 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.
  10. 10. Tendrás que leer código, mucho y probablemente de muy poca calidad. Tendrás que programar, no hay herramientas que contesten todas las posibles preguntas.
  11. 11. La cantidad de información que se debe procesar para realizar una excavación y análisis es mucha. Lo mejor es tomar notas de todo, sin repetir lo que ya existe en el código (DRY).
  12. 12. 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.
  13. 13. 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.
  14. 14. 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
  15. 15. 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.
  16. 16. 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%
  17. 17. Scatter Plot (demo)
  18. 18. 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. Caracterizar características como estabilidad, fragilidad y flexibilidad al cambio. A nivel sistema y a nivel módulo.
  19. 19. 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)
  20. 20. Puede usarse para relacionar distintas capas.
  21. 21. 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/
  22. 22. 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.
  23. 23. Ejemplo: métodos con mayor complejidad
  24. 24. 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
  25. 25. Ejemplo de una historia muy accidentada (micro-fragmento)
  26. 26. Commits en proyectos con desarrollo en cascada Commits 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 Py-1 5 7 82 89 109 265 13 85 120 187 197 82 39 59 38 24 1401 Grand Total 5 7 82 89 109 265 13 85 120 187 197 82 39 59 38 24 1401
  27. 27. Una vista dinámica puede dar pistas cualitativas sobre el ritmo de desarrollo. Video (http://bit.ly/vO4Wc)
  28. 28. Recuerda que estás viendo es el resultado de capa tras capa de modificaciones. Puede ser difícil descubrir la intención / estructura original.
  29. 29. http://www.spinellis.gr/codereading/
  30. 30. 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 Respétalos.
  31. 31. 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 =)
  32. 32. 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
  33. 33. http://machinesareus.blogspot.com Twitter: @MachinesAreUs Twitter: @MachinesAreUs

×