Der Quellcode ist das Herzstück einer Software. Ob das Programm in ge­wünsch­ter Weise funk­tio­niert und welche Funk­tio­nen möglich sind, hängt von den An­wei­sun­gen und Befehlen ab, die in diesem Code ver­zeich­net sind. Pro­gram­mie­rer be­ar­bei­ten, warten und pflegen diesen Code re­gel­mä­ßig, um Nutzern die best­mög­li­che Usability zu bieten. Jede Ver­än­de­rung am Code kann mitunter Software-Fehler nach sich ziehen oder die Lauf­fä­hig­keit des Programms gefährden.

Für Ent­wick­ler und Pro­gram­mie­rer sind die Wartung und das Updaten von Software immer dann besonders pro­ble­ma­tisch, wenn sie mit Codes arbeiten müssen, die sie nicht selbst ge­schrie­ben haben oder die für ältere, nicht länger un­ter­stütz­te Be­triebs­sys­te­me in ebenso alten Versionen der zu­grun­de­lie­gen­den Pro­gram­mier­spra­che ge­schrie­ben wurden. Was genau hinter solchem Legacy Code steckt und wie am besten damit umzugehen ist, erfahren Sie hier.

De­fi­ni­ti­on von Legacy Code

Der Begriff „Legacy Code“ wird in der Software-Technik verwendet und bedeutet übersetzt so viel wie „Altcode“. Dabei handelt es sich um älteren Code, der in der Regel nicht mehr aktiv wei­ter­ent­wi­ckelt wird. Legacy Code ist in gewisser Weise das Ge­gen­stück zum „Clean Code“, der intuitiv ver­ständ­lich, besonders war­tungs­freund­lich und leicht anpassbar ist. Legacy Code ist sperriger, über­hol­ter und un­auf­ge­räum­ter Code, der zu zahl­rei­chen Problemen führen kann. Was genau der Begriff meint, hängt stark von der Sicht des Ent­wick­lers und der je­wei­li­gen Situation ab. Prin­zi­pi­ell zeichnet sich Legacy Code aber durch folgende Aspekte aus:

  • Der Code wird nicht mehr vom ur­sprüng­li­chen Ent­wick­ler in­stand­ge­hal­ten.
  • Der Code wurde ur­sprüng­lich für nicht mehr un­ter­stütz­te Be­triebs­sys­te­me ge­schrie­ben.
  • Der Code lässt sich nicht au­to­ma­ti­siert auf Bugs testen.

Was sind die Nachteile von Legacy Code?

Warum wird Legacy Code überhaupt verwendet, wenn er doch eine ganze Reihe von Nach­tei­len mit sich bringt? Ganz einfach aus dem Grund, dass er sich nicht immer vermeiden lässt: Es kommt häufig vor, dass im Laufe eines Projekts ein neuer Pro­gram­mie­rer die In­stand­hal­tung und Wei­ter­ent­wick­lung des Codes übernimmt. Während der ur­sprüng­li­che Ent­wick­ler den Code wohl in den meisten Fällen intuitiv ver­stan­den hat, müssen sich neue Team-Mit­glie­der dieses Ver­ständ­nis erst er­ar­bei­ten. Dabei kann es vorkommen, dass Teile des Codes über­gan­gen werden oder nicht komplett ver­stan­den werden.

Wenn ein Code über viele Jahre von vielen ver­schie­de­nen Pro­gram­mie­rern gepflegt, ver­bes­sert und an­der­wei­tig be­ar­bei­tet wird, kann aus dem Code im Laufe der Zeit ein Fli­cken­tep­pich werden, der immer schwerer zu verstehen und zu verändern ist. Das Problem dabei: Ab einem gewissen Punkt können nötige Ak­tua­li­sie­run­gen oder Ver­än­de­run­gen nicht durch­ge­führt werden, wenn der Code und seine Aus­wir­kung von niemanden mehr ver­stan­den werden.

Ein weiterer Nachteil von Legacy Code: Re­gres­si­ons­tests, also au­to­ma­ti­sier­te Tests, lassen sich aufgrund der zu sperrigen, un­hand­li­chen und fli­cken­haf­ten Pro­gram­mie­rung nicht durch­füh­ren. Ent­wick­ler, die es mit Altcode zu tun bekommen, haben also einen we­sent­lich höheren manuellen Prü­fungs­auf­wand. Fehler sind schwie­ri­ger zu beheben, Updates kom­pli­zier­ter um­zu­set­zen.

Re­fac­to­ring: Die passende Antwort auf Legacy Code

Legacy Code ist etwas, mit dem sich Ent­wick­ler aus ver­schie­de­nen Gründen nur ungern be­schäf­ti­gen. Eines der größten Probleme ist dabei der Fakt, dass sich der Code nicht au­to­ma­ti­siert auf Bugs bzw. Fehler testen lässt. Was können Ent­wick­ler also tun, wenn sie im Zuge eines neuen Projekts plötzlich mit Legacy Code kon­fron­tiert sind?

Die wohl beste Antwort lautet: Re­fac­to­ring (dt. „Re­struk­tu­rie­rung“). Bei diesem Ent­wick­lungs­an­satz wird Code neu struk­tu­riert, ohne seine ur­sprüng­li­che Funktion zu verändern. Bevor aber die tat­säch­li­che Re­struk­tu­rie­rung passiert, müssen Pro­gram­mie­rer erst ver­stan­den haben, wofür die einzelnen Code-Be­stand­tei­le ver­ant­wort­lich sind. Außerdem müssen sämtliche Funk­tio­nen durch Tests ab­ge­si­chert werden.

Erst wenn klar ist, wie der Code funk­tio­niert, geht es an das tat­säch­li­che Re­fac­to­ring. Dabei wird der Code Stück für Stück optimiert. Über­flüs­si­ge Co­die­run­gen werden entfernt oder um­ge­schrie­ben, Code-Klassen und Variablen ver­ein­facht und zu­sam­men­ge­führt, Be­fehls­me­tho­den angepasst und um­ge­schrie­ben. Letztlich kommt das Re­fac­to­ring einer Ge­ne­ral­über­ho­lung des Legacy Codes gleich. Im Ergebnis steht ein Code, der leichter zu verstehen, einfacher zu pflegen und schneller an­zu­pas­sen ist.

Zum Hauptmenü