Gillar du som utvecklare bokstavssoppa?

Gillar du som utvecklare bokstavssoppa?

2021-09-30

Det var en gång när programmering var enkelt. Det var bara att skriva kod. Nu finns det fler metoder och principer än vad det finns utvecklare. Låt oss spela ett spel - hur många av följande begrepp förstår du?


Ge dig en poäng om du vet vad det är, två poäng om du tror att du förstår det väl och fem poäng om du förstår och har använt den (i produktion).


Programming paradigms

  • OOP (Object Oriente Programming)
  • Procedural
  • Functional

Driven

  • TDD (Test Driven Development) 
  • DDD (Domain Driven Design) 
  • BDD (Behavioural Driven Development) 
  • ATDD (Acceptance Test Driven Development) 
  • FDD (Feature Driven Development)

Principles

  • 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)


Jag låter med flit bli att ta upp utvecklingsmetoder och “architectural patterns” för att hålla någorlunda balans. Men om du vill tjäna ännu fler poäng kan du gärna besöka den här sidan (som innehåller mer än ett femtiotal artiklar): https://en.wikipedia.org/wiki/List_of_software_development_philosophies


Och nu till den sista omgången. Vad är målet med att programmera? Jag ska ge dig en ledtråd. Det har inget att göra med något av det jag skrev ovan.


Målet är att tillfredsställa användarnas behov.


Jag hoppas att du vill fråga mig vid det här laget: "Åh. Vänta. Hur blir det med alla mina poäng? Gjorde jag det bra? Vann jag?"


Svaret är: Vi (utvecklare) blir ofta så engagerade i dessa verktyg att vi börjar tro att de är målet istället för att se det som ett verktyg att lösa problem och behov. Verktyg är viktigt (för att göra saker snabbare, billigare och bättre). Men återigen är det bara verktyg.


Bra programvaruingenjörer har fler verktyg i ryggsäcken och kan använda dem effektivt. Och jag vill starkt uppmuntra dem att utforska och lära sig nya. Du behöver dock inte använda alla verktyg (särskilt inte de nya “glänsande” verktygen) i ditt nästa projekt. Och det är okej att INTE använda vissa verktyg (även om de ser lovande ut).


Det finns en fantastisk bok - Pragmatic Programmer. Ärligt talat läste jag den för ganska länge sedan, så jag kan inte citera den vid det här laget. Jag gillade dock idén om pragmatism. Man provar olika verktyg, lär sig deras fördelar och nackdelar, ser sig omkring och ser vilka verktyg som blir populära och vilka som faller bort. Och till slut bestämmer man sig för vad som är vettigt att använda här och nu.


I slutändan måste du hålla ögonen på målet - att göra kunderna nöjda.

Låt mig avsluta med två anekdoter om hur jag tillämpat detta i livet.


Enhetstester och TDD

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 då bad mig dock att prova det under en vecka. Och oh vad jag blev 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 det jag sedan upptäckte var att det blev ett hinder när man använde det i en upptäcktsfas. De bra delar 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. 


AOP

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 även en av mina vänner rekommenderade det starkt. 

När jag först provade det 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 (OBS detta är inte bara min observation - https://en.wikipedia.org/wiki/Aspect-oriented_programming#Criticism). Dessutom var antalet personer som använde AOP försvinnande litet. Det hade kanske sin förklaring för först när jag började använda mig av detta i praktiken, resulterade det i att koden blev väldigt svår att tyda. Och efter en del övervägande lade jag detta åt sidan. När jag ser tillbaka tycker jag att det var rätt beslut. Det slutade med att det användes i vissa särskilda lägen men fick inte någon bred spridning.


Och om jag ska sammanfatta det som skrivits. Lär dig nya saker, använd dem när det behövs, var pragmatisk och samtidigt se på dem med ett kritiskt öga så att du vet när du ska och inte ska använda dem.

Debattinlägg från Victor Ronin.

Har du idéer på ett intressant eller roligt ämne att skriva om eller kanske till och med en redan färdig artikel? Klicka här för att läsa mer.

Demando Demando