Nils-Johan Gynther
ca8987d9e4
Test Suite / test (24.15.0) (push) Has been cancelled
- Introduced user guide for Flutter frontend in README.md, detailing user flows and recent improvements. - Created next steps roadmap for Flutter migration in next_steps_flutter.md, outlining current tasks and priorities. - Developed technical description for Flutter frontend in teknisk_beskrivning_flutter.md, covering architecture and security status. - Removed outdated migration documentation for Prisma P3009 and added recovery steps for failed migrations in migrering-MSI.md. - Established a release checklist for product launches in produktlansering.md, ensuring security and stability measures are met. - Formulated a systematic backend review and optimization plan in review_backend.md, focusing on reducing complexity and improving performance.
4.5 KiB
4.5 KiB
Plan för systematisk backend-review och optimering
Mål
- Minska komplexitet och duplicering.
- Förbättra prestanda och stabilitet.
- Göra koden enklare att underhålla och vidareutveckla.
- Införa kvalitetsgrindar så förbättringar håller över tid.
Arbetssätt
- Jobba i små, säkra iterationer per modul/domän.
- Mät före och efter varje förändring.
- Lås upp förbättringar med tester och CI-gates.
- Prioritera förändringar med hög effekt och låg risk först.
Fas 1: Baslinje och kartläggning (1 vecka)
- Inventera backend per modul:
- Endpoints, tjänster, databasaccess, externa integrationer.
- Sätt baslinjemätningar:
- Responstider per kritisk endpoint (p50/p95), felgrad, DB-latens.
- Nuvarande testtäckning per modul.
- Skapa hotspot-lista:
- Långa metoder, hög cyclomatic complexity, duplicerad logik, N+1-frågor.
- Leverabel:
- Prioriterad backlog med topp 10 förbättringsområden.
Fas 2: Snabba vinster och kodhygien (1-2 veckor)
- Standardisera felhantering:
- Enhetlig exception mapping och API-felmodell.
- Rensa duplicerad kod:
- Flytta gemensam logik till tydliga utilities/domänservices.
- Förbättra validering:
- Konsekvent DTO/valideringslager in och ut.
- Inför striktare lint-regler:
- Max function length, complexity-tak, no-dead-code.
- Leverabel:
- Minskad kodvolym i hotspots och jämnare kodstandard.
Fas 3: Arkitektur-förenkling (2-3 veckor)
- Tydlig separering av lager:
- Controller = transport.
- Service = affärslogik.
- Repository/data layer = persistens.
- Minska beroendekoppling:
- Ta bort korsberoenden mellan moduler.
- Inför tydliga domängränser:
- En modul ska kunna förstås utan att läsa flera andra.
- Leverabel:
- Enklare call-flöden och färre starkt kopplade beroenden.
Fas 4: Databas och prestanda (1-2 veckor)
- Granska tunga queries:
- N+1, överhämtning, saknade index, ineffektiva joins.
- Förbättra dataåtkomst:
- Standard för pagination/filtering.
- Selektiv hämtning av fält.
- Caching där det är motiverat:
- Endast för dyra och frekventa läsningar.
- Leverabel:
- Mätbar förbättring i p95 och minskad DB-belastning.
Fas 5: Teststrategi och regressionsskydd (1-2 veckor, löpande)
- Lägg tester där risk och affärsvärde är högst:
- Kritiska use cases först.
- Balans i testpyramiden:
- Fler enhetstester för domänlogik.
- Fokuserade integrations- och API-tester för flöden.
- Kontrakttester för externa integrationer.
- Leverabel:
- Högre täckning i kritiska moduler och färre regressionsbuggar.
Fas 6: Säkerhet och driftbarhet (parallellt)
- Säkerhetsgranskning:
- Input-validering, auth/role-kontroller, secret-hantering.
- Inventory är nu user-scopad och IDOR-skyddad: Alla inventory-operationer kräver och filtrerar på userId i backend (schema, migration, service, controller, tester). Tester verifierar att åtkomst nekas vid försök till IDOR.
- Driftbarhet:
- Strukturerad loggning, korrelations-id, tydligare metrics.
- Resiliens:
- Timeout/retry/circuit-breaker för externa beroenden.
- Leverabel:
- Färre driftincidenter och enklare felsökning.
Kvalitetsgrindar i CI
- Build och lint måste passera.
- Tester måste passera.
- Miniminivå för täckning i ändrade moduler.
- Blockera PR vid ökad komplexitet över satt tröskel.
- Enkel performance-smoke på kritiska endpoints.
Prioriteringsmodell för varje förbättring
- Effekt: prestanda, stabilitet, underhållbarhet.
- Risk: regressionsrisk och driftsrisk.
- Insats: utvecklingstid.
- Välj först: hög effekt + låg/medel risk + låg/medel insats.
Definition of Done
- Kritiska endpoints har förbättrad p95.
- Topp-hotspots är refaktorerade eller borttagna.
- Kodduplicering reducerad i prioriterade moduler.
- Testskydd finns för alla kritiska flöden.
- CI-gates förhindrar att kvaliteten glider tillbaka.