|
Archéologie logicielleL'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[1],[2]. L'archéologie logicielle, nommée par analogie avec l'archéologie[3], 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[4]. L'archéologie logicielle peut révéler des processus d'équipe dysfonctionnels ayant produit des modules logiciels mal conçus, voire inutilisés[5]. Le terme est utilisé depuis des années[6] 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[7]. TechniquesUn 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[8] :
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»[8]. 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[8]. 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[9]. Dans la même logique, Cunningham a suggéré de visionner des programmes en police 2 afin de comprendre la structure globale[10]. 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[11]. 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 ? »[12]. 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[13]. Mitch Rosenberg de InfoVentions.net, Inc. revendique [réf. nécessaire] 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 :
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[14]. La profession de programmeur-archéologue figure en bonne place dans A Deepness in the Sky de Vernor Vinge[15]. Voir aussiNotes et références
Liens externes
|
