NYHET Ett problem varje mjukvaruutvecklare brottas med är att systemens grundämne, koden, försämras och ruttnar med tiden. Utvecklaren Erik Schlyter efterlyser mer hantverkarattityd och färre påhittiga MacGyver-lösningar.
Erik Schlyter, före detta student vid datavetenskapen på Umeå universitet, har studerat problematiken med dålig kod på heltid och föreläste i fredags på Dohi Sweden, där han gav handfasta tips på hur man håller koden fräsch.
Erik Schlyter kommer ursprungligen från västra Värmland och gjorde sitt första hundramilakliv till Umeå universitet 2003, för att läsa datavetenskap. Efter examen tog han nästa jättekliv, ner till Linköping för en anställning på datakonsultbolaget ENEA.
Via ENEA fick Erik bra kontakt med en av bolagets kunder Opera Software – som står bakom webbläsaren Opera – och efter tre månader i en kund/konsult-relation flyttade Erik över till Opera för att utveckla för dem på heltid.
– Under den här tiden blev jag allt mer nyfiken på kod ur ett långsiktigt perspektiv. Hur kod utvecklad av oerhört smarta människor ändå tenderar att bli komplex att underhålla med tiden, samt hur större delen av mjukvaruindustrin verkar förbise problemet.
Intresset blev nästan en fixering och Erik tog till slut tjänstledigt för att fördjupa sig i detta, och liknande problem inom branschen.
– Jag lärde mig mycket under den perioden. Framförallt vikten av att distansera sig från det kommersiella en stund för att få lite perspektiv, men också hur viktigt det är att stanna upp och ge sig själv ett andningshål ibland – en chans att ta reda på om man själv är där man vill vara, och på väg åt rätt håll.
I Eriks fall ledde pausen till att han sade upp sig på Opera och bestämde sig för att starta eget. ”Tanken är väl att jag ska befria världen från ful kod”, säger Erik som sedan oktober i år jobbar som konsult inom området.
– Jag ser mig som en resurs för företag, och då inte som en föreläsare som gör korta inhopp. Jag vill sitta en längre period på plats hos företagen – i kanske i ett par månader – så att jag verkligen kan få rätsida på problemen, och under den tiden uppmuntra utvecklarna att arbeta långsiktigt för att undvika att koden ruttnar igen.
Vilka är då de viktigaste anledningarna till varför koden blir dålig?
– Ett av grundproblemen är att förutsättningarna alltid förändras, och att strukturen man utgick från inte längre är aktuell efter några år. Eftersom det i större kodbaser alltid är enklare att lägga till kod
istället för att korrigera den befintliga arkitekturen, så leder det sakta men säkert till ett allt krångligare och mer känsligt system.
Snabba lösningar, till exempel inför en deadline, bidrar givetvis också. Det leder till halvfärdiga lösningar utvecklarna lovar sig själva att ordna till i efterhand – någonting som ofta har en tendens att inte bli av. Trots sanningen Erik tar upp, att: ”det alltid är mycket dyrare att lösa någonting i morgon jämfört med att ta tag i det idag.”
– Lägg därtill personalomsättning som är oundviklig, då tappar bolagen all kunskap om koden som inte finns inskriven i den. Därför är det viktigt att koden är läsbar och att den innehåller rätt information.
Erik rekommenderar att man kommunicerar genom testfall och tydlig kod istället för efterkonstruerad dokumentation, samt att man värdesätter kodens läsbarhet snarare än fiffighet.
– Vad branschen och företagen behöver är färre påhittiga MacGyver-lösningar och mer hantverkarattityd.
Redaktör: Mikael Hansson