Konsten att vara en pragmatisk programmerare

Under hösten och vintern anordnade vi på Dynabyte en bokcirkel där vi läste den gamla klassikern The Pragmatic Programmer.

Boken presenterar en mängd handfasta tips man kan använda inom programmering och teamarbete. Den är inte bunden till något specifikt programmeringsspråk, utan behandlar allmänt tillämpningsbara metodiker på hur vanliga problem kan förebyggas och hur arbetsflöden kan förbättras.

Vi träffades tre gånger och inför varje möte hade deltagarna förberett diskussionsfrågor från kapitlen vi läst. Då deltagarna var av olika teknisk bakgrund blommade de flesta ämnena ut i fruktsamma diskussioner:

## Don’t Live with Broken Windows
Ett exempel som boken ger är ett hyreshus som ursprungligen är vid gott skick, med undantag från en enda trasig fönsterruta. Om det dröjer innan fönsterrutan lagas så skapar det till slut en uppfattning bland förbipasserande att det inte är så höga krav på kvaliteten i hyreshuset. Något mer går sönder och lagas inte heller. Sedan eskalerar det och resulterar i att resten av hyreshuset förfaller mer och mer. Samma princip kan ses inom systemutveckling, exempelvis kodformattering. Om inte även de små detaljerna görs rätt så kan det påverka teamets allmänna ambitionsnivå när det kommer till att skriva snygg kod, vilket i längden kan få större konsekvenser när det kommer till exempelvis hur mycket man bemödar sig att tänka igenom valet av en viss arkitektur.

## Tracer Bullets vs. prototyper
Tracer bullets är tidiga implementationer av ett system, vars syfte är att testa de kritiska aspekternas funktionalitet. Resten av systemet kan sedan inkrementellt byggas runt denna grundläggande funktionalitet. Prototyper, å andra sidan, har till syfte att bygga en grundläggande kunskap, men har som mål att de efteråt ska kasseras. Detta då den kunskap man fått med sig i största sannolikhet kommer att resultera i ett bättre system om man börjar om från grunden. Ofta behöver man på förhand vara tydligt med att det man visar upp egentligen är en prototyp som ska kasseras för att stå till grund till något bättre, för att alls ha möjlighet till detta.

## DRY
Principen DRY (Don’t Repeat Yourself) beskrivs flitigt i boken och är något som är viktigt inom all systemutveckling. Om det eftersträvas att inte ha några upprepningar och att ha varje implementation på endast ett ställe så minskar både underhållskostnaderna, svårigheten att sätta sig in i koden och risken för buggar. I de fall där det visar sig vara svårt att inte duplicera kod så kan det vara tecken på ett strukturellt problem som isåfall förhoppningsvis kan lösas med en modifierad arkitektur.

## Den pragmatiska programmeraren
Vad definierar då en pragmatisk programmerare? Som pragmatisk programmerare granskar man kontinuerligt effektiviteten i ens arbetsmetoder. Finns det utrymme för att snabba upp ens arbete, exempelvis genom script, makron eller byte av IDE? Finns det tydliga rutiner i teamet som minskar risken för förvirring? Har allt som kan göras för att förebygga uppkomsten av buggar gjorts, tillämpas DRY? Fungerar versionshanteringen och testningen på ett tillfredsställande sätt? Förbättringsmöjligheterna är naturligtvis individuella och skiljer sig mellan olika projekt.

*Att vara en pragmatisk programmerare handlar om inställning. Att systemutveckling är ett hantverk som uppnår hög kvalitet genom omsorgsfullt förbättringsarbete, såväl vid själva implementationen i sig som vid det omkringliggande arbetet.*