Agila utvecklare måste även skriva sin kod på ett agilt sätt för att vara helt agila

Agila team som jobbar enligt t.ex. scrum jobbar agilt avseende planering, kravhantering och arbetsgång, men det är bara ena sidan av det agila myntet.

Sen är även automatiserade enhetstester och CI/CD vanligt inom agil utveckling där man automatiserar test, integration och deployment av en applikation.

Men det många utvecklare missat är att agil utveckling även innebär att man skriver sin kod och lösning på ett agilt sätt, och inte gör överarbetade och överkomplicerade ”perfekta” lösningar som tar hänsyn till allt som kan behövas i framtiden och använder varenda designmönster och cool finess som finns, eller för den delen motsatsen och gör obegriplig spagettikod.

En agil utvecklare ska följa KISS och YAGNI principerna och inte göra mer än vad som behövs för att lösa problemet just nu med rimlig hänsyn tagen till förvaltningsbarhet, utökningsbarhet och återanvändbarhet.

Återanvändbarhet är däremot oftast svårt att uppnå, så skriv för det specifika fallet och återanvänd det som råkar passa till det, om det inte är uppenbart att något är återanvändningsbart från början.

En agil utvecklare ska inte sub-optimera sin kod in i absurdum och försöka göra bästa möjliga tekniska lösning för alla tänkbara framtida scenarion eller osannolika scenarion med liten risk att inträffa, utan låta tiden utvisa om det verkligen behövs.

Tillkommer nya krav eller omständigheter i framtiden så löser man dem då.

Nedan artikel tycker jag på ett väldigt bra sätt summerar hur man kan tänka och jobba som agil utvecklare, för det är lika viktigt som att jobba agilt med kraven och den andra sidan av det agila myntet.

5 Principles for (Agile) Software Development that improve Agility (and make you a better developer)

De 5 principerna för agil programutveckling är:

  1. Just in Time Design & coding
  2. Think, write, test, refactor
  3. Unit testing
  4. Write Object-Oriented code (OO), not procedural code
  5. Apply Agile Design Patterns and Principles

Man kanske inte alltid ska följa alla SOLID principerna fullt ut som punkt 5 handlar om då det tenderar att skapa ett system som innehåller väldigt många små delar som kan bli svåra att överblicka och hantera.

Do SOLID design principles make code slow?

Man ska alltså vara pragmatisk och inte dogmatiskt när det gäller SOLID principerna, för det är inte alltid berättigat eller nödvändigt att använda dem fullt ut.

3 Key Software Principles You Must Understand

3 andra huvudprinciper för programutveckling är:

  1. Don’t Repeat Yourself (DRY)
  2. Keep it Simple Stupid (KISS)
  3. You ”Ain’t Gonna Need It (YAGNI)

När det gäller punkt 5 kan man även försöka följa DRY principen som först nämndes i den klassiska boken The Pragmatic Programmer.

The DRY Principle Explained: Its Benefit and Cost with Examples

Även när det gäller DRY principen ska ni vara pragmatiska och inte dogmatiska så det inte blir för mycket av det goda, för lagom är bäst.

When to avoid the DRY principle

Här en artikel som i kod ger praktiska exempel på många av principerna så ni får en mer handfast förståelse. Kodexemplen är i TYPESCRIPT så det är lätt för er att testa dem själva.

How to become a better programmer ?

Tycker även själv The Zen of Pythons 20 regler ger en bra bild av hur man ska skriva enkel kod på ett bra sätt och ser dem som ett komplement till de tidigare nämnda principerna.

What do different aphorisms in The Zen of Python mean?

When programming in Python, you should…

PEP 20 (The Zen of Python) by example

Sen är Separation Of Concerns principen och Single Responsibility principen (som är S’et i SOLID) de mest essentiella, så ni kan börja med att använda dem och OOP.

Försök även hålla er till max två nivåer av arv och god namnsättning så koden blir lätt att förstå.

Rent praktiskt kan ni åstadkomma separation of concerns genom att designa era applikationer enligt antingen MVC eller den klassiska N-tier arkitekturen som är två olika sätt att åstadkomma det på.

Overview of ASP.NET Core MVC

Och genom att även tillämpa best practices för ASP.NET MVC arkitekturer uppnår ni en bra nivå på separation of concerns och single resonsibility principerna även för större system.

ASP.NET MVC Solution Architecture – Best Practices

För mindre applikationer som inte kommer förändras så mycket kan en enklare arkitektur räcka, och i andra fall kanske microservice arkitektur är bättre, så allt beror på (kom ihåg KISS & YAGNI).

Självklart ihop med bra tester som kan vara enhetstester, integrationstester eller acceptanstester som ska vara så automatiserade som möjligt.

Nedan en bra videoserie på YouTube som förklarar de 5 SOLID principerna, och den 6:e och sista videon förklarar DRY principen.