Av : pontus.bergoo | 2013-08-21 07:38

Det börjar som en intuition nere från magtrakten, någonting som gnager och inte känns bra. De visste inte hur rätt de hade, Martin Fowler och Kent Beck, som myntade uttrycket code smell, eller så var det just precis det de visste.

Nåväl, jag har identifierat något ställe i koden som gnager och luktar och börjar refaktorera. Ibland är refaktoreringen enkel och snabb att åtgärda, ibland finns det så många nästlade beroenden så att jag inte på något enkelt sätt kan refaktorera. Det finns en refaktoreringsmetod som heter Mikado som jag har börjat använda som är ett strukturerat sätt att nysta upp och refakorera kod med snåriga beroenden. Om min uppdragsgivare låter mig hållas och fortsätta att följa min intuition så börjar det hända saker. För mig är refaktoreringen ett sätt att lära känna mjukvaran och göra den till min. Och till slut så börjar mjukvaran tala. Det är en djupt kreativ process som är väldigt tillfredsställande och personlig.

I ett tidigare liv studerade jag filmvetenskap och skrev en uppsats om filmen Metropolis och då hände samma sak. Det kan också hända när jag studerar in ett musikstycke med min kör, Boo Cantabile. Noterna på pappret börjar tala eller snarare sjunga. När jag lägger pussel händer samma sak. I början är allt kaos. Efter hand så kan man börja se mönster och sortera bitarna efter något system. Sedan ser man underavdelningar och vid en viss punkt börjar pusslet tala och lägger sig i stort sätt själv. Programmering är ett hantverk mer än något annat.

Tyvärr finns det bland uppdragsgivare, projektledare och produktägare sällan förståelse för den här kreativa processen. Det är sådant fokus på att prestera funktionalitet till nästa sprint eller deadline på ett kortsiktigt sätt. Då är det väldigt svårt att undvika att bygga upp teknisk skuld. Jakten på säljbar funktionalitet är mjukvaruutvecklingens svar på kvartalskapitalism. Jag har varit och är en stark förespråkare för agil utveckling men ser också risken för kortsiktighet. Hur kan det komma sig och hur kan man bemöta det då?

Ibland är ett utvecklingsteam hårt pressat av deadlines och kan inte samla kraft för att göra några djupdykningar i koden, utan tvingas att fortsätta att bygga upp en teknisk skuld. Jag vet vad som borde göras – det skulle gagna uppdragsgivaren på lite längre sikt – men jag kan inte göra något åt det. Det är som när man är stressad och tvingas att bröstandas istället för att andas med magen – en andning som är bättre förutom i extrema nödsituationer.

Ofta kommer pressen från utvecklarna själva så som Henrik Kniberg så träffande uttrycker. Vi är ett otåligt släkte och ofta är pressen ett hjärnspöke. Men ibland beror oförståelsen helt enkelt på bristande kompetens hos de som bestämmer. De vet inte vad som skiljer bra från dålig mjukvara och har inte klart för sig vad teknisk skuld innebär. Det krävs skickliga programmerare till det som dessutom kan sprida sina insikter till hela teamet. En bra ledare har antingen denna kunskap eller har tillräcklig tillit till utvecklarna i teamet och låter dem hållas. Vid de tillfällen som jag har sett riktigt bra mjukvara skapas, eller har skapat den själv, så har det tyvärr ofta skett tack vare att någon genial programmerare ”flyger under radarn” och programmerar i smyg utan ledningens vetskap. Varför är det så? Det är något som i bästa fall uppskattas i efterhand men sällan belönas medan det sker.

Och det här är en av de verkligt stora riskerna med agil utveckling. Det är lätt att suboptimera. Eller är det så att det är något som drabbar omogna organisationer? Agil utveckling är ju ett i många stycken kraftfullt verktyg som kanske alltför många anammar okritiskt, vilket gör att de kastar ut barnet med badvattnet.

2 kommentarer to “När mjukvaran börjar tala”

  1. Jonny Andersson skriver:

    Jag råkade hitta den här artikeln när jag googlade lite på Java och kvalitet och du har några intressanta poänger i det du säger och som jag själv också har insett i mitt jobb som Javautvecklare. T.ex. det om att använda sig av refactoring som ett sätt att lära sig kod. Jag vet inget bättre sätt att lära sig ny kod än att städa iden med små refactorings allt eftersom jag förstår mer och mer av vad den gör och oftast har jag minskat mängden kod rejält också när jag känner mig klar utan att jag ändrat på vad den gör. Sånt kan ha en dramatisk effekt på kodkvaliteten på djupet. Tyvärr upplever jag dock precis som du också säger att kompetensen hos de som bestämmer är bristfällig. Speciellt upplever jag att många har en bristande förståelse för vad kvalitet är. För många betyder det hög testtäckning men det kan ju t.o.m. vara ett kontraproduktivt mått ibland! Men kompetensen är för låg hos utvecklarna också. Det objektorienterade paradigmet är väldigt annorlunda än procedurorienterat eller sekventiellt programflöde och tyvärr ser jag ofta kod där det är tydligt att den har skrivits med ett sekventiellt tänkesätt. Det brukar inte bli så bra. Att bli en bra hantverkare, craftsman som det heter i utvecklarvärlden, kräver väldigt mycket lärande och jag brukar säga då och då att våra kunder borde börja kräva en rabatt på t.ex. 30% för de Javautvecklare som inte är certifierade. Certifieringarna är förstås ett trubbigt mått men det skulle åtminstone öka incitamentet till lärande rejält bland utvecklare och deras arbetsgivare och det är inte ovanligt att man ser kod där det framgår att utvecklaren har haft bristande kunskaper om syntaxen också. Det behövs i varje fall många fler som predikar vikten av verklig kvalitet i programutveckling och därför är det bra att det finns såna här artiklar som syns när man googlar efter kvalitet.

  2. pontus.bergoo skriver:

    Tack för ditt inlägg Jonny. Michael Feathers skriver om en teknik som kallas för ”scratch refactoring” som går ut på att man refaktorerar kod enbart med syftet att lära sig. Eftersom det nästan alltid är riskabelt att refaktorera så backar man dom ändringarna för att inte tvingas ta så många hänsyn. Det är en viktig komponent i mikadometoden.
    Du noterar helt riktigt att många utvecklare inte har följt med i paradigmskiftet från procedurell till objektorienterad programmering (vilket skedde för decennier sedan). Och hur svårt är det inte då att hänga med i det nygamla paradigmskiftet vi upplever just nu, den funktionella programmeringen.

Lämna en kommentar

*
css.php