La arqueología del software es el estudio de implementaciones de software heredado mal documentado o indocumentado, como parte de su mantenimiento de software .
La arqueología del software, nombrada por analogía con la arqueología , incluye la ingeniería inversa de módulos de software y la aplicación de diversas herramientas y procesos para extraer y comprender la estructura de los programas y recuperar información de diseño. 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. El término se ha utilizado durante años y refleja una metáfora bastante natural: un desarrollador que lee un código antiguo puede sentir que se encuentra en la misma situación que un arqueólogo que explora las ruinas de una civilización antigua.
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 :
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 "[dibuje] un mapa cuando comience a explorar".
Al igual que en la arqueología, la arqueología del software implica un trabajo de investigación para comprender los procesos de pensamiento de sus predecesores. En el taller de OOPSLA, Ward Cunningham sugirió una técnica de análisis de firma sinóptica que le dio una “sensación” general a un programa mostrando solo puntuación, como punto y coma y llaves. En la misma línea, Cunningham sugirió ver programas en Police 2 para comprender la estructura general. Otra técnica identificada durante el taller fue el uso de herramientas de programación orientadas a aspectos como AspectJ para introducir sistemáticamente el código de trazado sin modificar directamente el programa existente.
Las técnicas de análisis de red e historial de cambios pueden revelar los patrones de actividad colaborativa de los desarrolladores de software heredados, lo que a su vez puede arrojar luz sobre las fortalezas y debilidades de los artefactos de software producidos.
Michael Rozlog de Embarcadero Technologies describió 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 partes aterradoras del código? " . 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 encontrar infracciones de diseño y estilo, el uso de pruebas unitarias y la creación de perfiles para buscar errores y cuellos de botella de rendimiento, y recopilar información de diseño recuperada por el proceso. La arqueología del software también puede ser un servicio proporcionado a los programadores por consultores externos.
Mitch Rosenberg de InfoVentions.net, Inc. afirma 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 razones posibles:
El corolario de esta "ley" es que hasta que no sepa cuál es el propósito del código, 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.
La profesión de programador-arqueólogo ocupa un lugar destacado en A Deepness in the Sky de Vernor Vinge .