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

”Writing good code is very challenging. Writing good code in an Agile environment is even harder. At least, that’s what it might look like. Because Agile teams have to be economic with their time, so they require strategies that allow them to maintain their flexibility throughout the sprint. Thankfully, many developers have gone before us and there’s a lot we can learn from their experiences”

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.

Ni kan börja med att läsa igenom nedan artikel som går igenom de 22 vanligaste misstagen programmerare gör så ni har grunden klar för er.

The Mistakes I Made As a Beginner Programmer

3 grundprinciper för agil systemutveckling

3 grundprinciper för agil systemutveckling är:

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

3 Key Software Principles You Must Understand

DRY principen

Man ska 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

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, men i de allra flesta fall är duplicerad kod inte bra.

When to avoid the DRY principle

KISS och YAGNI principerna

Man ska 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å.

KISS och YAGNI principerna

Din kod ska vara enkel att förstå

”A good developer creates things that are easy to understand so that it’s really easy to shake out all the bugs.”

KISS och YAGNI principerna är ingen ursäkt för att skriva obegriplig spagettikod så din kod ska även vara enkel att förstå och förvalta.

Learn the fundamentals of a good developer mindset in 15 minutes

The Zen of Pythons 20 regler

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

Fem huvudprinciper för agil systemutveckling

Följande 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.

De 5 huvudprinciperna för agil systemutveckling ä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

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

Videos om de 5 SOLID principerna och DRY pricipen

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

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, och kan vara overkill för mindre system som inte kommer ändras så mycket i framtiden.

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 alla fullt ut.

Viktigaste principerna att använda inom agil systemutveckling

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

Försök även hålla er till composition before inheritance, max två nivåer av arv, god namnsättning och skriv så att koden blir lätt att förstå så följer ni i stort DRY, KISS & YAGNI principerna

Separation of concerns

Rent praktiskt kan ni åstadkomma separation of concerns genom att designa era applikationer enligt antingen den klassiska N-tier eller N-layer arkitekturen

N-tier data applications overview

Eller MVC arkitekturen som är två olika sätt att åstadkomma det på.

Overview of ASP.NET Core MVC

Best practices för ASP.NET MVC arkitekturer

Genom att även tillämpa best practices för ASP.NET MVC arkitekturer uppnår ni en bra nivå på separation of concerns, single resonsibility principerna och lös koppling ä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 som till exempel det ni får out-of-the-box när ni skapar ett MVC projekt, och i andra fall kanske microservice arkitektur eller domain driven design är bättre, så allt beror på (kom ihåg KISS & YAGNI).

Common web application architectures

Dependency injection i C# och Asp.Net Core

I Asp.Net Core 2.1 och framåt finns redan en dependency injection container inbyggt så ni behöver inte alltid använda Autofac där, men det beror på hur avancerade behov ni har.

.NET Core project without Autofac. Is it viable?

Dependency injection in ASP.NET Core

Ibland behöver man inte använda IoC containar alls utan kan nöja sig med gammal hederlig manuell dependency injection i stället, eller kanske ingen dependency injection alls.

Dependency Injection in C#

TDD och automatiserade enhetstester

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

När det gäller enhetstester finns två skolor.

Den dogmatiska TDD linjen som förespråkar att man alltid ska skriva enhetstester först och testa 100% av koden, och en pragmatisk som anser att man bara behöver testa den viktigaste affärslogiken med enhetstester, och kan skriva enhetstester efter man är klar med den initiala versionen av en metod eller klass och har fått bättre förståelse för problemet.

Hur omfattande tester som behövs beror också på, så även där ska ni tillämpa KISS och YAGNI.

Unit Testing in ASP .NET Core

Praktiska exempel på många av principerna

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 oavsett vilket som är ert huvudspråk.

How to become a better programmer ?