”Det viktigaste är att koden kommunicerar bra. Om den inte gör det har man inte gjort ett särskilt bra jobb”. Något i den stilen kläckte jag ur mig under mitt utvecklingssamtal som jag hade under förra veckan. Man kan med all rätt tycka att uttalandet inte var särskilt sensationellt eftersom hela grejen med högnivåspråk är att koden ska vara lätt för människor att förstå. Det skrivs hela kapitel i facklitteratur om hur vi bör benämna och strukturera saker och ting för att göra kodbasen begriplig. Vi har begåvats med en rejäl hög design patterns – ett slags blue print över hur man kan lösa problem – som bidrar med en rik begreppsvärld som kan användas i våra lösningar. Ändå stöter jag gång på gång på kod som kommunicerar riktigt, riktigt dåligt.

Oavsett om det är någon annan eller jag själv som har haft en dålig dag på jobbet är det solklart att det tåls att upprepas – det viktigaste uppdraget vi som utvecklare har är att skriva kod som kommunicerar bra. Man kan då fråga sig varför det ser ut som det gör därute. Som ni säkert förstår har jag en teori och för att förmedla den ska jag damma av en gammal klassisk jämförelse.

Många tycker att programmering ska ses som ett hantverk. Här använder hantverkaren (det vill säga programmeraren) sina verktyg (främst sitt IDE) till att förändra befintlig eller lägga till ny funktionalitet i det system han eller hon bearbetar. I denna analogi kan man se kod som hantverkarens material, en formbar massa vars skepnad i högsta grad påverkas av personen bakom tangenterna. Denna massa ska formas så att den både a) kan tolkas maskinellt på korrekt sätt och b) bli enkel och tydlig för andra hantverkare att förstå.

Det grundläggande problemet är att det bara är a som behövs för att systemet ska fungera, och på kort sikt levererar man faktiskt det man ska även om man fullkomligt skiter i b. Man bör skämmas i sin roll som hantverkare men så länge som man har gjort a är funktionaliteten ändå på plats. Den verkliga konsekvensen av ett risigt hantverk ser man först på lite längre sikt – förr eller senare ska någon stackare ge sig in i just den sektionen av kodbasen och försöka förstå vad som faktiskt händer. Då kan enkla ändringar som borde ta några timmar att genomföra förvandlas till flera dagars arbete. Att gräva i en stadig balja med spagettikod är dessutom stressigt och ganska arbetsamt. Det händer att befintlig kod är så pass komplex att det helt enkelt inte går att förutse alla konsekvenser av de ändringar man gör. Och då är man inte så tuff.

Min teori är alltså följande: så länge det går att komma undan med snabba ”fullösningar” kommer vi inte att bli av med dem. Detta är förmodligen sant oavsett om det handlar om snickeri eller programmering. Men nu ska vi inte deppa ihop, vi kan i vilket fall arbeta aktivt och medvetet för att minimera  eländet. Med verktyg som till exempel parprogrammering och code review kan vi lära av och pusha varandra till att forma kodmassan till något fint. Och som mantra borde vi ha att koden ska kommunicera bra.