Program arkæologi

Den aktuelle version af siden er endnu ikke blevet gennemgået af erfarne bidragydere og kan afvige væsentligt fra den version , der blev gennemgået den 2. oktober 2017; checks kræver 22 redigeringer .

Softwarearkæologi  er den disciplin, der studerer dårligt dokumenteret eller udokumenteret ældre software med det formål at vedligeholde den [1] [2] . Softwarearkæologi involverer reverse engineering af applikationer, brugen af ​​specielle værktøjer og arbejdsgange til at udtrække og forstå kodestrukturen og genskabe dens udvikleres hensigt [1] [3] . Softwarearkæologi hjælper med at afdække problemer forbundet med dårlig applikationsarkitektur og død (ubrugt) kode [4] . Udtrykket har været brugt i flere årtier [5] og afspejler følgende metafor: en udvikler, der læser koden for ældre software, føler det samme som en arkæolog, der udforsker monumenterne i en gammel civilisation [6] .

Værktøjer og teknikker

I 2001 på OOPSLA- konferencen definerede softwarearkæologisektionen følgende arkæologiske softwareværktøjer og -teknikker, hvoraf nogle vedrører objektorienteret programmering [6] :

For systematisk at spore funktionskald uden omfattende redigering af kodebasen for den applikation, der undersøges, kan aspektorienteret programmering (f.eks. AspectJ [6] for Java, MrAdvice for C # .NET) med succes bruges ved at udvikle aspektklasser at få information om tilstanden af ​​opkaldsstakken ved hjælp af refleksionsværktøjer, filtrering af de nødvendige oplysninger fra den og skrivning til logfilen eller vinduet i operationsprotokollen (den såkaldte log) for applikationen.

Når man vedligeholder et ekspertsystem, er en vigtig kilde til information om logikken i dets arbejde budskaberne fra undersystemet af forklaringer [7] .

Andy Hunt og Dave Thomas påpeger vigtigheden af ​​at bruge et versionskontrolsystem , en afhængighedsstyringscontainer, tekstindekseringsværktøjer (GLIMPSE, SWISH-E) og "[mapping] a study" [6] .

Ligesom ægte arkæologi involverer programarkæologi forskningsarbejde for at forstå forgængernes tankeprocesser [6] . Ved OOPSLA-sektionen foreslog Ward Cunningham den såkaldte "synoptiske signaturanalyse", som giver en første tilnærmelse af programmets "ånd" ved kun at vise udvikleren tegnsætningen af ​​koden (kolon, operatørparenteser ) [8] . Cunningham foreslog også at overveje programmer trykt i den mindst mulige skrifttype for at forstå programmets overordnede struktur [9] .

Netværks- og tidsanalyseteknikker, Git Archaeology -udvidelsen til Microsoft Visual Studio, kan hjælpe med at afdække ældre softwareudvikler-samarbejdsmønstre, som igen kan kaste lys over styrkerne og svaghederne ved den resulterende kode [10] .

Michael Rozlog fra Embarcadero Technologies beskrev softwarearkæologi som en seks-trins proces, der giver udviklere mulighed for at besvare spørgsmål som "Hvad har jeg arvet?" og "Hvor er denne kode forfærdelig?" [11] Disse trin, som dem, der blev opdaget af OOPSLA-sektionen, inklusive kodevisualisering for at forstå applikationsarkitektur, bruger softwaremetrik til at finde overtrædelser af designprincipper og programmeringsstil, enhedstest og profilering for at finde softwarefejl (såkaldte fejl) og flaskehalse steder i ydeevne, samt indsamling af information om strukturen af ​​applikationen, gendannet i processen med program-arkæologiske udgravninger [11] . Softwarearkæologi kan også være en service, der leveres til interne udviklere af eksterne konsulenter [12] .

Mitch Rosenberg (InfoVentions.net) udtaler, at "softwarearkæologiens første lov" er:

Det er her af en grund, og årsagen kan være en af ​​tre:

  1. Det skulle have været her, men det burde ikke være mere .
  2. Han behøvede ikke at være her, og programmøren, der skrev dette, vidste ikke, hvad han lavede .
  3. Det skal stadig være her, og det er dig , der ikke ved, hvad du laver .

Konsekvensen af ​​denne "lov": indtil årsagen er kendt, bør man ikke ændre koden (eller dataene) [13]

.

Se også

Noter

  1. ↑ 1 2 Gregorio Robles, Jesus M. Gonzalez-Barahona og Israel Herraiz, " An Empirical Approach to Software Archaeology Archived January 20, 2020 at the Wayback Machine ," Poster Proceedings of the International Conference on Software Maintenance , 2005.
  2. ↑ " Agile Legacy System Analysis and Integration Modeling Archived March 23, 2021 at the Wayback Machine " af Scott W. Ambler på agilemodeling.com, tilgået 20. august 2010: "Uden nøjagtig dokumentation eller adgang til kyndige mennesker kan din sidste udvej være at analysere kildekoden til det gamle system.
  3. ↑ Richard Hopkins og Kevin Jenkins, Eating the IT Elephant: Moving from greenfield development to brownfield Arkiveret 23. marts 2015 på Wayback Machine , Addison-Wesley, 2008, ISBN 0-13-713012-0 , s. 93.
  4. ↑ Diomidis Spinellis og Georgios Gousios, Smuk arkitektur arkiveret 22. marts 2015 på Wayback Machine , O'Reilly, 2009, ISBN 0-596-51798-X , s. 29.
  5. ↑ En tidlig diskussion er Judith E. Grass, " Object-Oriented Design Archaeology with CIA++ ", " Computing Systems " , Vol. 5, nr. 1, vinter 1992.
  6. ↑ 1 2 3 4 5 Andy Hunt og Dave Thomas, " Software Archaeology Archived November 9, 2020 at the Wayback Machine ", IEEE Software , vol. 19, nr. 2, s. 20-22, marts.
  7. ↑ Gavrilova T. A., Khoroshevsky V. F. Vidensbaser for intelligente systemer. - Sankt Petersborg. : Peter, 2000..
  8. ↑ Ward Cunningham , " Signature Survey: A Method for Browsing Unfamiliar Code Arkived 22 August 2010 at the Wayback Machine , "Workshop Position Statement, Software Archaeology: Understanding Large Systems, OOPSLA 2001.
  9. ↑ “ Software Archaeology Archived March 6, 2012 at the Wayback Machine ” på John D. Cooks blog The Endeavour , 10. november 2009.
  10. ↑ Cleidson de Souza, Jon Froehlich og Paul Dourish, "Seking the Source: Software Source Code as a Social and Technical Artifact Archived September 23, 2015 at the Wayback Machine ," Proceedings of the 2005 International ACM SIGGROUP Conference on Supporting Group Work, pp. 197-206.
  11. ↑ 1 2 Michael Rozlog, " Software Archaeology: What Is It and Why Should Java Developers Care? Arkiveret 13. juli 2015 på Wayback Machine ," artikel på java.sys-con.com, 28. januar 2008.
  12. ↑ Simon Sharwood, Raiders of the Lost Code arkiveret 14. marts 2012 på Wayback Machine , ZDNet 3. november 2004.
  13. ↑ For eksempel, den 32. ACM/IEEE International Conference on Software Engineering i Cape Town, Sydafrika i maj 2010