Utvecklare med passion för bokstavssoppa?

Är du ett fan av förkortningar och nya metoder och principer? Eller tycker du att det blir lite väl mycket bokstavssoppa ibland?

Det fanns en tid när programmering var enkelt: det var bara att skriva kod. Men nu finns det fler metoder och principer än det finns utvecklare. Så, frågan är om vi som jobbar med utveckling ens har koll på alla? Vet du till exempel vad följande begrepp innebär? Och om du hört om dem – förstår du dem? Har du rentav använt dem i produktion?

• OOP (Object Oriented Programming)
• Procedural
• Functional
• TDD (Test Driven Development) 
• DDD (Domain Driven Design) 
• BDD (Behavioural Driven Development) 
• ATDD (Acceptance Test Driven Development) 
• FDD (Feature Driven Development)
• KISS (Keep It Simple, Stupid)
• SOLID (tio extrapoäng om du känner till Liskovs kön :)  Ej tillåtet att gissa )
• DRY (Don’t Repeat Yourself)
• YAGNI (You Aren’t Going Need it)
• IOC (Inversion of Control)
• DIP (Dependency injection principle)

Andra

• AOP (Aspect Oriented Programming)
• FBP (Flow-Based Programming)
• Data-Oriented Design
• SSOT (Single Source of Truth)

Och nu till den sista spelomgången. Den handlar om målet med att programmera. Jag skulle säga att det inte har så mycket att göra med något av begreppen här ovanför. Målet handlar ju först och främst om att uppfylla användarnas behov.

Vi utvecklare blir ofta så engagerade i nya verktyg att vi börjar tro att de är målet istället för att se dem som verktyg för att lösa problem, eller fylla olika behov. Och verktyg är absolut viktiga (de hjälper oss att göra saker snabbare, billigare och bättre). Men de är trots allt bara verktyg. 

Bra programvaruingenjörer har flera verktyg i lådan och kan använda dem effektivt. Och det är superbra att utforska utbydet och lära sig om det nya. Men med det sagt, behöver man inte använda alla verktyg (särskilt inte de splitternya, obeprövade) i sitt nästa projekt. Och det är också helt okej att inte använda vissa verktyg alls, även om de skulle kännas lovande. 

Det finns en bok som heter Pragmatic Programmer och nu var det ett tag sen jag läste den, men jag fastnade för idén om det pragmatiska förhållningssättet. Att prova olika verktyg och lära sig deras för- och nackdelar, men också bredda perspektivet och se vilka verktyg som blir populära – och vilka som faller bort. Det gör det så mycket enklare att bestämma sig för vad som är bra att använda här och nu. För det är ju trots allt målet som är det viktiga – att göra kunderna nöjda.

Det finns lika många förhållningssätt som programmerare, men jag tänkte dela med mig av två exempel på hur jag tänkt kring detta i olika situationer. 

Jag minns när jag blev introducerad till enhetstester  och TDD. Jag förstod inte varför det var så värdefullt. Men arkitekten jag arbetade med  bad mig att prova det under en vecka. Och jag blev verkligen fast. Jag har täckt min kod med enhetstester sedan dess. Det slutade dock med att jag var lite mindre imponerad av TDD. Jag kom fram till att det är ett utmärkt verktyg när jag vet vad som ska göras och hur jag ska göra det. Men jag insåg också att det blev ett hinder när man använde det i en upptäcktsfas. Fördelarna som jag tog med mig från TDD är: testbar design, gränssnitt och göra saker i små steg. Jag trodde att testerna ALLTID måste skrivas först. Men tester ska skrivas när det passar – och när det inte passar skjuter jag upp det till senare. 

Vid något tillfälle, förmodligen för ungefär tio år sedan, lärde jag mig om Aspect-Oriented Programming. Jag läste om det och en av mina vänner rekommenderade det starkt. 

När jag först provade kändes det som ett utmärkt sätt att separera problemområden. Men å andra sidan trodde jag att det skulle vara otroligt svårt att förstå hur systemet fungerar (detta är inte bara min observation, här kan du läsa fler aspekter av det). Dessutom var antalet personer som använde AOP försvinnande litet. Det visade sig att det hade sin förklaring, för när jag började använda mig av detta i praktiken blev koden väldigt svår att tyda. Och efter en del övervägande lade jag det åt sidan. Det känns faktiskt fortfarande som rätt beslut, eftersom vi nu ser att det användes i vissa särskilda lägen men aldrig fick någon bred spridning.

Så, för att sammanfatta kring bokstavssoppans vara eller icke vara: Det bästa jag lärt mig att att man ska se till att lära sig nya saker och använda dem när det behövs. Men att det också är bra att vara pragmatisk och se på nyheterna med ett kritiskt öga, för att kunna värdera när man ska och inte ska använda dem.