# Archéologie logicielle

L'archéologie logicielle est l'étude d'implémentations de logiciels hérités mal documentés ou non documentés, dans le cadre de leur maintenance logicielle$^,$.
L'archéologie logicielle, nommée par analogie avec l'archéologie, comprend la rétro-ingénierie des modules logiciels et l'application de divers outils et processus permettant d'extraire et de comprendre la structure de programmes et de récupérer des informations de conception. L'archéologie logicielle peut révéler des processus d'équipe dysfonctionnels ayant produit des modules logiciels mal conçus, voire inutilisés. Le terme est utilisé depuis des années et reflète une métaphore assez naturelle : un développeur lisant un code ancien peut sentir qu'il ou elle est dans la même situation qu'un archéologue explorant les ruines d'une ancienne civilisation.

## Techniques

Un atelier sur l'archéologie logicielle à la conférence OOPSLA de 2001 (Programmation orientée objet, systèmes, langages et applications) a identifié les techniques d'archéologie logicielle suivantes, dont certaines sont spécifiques à la programmation orientée objet :
* Langages de script pour créer des rapports statiques et pour filtrer le rapport ressortant
* Documentation dans les pages HTML ou les wikis
* Analyse de signature synoptique, analyse statistique et outils de visualisation de logiciels
* Outils de rétro-ingénierie
* Suivi au niveau du système d'exploitation via truss ou strace
* Moteurs et outils de recherche pour rechercher des mots-clés dans les fichiers source
* Navigation dans les fichiers IDE
* Framework de tests unitaires tels que JUnit et CppUnit
* Génération de documentation API à l'aide d'outils tels que Javadoc et doxygen
* Débogueurs
Plus généralement, Andy Hunt et Dave Thomas notent l'importance du contrôle de version, de la gestion des dépendances, des outils d'indexation de texte tels que GLIMPSE et SWISH-E, et «[dessiner] une carte lorsque vous commencez à explorer».
Comme dans l'archéologie, l'archéologie logicielle implique un travail d'investigation pour comprendre les processus de pensée de ses prédécesseurs. Lors de l'atelier OOPSLA, Ward Cunningham a suggéré une technique d'analyse de signature synoptique qui a donné une «impression» générale pour un programme en ne montrant que la ponctuation, comme les points-virgules et les accolades. Dans la même logique, Cunningham a suggéré de visionner des programmes en police 2 afin de comprendre la structure globale. Une autre technique identifiée lors de l'atelier était l'utilisation d'outils de programmation orientés aspect tels qu'AspectJ pour introduire systématiquement du code de traçage sans modifier directement le programme existant.
Les techniques d'analyse de réseau et d'historiques des modifications peuvent révéler les modèles d'activité collaborative des développeurs de logiciels hérités, qui à leur tour peuvent mettre en lumière les forces et les faiblesses des artefacts logiciels produits.
Michael Rozlog d' Embarcadero Technologies a décrit l'archéologie logicielle comme un processus en six étapes qui permet aux programmeurs de répondre à des questions telles que « De quoi est-ce que je viens d'hériter ? » et « Où sont les sections effrayantes du code ? ». Ces étapes, similaires à celles identifiées par l'atelier OOPSLA, incluent l'utilisation de la visualisation pour obtenir une représentation visuelle de la conception du programme, l'utilisation de métriques logicielles pour rechercher les violations de conception et de style, l'utilisation de tests unitaires et de profilage pour rechercher les bogues et les goulots d'étranglement des performances, et rassembler les informations de conception récupérées par le processus. L'archéologie logicielle peut également être un service fourni aux programmeurs par des consultants externes.
Mitch Rosenberg de InfoVentions.net, Inc. revendique que la première loi de l'archéologie logicielle (il l'appelle l'archéologie de code ou de données) est : « Tout ce qui est là est là pour une raison, et il y a 3 raisons possibles :
* Cela avait besoin d'être là mais ce n'est plus le cas
* Cela n'a jamais eu besoin d'être là et la personne qui a écrit le code ne le savait pas
* Cela doit toujours être là et vous ne le savez pas ».
Le corollaire de cette « loi » est que, jusqu'à ce que vous sachiez quelle était la raison d'être du code, vous ne devez pas modifier le code (ou les données).
L'archéologie logicielle a continué d'être un sujet de discussion lors de conférences plus récentes sur le génie logiciel.
La profession de programmeur-archéologue figure en bonne place dans A Deepness in the Sky de Vernor Vinge.