La arqueología del software o la arqueología del software es el estudio de implementaciones de software heredado mal documentadas o no documentadas , como parte del mantenimiento del software . [1] [2] La arqueología de software, nombrada por analogía con la arqueología , [3] incluye la ingeniería inversa de módulos de software y la aplicación de una variedad de herramientas y procesos para extraer y comprender la estructura del programa y recuperar información de diseño. [1] [4]La arqueología del software puede revelar procesos de equipo disfuncionales que han producido módulos de software mal diseñados o incluso no utilizados y, en algunos casos, se puede encontrar código deliberadamente ofuscatorio. [5] El término se ha utilizado durante décadas, [6] y refleja una metáfora bastante natural: un programador que lee un código heredado puede sentir que está en la misma situación que un arqueólogo que explora los escombros de una civilización antigua. [7]
Técnicas
Un taller sobre Arqueología de Software en la conferencia OOPSLA (Programación Orientada a Objetos, Sistemas, Lenguajes y Aplicaciones) de 2001 identificó las siguientes técnicas de arqueología de software, algunas de las cuales son específicas de la programación orientada a objetos : [7]
- Lenguajes de secuencias de comandos para crear informes estáticos y para filtrar resultados de diagnóstico
- Documentación continua en páginas HTML o wikis
- Herramientas de visualización de software , análisis estadístico y análisis de firmas sinópticas
- Herramientas de ingeniería inversa
- Seguimiento a nivel del sistema operativo mediante truss o strace
- Motores de búsqueda y herramientas para buscar palabras clave en archivos fuente.
- Navegación de archivos IDE
- Marcos de prueba unitarios como JUnit y CppUnit
- Generación de documentación API usando herramientas como Javadoc y doxygen
- Depuradores
De manera más general, Andy Hunt y Dave Thomas señalan la importancia del control de versiones , la administración de dependencias , las herramientas de indexación de texto como GLIMPSE y SWISH-E , y "[dibujar] un mapa mientras comienza a explorar". [7]
Como la verdadera arqueología, la arqueología del software implica un trabajo de investigación para comprender los procesos de pensamiento de nuestros predecesores. [7] En el taller de OOPSLA, Ward Cunningham sugirió una técnica de análisis de firma sinóptica que daba una "sensación" general de un programa al mostrar solo signos de puntuación, como punto y coma y llaves . [8] En la misma línea, Cunningham ha sugerido ver los programas en fuente de 2 puntos para comprender la estructura general. [9] Otra técnica identificada en el taller fue el uso de herramientas de programación orientadas a aspectos como AspectJ para introducir sistemáticamente el código de rastreo sin editar directamente el programa heredado. [7]
Las técnicas de análisis temporal y de redes pueden revelar los patrones de actividad colaborativa de los desarrolladores de software heredado, lo que a su vez puede arrojar luz sobre las fortalezas y debilidades de los artefactos de software producidos. [10]
Michael Rozlog de Embarcadero Technologies ha descrito la arqueología del software como un proceso de seis pasos que permite a los programadores responder preguntas como "¿Qué acabo de heredar?" y "¿Dónde están las secciones aterradoras del código?" [11] Estos pasos, similares a los identificados por el taller de OOPSLA, incluyen el uso de la visualización para obtener una representación visual del diseño del programa, el uso de métricas de software para buscar infracciones de diseño y estilo, el uso de pruebas unitarias y la creación de perfiles para buscar errores y rendimiento. cuellos de botella y recopilación de información de diseño recuperada por el proceso. [11] La arqueología del software también puede ser un servicio proporcionado a los programadores por consultores externos. [12]
Mitch Rosenberg de InfoVentions.net, Inc. afirma [ cita requerida ] que la primera ley de la arqueología del software (él la llama código o arqueología de datos) es:
Todo lo que hay está ahí por una razón, y hay 3 posibles razones:
- Solía necesitar estar allí, pero ya no lo hace.
- Nunca necesitó estar allí y la persona que escribió el código no tenía ni idea
- TODAVÍA necesita estar ahí y USTED no tiene ni idea
El corolario de esta "ley" es que, hasta que sepa cuál fue la razón, NO debe modificar el código (o los datos).
La arqueología del software ha seguido siendo un tema de debate en las conferencias de ingeniería de software más recientes. [13]
La profesión de programador-arqueólogo ocupa un lugar destacado en Vernor Vinge 's Un abismo en el cielo . [14]
Ver también
- Recuperación de la arquitectura de software
- Código de refactorización
- Retrocomputación
- Fragilidad del software
- Podredumbre de software
- Entropía de software
- Abandonware
Referencias
- ^ a b Robles, Gregorio; González-Barahona, Jesús M .; Herraiz, Israel (2005). "Un enfoque empírico de la arqueología del software" (PDF) . Actas de póster de la Conferencia Internacional sobre Mantenimiento de Software .
- ^ Ambler, Scott W. "Análisis de sistemas heredados ágiles y modelado de integración" . agilemodeling.com . Consultado el 20 de agosto de 2010 .
Sin documentación precisa o sin acceso a personas con conocimientos, su último recurso puede ser analizar el código fuente del sistema heredado ... Este esfuerzo a menudo se conoce como arqueología de software.
- ^ Moyer, Bryon (4 de marzo de 2009). "Arqueología de software: modernización de sistemas antiguos" (PDF) . Revista de tecnología integrada .
- ^ Hopkins, Richard; Jenkins, Kevin (2008). "5. El mítico Metaman" . Comer el elefante de la tecnología de la información: Pasar del desarrollo greenfield al brownfield . Addison-Wesley. pag. 93. ISBN 978-0-13-713012-2.
- ^ Spinellis, Diomidis ; Gousios, Georgios (2009). "2. Una historia de dos sistemas § Falta de cohesión" . Hermosa arquitectura . O'Reilly. pag. 29. ISBN 978-0-596-51798-4.
- ^ Una de las primeras discusiones es Grass, Judith E. (invierno de 1992). "Arqueología del diseño orientado a objetos con CIA ++" (PDF) . Sistemas informáticos . 5 (1).
- ^ a b c d e Hunt, Andy ; Thomas, Dave (marzo-abril de 2002). "Arqueología de software" (PDF) . Software IEEE . 19 (2): 20-22. doi : 10.1109 / 52.991327 .
- ^ Cunningham, Ward (2001). "Encuesta de firma: un método para navegar por código desconocido" . Declaración de posición del taller, Arqueología de software: comprensión de grandes sistemas, OOPSLA 2001 .
- ^ Cook, John D. (10 de noviembre de 2009). "Arqueología de software" . El esfuerzo .
- ^ de Souza, Cleidson; Froehlich, Jon; Dourish, Paul (2005). "Buscando la fuente: el código fuente del software como un artefacto social y técnico" (PDF) . Actas de la Conferencia Internacional ACM SIGGROUP de 2005 sobre el trabajo grupal de apoyo . págs. 197–206. doi : 10.1145 / 1099203.1099239 . ISBN 1595932232.
- ^ a b Rozlog, Michael (28 de enero de 2008). "Arqueología de software: ¿Qué es y por qué deberían preocuparse los desarrolladores de Java?" . java.sys-con.com.
- ^ Sharwood, Simon (3 de noviembre de 2004). "En busca del código perdido" . ZDNet .
- ^ Por ejemplo, el "32ª Conferencia Internacional ACM / IEEE sobre Ingeniería de Software" . Mayo de 2010..
- ^ Rees, Gareth (12 de junio de 2013). "Arqueología de software y deuda técnica" .
enlaces externos
- "Documentos de posición" . Taller OOPSLA 2001 sobre Arqueología de Software: Comprensión de Grandes Sistemas . Archivado desde el original el 12 de junio de 2010.
- "Escritura de código, lectura de código y arqueología de software" . Una vez más en el código . Computerworld . 23 de septiembre de 2009. Archivado desde el original el 29 de enero de 2011.
- Rozlog, Michael (13 de marzo de 2008). "Cómo aplicar la arqueología del software a su proceso de desarrollo" (PDF) .
- "Podcast de OOPSLA 2008 con Grady Booch sobre arqueología de software y temas relacionados" (Podcast). 2008. Archivado desde el original el 26 de septiembre de 2011.