Archéologie logicielle - Software archaeology

L'archéologie logicielle ou l' archéologie logicielle est l'étude des implémentations logicielles héritées mal documentées ou non documentées , dans le cadre de la maintenance logicielle . L'archéologie logicielle, nommée par analogie avec l' archéologie , comprend l' ingénierie inverse de modules logiciels et l'application d'une variété d'outils et de processus pour extraire et comprendre la structure du programme et récupérer les informations de conception. L'archéologie logicielle peut révéler des processus d'équipe dysfonctionnels qui ont produit des modules logiciels mal conçus ou même inutilisés, et dans certains cas, un code délibérément obscurcissant peut être trouvé. Le terme est utilisé depuis des décennies et reflète une métaphore assez naturelle: un programmeur lisant du code hérité peut avoir le sentiment qu'il se trouve dans la même situation qu'un archéologue explorant les décombres d'une civilisation ancienne.

Technique

Un atelier sur l'archéologie logicielle lors de la conférence 2001 OOPSLA (Object-Oriented Programming, Systems, Languages ​​& 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 les résultats de diagnostic
  • Documentation continue dans les pages HTML ou Wikis
  • Analyse de signature synoptique, analyse statistique et outils de visualisation logicielle
  • Outils de rétro-ingénierie
  • Suivi au niveau du système d'exploitation via treillis ou strace
  • Moteurs de recherche et outils pour rechercher des mots-clés dans les fichiers sources
  • navigation dans les fichiers IDE
  • Frameworks 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 la véritable archéologie, l'archéologie logicielle implique un travail d'enquête 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 "sensation" globale pour un programme en ne montrant que la ponctuation, comme les points-virgules et les accolades . Dans la même veine, Cunningham a suggéré de visionner des programmes en police 2 points 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 éditer directement le programme hérité.

Les techniques d'analyse du réseau et du temps peuvent révéler les modèles d'activité de collaboration des développeurs de logiciels hérités, ce qui à son tour peut 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 "Qu'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 des bogues et des goulots d'étranglement de 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 d'InfoVentions.net, Inc. affirme que la première loi de l'archéologie logicielle (il l'appelle archéologie du code ou des données) est :

Tout ce qui est là est là pour une raison, et il y a 3 raisons possibles :

  1. Il avait besoin d'être là, mais ce n'est plus le cas
  2. Il n'a jamais eu besoin d'être là et la personne qui a écrit le code n'avait aucune idée
  3. Il doit TOUJOURS être là et VOUS n'en avez aucune idée

Le corollaire de cette "loi" est que, jusqu'à ce que vous sachiez quelle en était la raison, vous ne devriez 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 occupe une place importante dans Vernor Vinge de A Deepness dans le ciel .

Voir également

Les références

Liens externes