Ah, det evige spørsmålet i utviklerverdenen: når kan man skrote den irriterende drittkoden man arbeider på, så man kan skrive noe nytt?
Og samtidig få det akkurat slik man vil ha det selv.
Så er rutinen at man lar det gå 3-4 år før en ny ansatt arver koden din og tenker det samme om det du skrev. Ikke sant?
Kanskje det ikke er akkurat så enkelt? Vi spurte kode24-klubben om de kunne hjelpe oss å definere når kode faktisk er moden for utskifting, eller når den er "legacy" som vi ofte kaller det i bransjen. Slik at vi alle vet når vi skal gå til teamlederen vår og kreve omstart.
#1. Kode som ikke er testbar
Dette argumentet hører man ganske ofte i utviklerbransjen. For mange er kode som ikke har skrevne tester eller kan testes på andre måter ubrukelig. Og det kan vi forstå.
Hvordan kan man stole på at koden fungerer hvis man ikke kan verifisere at den fungerer i alle scenarioer man trenger?
- Kort og godt så liker jeg definisjonen i denne boka: Working Effectively with Legacy Code. Legacy-kode er kode som ikke er testbar. Det har en mer praktisk tilnærming enn en del andre definisjoner, skriver Kristian Hasli Johnsen.
#2. Kode man er redd for å endre
Vi har alle vært der.
Av og til får man utdelt kode som snirkler og vrir seg gjennom millioner av filer, som en slyngplante på en gammel britisk herregård. Med avhengigheter på kryss og tvers og globale variabler som av uante grunner benyttes dypt nede i en funksjon med et kryptisk firebokstavs-navn.
Den koden er det best å la være.
- Jeg er nok litt mer på Eli Lopian sin "code that developers are afraid to change’", enn Michael Feathers sin "code without tests". Kanskje burde disse to kategoriene vært sammenfallende, men har sett alt for mye kode med tester som jeg fortsatt er redd for å røre, forteller Vegar Vikan.
#3. Gammalt språk, gammal teknologi
Ting skjer fort i kodebransjen. For knappe ti år siden var det helt gangbart å ha svære kronglete PHP-kodebaser med noen avsidesliggende Pearl-script og en gigantisk frontend basert på jQuery UI.
Men så kom Angular, og så kom React, og Go og Node. Nye språk som endrer kode-paradigmene, og vips så virker den gamle koden nesten uleselig.
Når det virker som om hver eneste kodelinje er basert på et dårlig gammelt valg. Da er det kanskje på tide å bytte den ut?
- Kode skrevet for en plattform eller et språk man ikke bruker lenger, eller som ikke følger kodestandarden man har kommet frem til. Kort sagt: Ting som har nådd pensjonsalder, men som fremdeles lever i produksjon, skriver Paul A. Stølen.
- Kode som binder en fast til gammel teknologi. Henger sammen med de foregående da dette ofte er kode man er redd for å endre og at det. Hadde koden vært enhets testbane så hadde den ikke vært knyttet så sterkt til gammel tech, tilføyer Arnt Emmanuel Berge.
#4. kode du har lyst til å skrive på nytt
Dette punktet gjelder all kode, amirite? 😉
Det er veldig lett å tenke at all kode man ikke liker selv bør kunne defineres som legacy. Da har man jo en enkel billett til å få skrive om slik man vil.
- Å kalle noe for legacy code er veldig strategisk hvis man har lyst å skrive noe på nytt. Eller benytte et nytt språk eller rammeverk. Det er et uttrykk som er veldig løst definert og er veldig lett å misbruke, skriver Eirik Stenestø Tenold.
- For min del har det flere ganger vist seg enklere å lage et "nytt" prosjekt basert på ny teknologi og heller inkludere logikken og dataflytene fra det gamle prosjektet, heller enn å starte med det gamle prosjektet og forsøke å skrive skallet om til noe nytt. Men begge deler kan gå. Det kommer også litt an på hvor store endringene er fra gammel versjon til ny, forteller David Oftedal.
#5. kode som er i limbo
Limbo-legacy er den verste typen legacy kode.
Vi snakker kode som er så omfattende og forferdelig at ingen vil ta i den, samtidig som den kjører og fungerer strålende i produksjon. Da blir den fort for kostbar til å skrive om, og for kjip til å jobbe på, og blir sittende fast i en limbo-tilstand.
- Legacy-kode er kode som er for kostbar til å effektivt videreutvikle og for verdifull til å kaste. Den mest passende oversettelsen jeg klarer av legacykode er forøvrig "nedarvet kode" eller kanskje "arvekode". - Johannes Brodwall
- legacy kode er koden som overlevde. Den som gir så mye verdi, at den ikke kan kastes, selv om man vil.Vi i NAV får jevnlig ekstraordinære bevilgninger i milliard klasses for å gjøre noe med legacy koden vår, forteller Audun Fauchald Strand.
Bør vi bruke legacy-begrepet?
Med så mange meninger om hva som er legacy-kode, bør vi heller prøve å tenke nytt om gammel kode?
Flere utviklere tar til orde for at begrepet er utdatert og kanskje polariserer mer enn det løser. For det er jo klart at vi åpner dørene for en veldig subjektiv oppfattelse av hva som er utdatert kode.
- Om noe, så er all kode en form for legacy i det øyeblikket den skrevet og i dette øyeblikket eksisterer. Og det er en klassifikasjon som ikke gir noen som helst verdi for det er da bare 1:1 med "eksisterende kode", skriver Michael Odden.
Og slår samtidig spikeren på hodet. Hvem har vel ikke sett på kode man skrev selv for en måned siden og tenkt: "hva er dette for noe møl?".
Kan det være at all og ingen kode egentlig er legacy? Kan det være at vi utviklere kanskje ikke er i stand til å gjøre en skikkelig vurdering av legacy-kode?
Noen utviklere mener det.
- Hele denne tråden viser jo at det best å overlate definisjonen til hva legacy-kode er til ikke-utvikiklere, skriver Christer Sarkasmus Solskogen med et 😉.