Frukostseminariet den 19/5 handlade om Legacy Code och den tudelade relationen vi har till det. På seminariet diskuterade vi utifrån tre frågeställningar:
- Vad menar vi med "Legacy Code"? När känner vi att det begreppet är lämpligt, och varför känner vi så? Varför behöver vi begreppet?
- Vad är det första vi gör när vi stöter på "Legacy Code"? Finns det olika angreppssätt eller tänkemodeller man kan använda för att "attackera" ärvd kod?
- Tekniker, böcker och andra resurser vi kan använda för att lära oss av andra
Här är bilder på anteckningarna vi gjorde på tavlan:
Sammanfattningsvis:
- "Legacy Code" är kod vi ärvt från andra eller oss själva, och som vi är inte trygga med att ändra i
- Det gäller att först försöka förstå och det finns många tips på hur man gör det, några startpunkter kan vara
- scratch-refactorering
- namnändringar
- tester
- ev. dokumentation
- Sen kanske man bara behöver ändra lite i den koden för att nästa person skall få lättare att förstå och sedan gå vidare med sitt egentliga ärende
- Några böcker bör man läsa ("Working Effectively with Legacy Code", "Refactoring", "Clean Code", "Beyond Legacy Code", ...)
- Återkoppling är viktigt för att veta om man har sönder något och återkopplingen behöver inte vara enhetstester (funktionstest, loggar, approval testing, ...)
Viktigaste insikten kanske är att det är värdefull kod som överlever och det är tryggheten att förstå och ändra som är målet.
Ett tilläggs-tips som jag vill ge nu är att Legacy Code är inte bara värdefull kod, den har dessutom ofta gett rätt resultat i många år per definition, inklusive de egenheter den har, så till och med s.k. bugg-kompatibilitet är viktigt att bevara när vi arbetar i ärvd kod. Det är ytterligare ett argument varför omskrivning ofta är en sämre idé än vi vill tro.
