Kodekvalitetsmønstre

Få mere at vide om veludformet ressourceoptimering → Kodeorganisation

Denne konsoliderede mønsterside dækker kodekvalitets- og vedligeholdelsespraksisser for Ressourceoptimering. Den inkluderer vejledning om standardbeslutninger i forhold til tilpassede kodebeslutninger, teknisk gældsstyring, designstandarder, dokumentationspraksisser og styring. Disse mønstre hjælper med at bevare udviklingshastighed, reducere fejlfrekvenser og aktivere langsigtet løsningsstabilitet.

Mønstre

Hvor skal du se	Hvordan godt ser ud
Ydeevne på skala	✅ Test validerer, at deklarative løsninger opfylder krav til ydeevne ved projekterede datamængder. Indlæsningstest i Full Copy Sandbox med realistiske data bekræfter skalerbarhed før produktionsimplementering.
Vedligeholdelsesanalyser	✅ TCO-analyse sammenligner den langsigtede vedligeholdelsesbelastning af deklarative kontra tilpassede tilgange, herunder opgraderingsindsats, testkrav og færdighedskrav for fremtidige teams.
Architektur for blandet tilgang	✅ Løsninger kombinerer deklarative og programmeringsmæssige tilgange, hvor det er relevant. Forløb orkestrerer logik på højt niveau, mens Apex håndterer komplekse beregninger. Formelfelter beregner enkle afledninger, mens Apex behandler massehandlinger.
AppExchange	✅ Før du opbygger tilpasset kode, skal du evaluere eksisterende AppExchange, der leverer lignende funktionalitet. Dokumentevalueringsresultater, herunder pakker, der er gennemset, funktionsmangler og TCO-sammenligning.

Mønstre

Hvor skal du se	Hvordan godt ser ud
Tilbagevendelsessynlighed	✅ Tekniske gældselementer, der spores i tilbagerulning med tydelige betegnelser, kontekst, der forklarer, hvorfor kode har brug for forbedring, forretningseffekt ved at lade den være utilpasset og estimeret rettelsesindsats. Usynlig gæld kan ikke prioriteres eller administreres.
Trinvis forbedring	✅ Boy Scout-regel anvendt under funktionsudvikling: efterlade kode bedre end fundet. Teams afhjælper gæld trinvist under relateret funktionsarbejde i stedet for at kræve store dedikerede omstruktureringsprojekter. Kodeanmeldelser bekræfter trinvise forbedringer.
Forebyggelse over afhjælpning	✅ Kvalitetsportaler i CI/CD håndhæver standarder, før kode når produktion. Kodescanner, ApexGuru og kompleksitetsmetrikker integreret i validering af pull-anmodninger. Blokering af problemer forhindrer fletning, indtil de er løst.

Anti-mønstre

Hvor skal du se	Hvad ser dårligt ud
Tilbagerulningsstyring	⚡️ Teknisk gæld bekræftet verbalt, men aldrig sporet i tilbagerulning. Ingen indsigt i gældsakkumulering. Gældsremission udskydes altid til fordel for funktionsarbejde. Hastigheden falder gradvist, og teams kan ikke forklare hvorfor.
Quality gate-tilsidesættelse	⚡️ CI/CD-kvalitetsportaler tilsidesættes ofte under tidsplanstryk med hensigt om at rette dem senere. “Senere” sker aldrig. Kode-scannerfejl markeret som kendte problemer og ignoreret. Kompleksitetstærskler hævet for at tage højde for dårlige implementeringer.
Ingen løsningskapacitet	⚡️ 100 % af sprintkapacitet allokeret til funktionsarbejde med nul kapacitet til teknisk gældsændring. Gæld akkumuleres uendeligt. Større omstruktureringsprojekter kræves for hver 18-24 måneder, hvilket forbruger hele kvartaler.
Konfigurationsgæld	⚡️ Tilpassede metadatatyper og tilpassede indstillinger akkumuleres uden oprydning. Ubrugte konfigurationer bevares uendeligt. Produktion har 50 metadataregistreringer, kun 12 bruges faktisk. Ingen dokumentation, der forklarer formålet med konfigurationsværdier.

Mønstre

Hvor skal du se	Hvordan godt ser ud
Udløserarkitektur	✅ Udløserhåndteringsmønster anvendt ensartet: tynde udløsere uddelegeres til handlerklasser, handlerklasser organiserer logik efter udløserkontekst (før indsættelse, efter opdatering), tydelige metodenavne afslører formål. Ingen forretningslogik i udløserfilerne selv.
Service Layer-implementering	✅ Forretningslogik, der er indbygget i serviceklasser, adskilt fra controllere, udløsere og batchindgangspunkter. Serviceklasser, der kan genbruges på tværs af flere indgangspunkter uden duplikering. Ryd navngivningskonvention (AccountService, OrderProcessor).
Vælgermønster	✅ SOQL-forespørgsler centraliseret i vælgerklasser pr. objekt (AccountSelector, OpportunitySelector). Vælgermetoder returnerer ensartede feltsæt. LDV-optimeringsændringer anvendes en gang, hvilket påvirker alle forespørgsler.
Lagermønster	✅ Dataadgang, der er abstrakt bag grænseflader, der aktiverer test med falske datakilder. Lagringsimplementeringer indkapsler forespørgselsopbygning, cachelagring og optimeringsstrategier. Forretningslogik afhænger af lagergrænseflader, ikke konkrete implementeringer.
Komponentdesignstandarder	✅ Lightning Web-komponenter følger princippet om enkelt ansvar, viser egenskaber til konfiguration, udsender begivenheder til overordnet kommunikation, designet til sammensætning og genbrug. Komponentbibliotek dokumenteret med anvendelseseksempler.
Kodeorganisation	✅ Logiske pakkestrukturgrupper, relaterede klasser. Ryd adskillelse mellem domænelogik, dataadgang, API-slutpunkter og integrationsadaptere. Pakkeafhængigheder forløber i en retning.

Anti-mønstre

Hvor skal du se	Hvad ser dårligt ud
Udløsere	⚡️Al forretningslogik integreret direkte i udløserfiler med dybt indlejrede betingelser, ingen adskillelse af bekymringer, ingen handlerklasser. Over 300 linjeudløserfiler, der blander validering, forretningslogik og integrationsopkald. Kan ikke testes effektivt.
Forespørg i løkke	⚡️ SOQL-forespørgsler, der afvikles i gentagelsesløkker. Fungerer med små datamængder, men overtræder 100 SOQL-forespørgselsgrænsen ved behandling af massehandlinger. Opdages kun, når udløsere aktiveres på massedataindlæsninger i produktion.
DML i løkke	DML-erklæringer (indsæt, opdater, slet), der afvikles i gentagelsesløkker. Overtræder grænsen på 150 DML-erklæringer med massehandlinger. Hver registrering behandles i separat databasetransaktion i stedet for effektiv massebehandling.

Mønstre

Hvor skal du se	Hvordan godt ser ud
Architekturbeslutningsregistreringer	✅ Vigtige arkitektoniske beslutninger, der er dokumenteret i ADR’er, der er lagret i versionskontrol. ADR’er registrerer kontekst (forretningsdrivere, tekniske begrænsninger), beslutning (hvad der blev valgt), overvejede alternativer (hvorfor de blev afvist) og konsekvenser (afhandlinger, betingelser for at se igen).