A szoftverrégészet az a diszciplína, amely a rosszul dokumentált vagy nem dokumentált örökölt szoftvereket tanulmányozza karbantartása céljából [1] [2] . A szoftverrégészet magában foglalja az alkalmazások visszafejtését , speciális eszközök és munkafolyamatok használatát a kód szerkezetének kinyerésére és megértésére, valamint a fejlesztői szándék visszaállítására [1] [3] . A szoftverarcheológia segít feltárni a rossz alkalmazásarchitektúrával és a halott (nem használt) kóddal kapcsolatos problémákat [4] . A kifejezést több évtizede használják [5] , és a következő metaforát tükrözi: a régebbi szoftverek kódját olvasó fejlesztő ugyanúgy érzi magát, mint egy régész, aki egy ősi civilizáció műemlékeit kutatja [6] .
2001-ben az OOPSLA konferencián a szoftverrégészeti szekció a következő szoftverrégészeti eszközöket és technikákat határozta meg, amelyek közül néhány az objektum-orientált programozáshoz kapcsolódik [6] :
A függvényhívások szisztematikus nyomon követése érdekében a vizsgált alkalmazás kódbázisának kiterjedt szerkesztése nélkül, a szempont-orientált programozás (például AspectJ [6] Java-hoz, MrAdvice C # .NET-hez) sikeresen használható szempontosztályok fejlesztésével. a hívásverem állapotáról reflektáló eszközökkel információt szerezni, kiszűrve belőle a szükséges információkat és beírva az alkalmazás naplófájljába vagy a műveleti protokoll ablakába (ún. log).
Egy szakértői rendszer fenntartása során fontos információforrást jelentenek a munka logikájával kapcsolatban a magyarázatok alrendszerének üzenetei [7] .
Andy Hunt és Dave Thomas rámutat a verziókezelő rendszer , a függőségkezelő tároló, a szöveges indexelő eszközök (GLIMPSE, SWISH-E) és a „tanulmány leképezése” [6] használatának fontosságára .
A valódi régészethez hasonlóan a programrégészet is kutatási munkát foglal magában, hogy megértsék az elődök gondolkodási folyamatait [6] . Az OOPSLA szekciónál Ward Cunningham az úgynevezett "szinoptikus aláírás-elemzést" javasolta, amely a program szellemének első közelítését adja azáltal, hogy a fejlesztőnek csak a kód írásjeleit (kettőspontok, operátori zárójelek ) mutatja [8]. . Cunningham azt is javasolta, hogy fontolja meg a lehető legkisebb betűtípussal nyomtatott programokat, hogy megértse a program általános szerkezetét [9] .
A hálózati és időbeli elemzési technikák, a Microsoft Visual Studio Git Archaeology bővítménye segíthet feltárni az örökölt szoftverfejlesztői együttműködési mintákat, amelyek viszont rávilágíthatnak az eredményül kapott kód erősségeire és gyengeségeire [10] .
Michael Rozlog, az Embarcadero Technologies munkatársa úgy írta le a szoftverrégészetet, mint egy hat lépésből álló folyamatot, amely lehetővé teszi a fejlesztők számára, hogy válaszoljanak olyan kérdésekre, mint például: "Mit örököltem?" és "Hol szörnyű ez a kód?" [11] Ezek a lépések, az OOPSLA szakasz által felfedezettekhez hasonlóan, beleértve az alkalmazásarchitektúra megértését célzó kódvizualizációt, szoftvermetrikákat használnak a tervezési elvek és a programozási stílus megsértésének felderítésére, az egységtesztelést és a profilalkotást a szoftverhibák (úgynevezett hibák) feltárására , és szűk keresztmetszetek .helyek a teljesítményben, valamint a program-régészeti feltárások során helyreállított információgyűjtés az alkalmazás szerkezetéről [11] . A szoftverrégészet külső tanácsadók által belső fejlesztők számára nyújtott szolgáltatás is lehet [12] .
Mitch Rosenberg (InfoVentions.net) kijelenti, hogy a "szoftverrégészet első törvénye" a következő:
Oka van itt, és az ok lehet a három közül:
Ennek a "törvénynek" a következménye: amíg az ok nem ismert, nem szabad megváltoztatni a kódot (vagy adatot) [13]
.