Nils-Johan Gynther
100 lines
3.7 KiB
Markdown
100 lines
3.7 KiB
Markdown
# Plan för systematisk backend-review och optimering
|
|
|
|
## Mål
|
|
1. Minska komplexitet och duplicering.
|
|
2. Förbättra prestanda och stabilitet.
|
|
3. Göra koden enklare att underhålla och vidareutveckla.
|
|
4. Införa kvalitetsgrindar så förbättringar håller över tid.
|
|
|
|
## Arbetssätt
|
|
1. Jobba i små, säkra iterationer per modul/domän.
|
|
2. Mät före och efter varje förändring.
|
|
3. Lås upp förbättringar med tester och CI-gates.
|
|
4. Prioritera förändringar med hög effekt och låg risk först.
|
|
|
|
## Fas 1: Baslinje och kartläggning (1 vecka)
|
|
1. Inventera backend per modul:
|
|
- Endpoints, tjänster, databasaccess, externa integrationer.
|
|
2. Sätt baslinjemätningar:
|
|
- Responstider per kritisk endpoint (p50/p95), felgrad, DB-latens.
|
|
- Nuvarande testtäckning per modul.
|
|
3. Skapa hotspot-lista:
|
|
- Långa metoder, hög cyclomatic complexity, duplicerad logik, N+1-frågor.
|
|
4. Leverabel:
|
|
- Prioriterad backlog med topp 10 förbättringsområden.
|
|
|
|
## Fas 2: Snabba vinster och kodhygien (1-2 veckor)
|
|
1. Standardisera felhantering:
|
|
- Enhetlig exception mapping och API-felmodell.
|
|
2. Rensa duplicerad kod:
|
|
- Flytta gemensam logik till tydliga utilities/domänservices.
|
|
3. Förbättra validering:
|
|
- Konsekvent DTO/valideringslager in och ut.
|
|
4. Inför striktare lint-regler:
|
|
- Max function length, complexity-tak, no-dead-code.
|
|
5. Leverabel:
|
|
- Minskad kodvolym i hotspots och jämnare kodstandard.
|
|
|
|
## Fas 3: Arkitektur-förenkling (2-3 veckor)
|
|
1. Tydlig separering av lager:
|
|
- Controller = transport.
|
|
- Service = affärslogik.
|
|
- Repository/data layer = persistens.
|
|
2. Minska beroendekoppling:
|
|
- Ta bort korsberoenden mellan moduler.
|
|
3. Inför tydliga domängränser:
|
|
- En modul ska kunna förstås utan att läsa flera andra.
|
|
4. Leverabel:
|
|
- Enklare call-flöden och färre starkt kopplade beroenden.
|
|
|
|
## Fas 4: Databas och prestanda (1-2 veckor)
|
|
1. Granska tunga queries:
|
|
- N+1, överhämtning, saknade index, ineffektiva joins.
|
|
2. Förbättra dataåtkomst:
|
|
- Standard för pagination/filtering.
|
|
- Selektiv hämtning av fält.
|
|
3. Caching där det är motiverat:
|
|
- Endast för dyra och frekventa läsningar.
|
|
4. Leverabel:
|
|
- Mätbar förbättring i p95 och minskad DB-belastning.
|
|
|
|
## Fas 5: Teststrategi och regressionsskydd (1-2 veckor, löpande)
|
|
1. Lägg tester där risk och affärsvärde är högst:
|
|
- Kritiska use cases först.
|
|
2. Balans i testpyramiden:
|
|
- Fler enhetstester för domänlogik.
|
|
- Fokuserade integrations- och API-tester för flöden.
|
|
3. Kontrakttester för externa integrationer.
|
|
4. Leverabel:
|
|
- Högre täckning i kritiska moduler och färre regressionsbuggar.
|
|
|
|
## Fas 6: Säkerhet och driftbarhet (parallellt)
|
|
1. Säkerhetsgranskning:
|
|
- Input-validering, auth/role-kontroller, secret-hantering.
|
|
2. Driftbarhet:
|
|
- Strukturerad loggning, korrelations-id, tydligare metrics.
|
|
3. Resiliens:
|
|
- Timeout/retry/circuit-breaker för externa beroenden.
|
|
4. Leverabel:
|
|
- Färre driftincidenter och enklare felsökning.
|
|
|
|
## Kvalitetsgrindar i CI
|
|
1. Build och lint måste passera.
|
|
2. Tester måste passera.
|
|
3. Miniminivå för täckning i ändrade moduler.
|
|
4. Blockera PR vid ökad komplexitet över satt tröskel.
|
|
5. Enkel performance-smoke på kritiska endpoints.
|
|
|
|
## Prioriteringsmodell för varje förbättring
|
|
1. Effekt: prestanda, stabilitet, underhållbarhet.
|
|
2. Risk: regressionsrisk och driftsrisk.
|
|
3. Insats: utvecklingstid.
|
|
4. Välj först: hög effekt + låg/medel risk + låg/medel insats.
|
|
|
|
## Definition of Done
|
|
1. Kritiska endpoints har förbättrad p95.
|
|
2. Topp-hotspots är refaktorerade eller borttagna.
|
|
3. Kodduplicering reducerad i prioriterade moduler.
|
|
4. Testskydd finns för alla kritiska flöden.
|
|
5. CI-gates förhindrar att kvaliteten glider tillbaka.
|