Kodekvalitetsmønstre

Lær mer om velbygd ressurs- og kostnadsoptimalisering → Kodeorganisasjon

Denne konsoliderte mønstersiden dekker praksis for kodekvalitet og vedlikehold for Ressursoptimalisering. Den inkluderer veiledning om standardbeslutninger kontra tilpassede kodebeslutninger, teknisk gjeldsbehandling, designstandarder, dokumentasjonsrutiner og styring. Disse mønstrene bidrar til å opprettholde utviklingshastighet, redusere defektfrekvenser og muliggjøre langsiktig løsningens bærekraft.

Mønstre

Hvor du kan se	Hvordan det ser bra ut
Ydeevne i stor skala	✅ Testing validerer om deklarative løsninger oppfyller ytelseskravene for projiserte datavolumer. Innlasting av testing i Full kopi-Sandbox med realistiske data bekrefter skalerbarhet før produksjonsdistribusjon.
Vedlikeholdsanalyse	✅ TCO-analyse sammenligner langsiktig vedlikeholdsbelastning for deklarative kontra tilpassede tilnærminger, inkludert oppgraderingsinnsats, testkrav og kvalifikasjonskrav for fremtidige team.
Architektur med blandet tilgang	✅ Løsninger kombinerer deklarative og programmatiske tilnærminger der det er aktuelt. Flytorkestrer logikk på høyt nivå, mens Apex håndterer komplekse beregninger. Formelfelt beregner enkle utledninger mens Apex behandler masseoperasjoner.
AppExchange evaluering	✅ Før du bygger tilpasset kode, bør du evaluere eksisterende AppExchange pakker som gir lignende funksjonalitet. Dokumentvurderingsresultater, inkludert pakker som er gjennomgått, kapasitetsgap og TCO-sammenligning.

Mønstre

Hvor du kan se	Hvordan det ser bra ut
Backlog synlighet	✅ Tekniske gjeldselementer sporet i etterslep med tydelige etiketter, kontekst som forklarer hvorfor koden trenger forbedring, forretningseffekten av å la den være ubesvart, og anslått rettelsesinnsats. Usynlig gjeld kan ikke prioriteres eller behandles.
Inkrementell forbedring	✅ Boy scout-regel brukt under funksjonsutvikling: la kode være bedre enn funnet Team løser gjeld trinnvis under relatert funksjonsarbeid i stedet for å kreve store, dedikerte refaktoringprosjekter. Kodevurderinger kontrollerer trinnvise forbedringer.
Prevention over remedy (Prevention over rettelse)	✅ Kvalitetsportaler i CI/CD håndhever standarder før kode når produksjon. Kodeskanner, ApexGuru og kompleksitetsmålinger integrert i validering av henteforespørsler. Blokkering av problemer hindrer fletting til de løses.

Anti-Mønstre

Hvor du kan se	Hvordan dårlig ser ut
Backlog-behandling	⚡️ Teknisk gjeld bekreftet muntlig, men aldri sporet i etterslep. Ingen synlighet til gjeldsakkumulering. Gjeldsbehandling utsettes alltid til fordel for funksjonsarbeid. Hastigheten reduseres gradvis, team kan ikke forklare hvorfor.
Kvalitetsportbypass	⚡️ CI/CD-kvalitetsportaler forbigås ofte under tidsplandrykk med hensikt å fikse senere. “Senere” skjer aldri. Kodeskannerfeil som er merket som kjente problemer og ignorert. Kompleksitetsterskeler hevet for å ta hensyn til dårlige implementeringer.
Ingen løsningskapasitet	⚡️ 100 % av sprintkapasiteten tildelt til funksjonsarbeid med null kapasitet for teknisk gjeldsbehandling. Skyld akkumuleres på ubestemt tid. Viktige refaktoringprosjekter kreves hver 18.-24. måned og bruker hele kvartaler.
Konfigurasjonsforpliktelse	⚡️ Tilpassede metadatatyper og tilpassede innstillinger akkumuleres uten opprydding. Ubrukte konfigurasjoner beholdes på ubestemt tid. Produksjonen har 50 metadataposter, bare 12 brukes faktisk. Ingen dokumentasjon som forklarer formålet med konfigurasjonsverdier.

Mønstre

Hvor du kan se	Hvordan det ser bra ut
Utløserarkitektur	✅ Utløserbehandlermønster brukt konsekvent: tynne utløsere delegeres til behandlerklasser, behandlerklasser organiserer logikk etter utløserkontekst (før innsetting, etter oppdatering), fjerne metodenavn viser formålet. Ingen forretningslogikk i selve utløserfilene.
Implementering av tjenestelag	✅ Forretningslogikk innkapslet i serviceklasser atskilt fra kontroller, utløsere og gruppeoppføringspunkter. Tjenesteklasser som kan gjenbrukes på tvers av flere inngangspunkter uten duplisering. Tøm navnekonvensjonen (AccountService, OrderProcessor).
Velgermønster	✅ SOQL-spørringer sentralisert i velgerklasser per objekt (AccountSelector, OpportunitySelector). Velgermetoder returnerer konsistente feltsett. LDV-optimaliseringsendringer brukt én gang, som påvirker alle spørringer.
repositoriemønster	✅ Datatilgang abstrakt bak grensesnitt som aktiverer testing med mock-datakilder. Repositoriumimplementasjoner innkapsler spørringsbyggings-, bufrings- og optimaliseringsstrategier. Forretningslogikk avhenger av repositoriumsgrensesnitt, ikke konkrete implementeringer.
Komponentutformingsstandarder	✅ Lightning Web-komponenter følger prinsippet om enkeltansvar, viser egenskaper for konfigurasjon, sender hendelser for overordnet kommunikasjon, designet for komposisjon og gjenbruk. Komponentbibliotek dokumentert med brukseksempler.
Kodeorganisasjon	✅ Logiske pakkestrukturgrupper for relaterte klasser. Fjern skillet mellom domenelogikk, datatilgang, API-endepunkter og integrasjonsadaptere. Pakkeavhengigheter flyter i én retning.

Anti-Mønstre

Hvor du kan se	Hvordan dårlig ser ut
Utløsere	⚡️ All forretningslogikk innebygd direkte i utløserfiler med dypt nestede betingelser, ingen adskillelse av bekymringer, ingen behandlerklasser. 300+ linjeutløsere som blander validering, forretningslogikk og integreringskall. Det er ikke mulig å teste effektivt.
Spørring i sløyfe	⚡️ SOQL-spørringer utført i gjentagelsessykluser. Fungerer med små datavolumer, men bryter grensen for 100 SOQL-spørringer ved behandling av masseoperasjoner. Oppdages bare når utløsere utløses på massedatalastinger i produksjonsorganisasjonen.
DML i sløyfe	⚡️ DML-setninger (sett inn, oppdater, slett) utført i gjentagelsessykluser. Bryder grensen på 150 DML-setninger med masseoperasjoner. Hver post behandles i separat databasetransaksjon i stedet for effektiv massebehandling.

Mønstre

Hvor du kan se	Hvordan det ser bra ut
Beslutningsposter for arkitektur	✅ Viktige arkitektoniske beslutninger dokumentert i ADR-er lagret i versjonskontroll. ADR-er fanger opp kontekst (forretningsdrivere, tekniske begrensninger), beslutning (hva som ble valgt), vurderte alternativer (hvorfor de ble avvist) og konsekvenser (avtaler, betingelser for revisjon).