Codekwaliteitspatronen

Lees meer over EPS Kisten van 75 x 60cm en 70 x 70cm → Code Organisatie

Deze geconsolideerde patroonpagina behandelt codekwaliteit en onderhoudbaarheidspraktijken voor Resourceoptimalisering. Het omvat richtlijnen voor beslissingen over standaard- versus aangepaste code, technisch schuldenbeheer, ontwerpnormen, documentatiepraktijken en governance. Deze patronen helpen de ontwikkelsnelheid te handhaven, het aantal defecten te verminderen en duurzaamheid van oplossingen op lange termijn mogelijk te maken.

Patronen

Waar te zoeken	Hoe goed eruitziet
Prestaties op schaal	✅ Testen valideert dat declaratieve oplossingen voldoen aan prestatievereisten bij geprojecteerde gegevensvolumes. Laadtests in Full Copy Sandbox met realistische gegevens bevestigen schaalbaarheid vóór productie-implementatie.
Onderhoudbaarheidsanalyse	✅ TCO-analyse vergelijkt de onderhoudslast op lange termijn van declaratieve versus aangepaste benaderingen, waaronder upgrade-inspanning, testvereisten en vaardigheidsvereisten voor toekomstige teams.
Architectuur van gemengde aanpak	✅ Oplossingen combineren waar nodig declaratieve en programmatische benaderingen. Stroom orkestreert logica op hoog niveau, terwijl Apex complexe berekeningen afhandelt. Formulevelden berekenen eenvoudige afleidingen, terwijl Apex bulkbewerkingen verwerkt.
AppExchange evaluatie	✅ Voordat u aangepaste code maakt, evalueert u bestaande AppExchange pakketten die soortgelijke functionaliteit bieden. Documentevaluatieresultaten inclusief beoordeelde pakketten, capaciteitshiaten en vergelijking van TCO.

Patronen

Waar te zoeken	Hoe goed eruitziet
Achterstandzichtbaarheid	✅ Technische schulditems bijgehouden in achterstand met duidelijke labels, context verklaren waarom code verbetering nodig heeft, zakelijke impact van het niet aangepakt laten, en geschatte herstelinspanning. Onzichtbare schulden kunnen niet worden geprioriteerd of beheerd.
Incrementele verbetering	✅ Boy scout regel toegepast tijdens de ontwikkeling van de functie: laat code beter dan gevonden. Teams lossen schulden incrementeel op tijdens gerelateerd voorzieningenwerk in plaats van grote specifieke refactorenprojecten te vereisen. Codebeoordelingen verifiëren incrementele verbeteringen.
Preventie boven sanering	✅ Kwaliteitspoorten in CI / CD dwingen normen af voordat code productie bereikt. Codescanner, ApexGuru en complexiteitsmeetgegevens die zijn geïntegreerd in pullverzoekvalidatie. Blokkeringsproblemen verhinderen samenvoegen totdat ze zijn opgelost.

Anti-patronen

Waar te zoeken	Hoe slecht eruitziet
Achterstandsbeheer	⚠️ Technische schuld erkend mondeling, maar nooit bijgehouden in achterstand. Geen zicht op schuldopbouw. Schuldsanering altijd uitgesteld ten gunste van voorzieningenwerk. Snelheid neemt geleidelijk af, teams kunnen niet verklaren waarom.
Kwaliteit poort bypass	⚠️ CI / CD-kwaliteit poorten vaak omzeild onder planningsdruk met de bedoeling om later te repareren. “Later” gebeurt nooit. Mislukte codescanner gemarkeerd als bekende problemen en genegeerd. Complexiteitsdrempels verhoogd om rekening te houden met slechte implementaties.
Geen herstelcapaciteit	⚠️ 100% van de sprintcapaciteit die is toegewezen aan voorzieningenwerk met nul capaciteit voor technische schuldsanering. Schuld stapelt zich voor onbepaalde tijd op. Grote refactoringprojecten die elke 18-24 maanden nodig zijn en hele kwartalen verbruiken.
Configuratieschuld	⚠️ Typen aangepaste metagegevens en aangepaste instellingen worden verzameld zonder opschoning. Ongebruikte configuratie blijft voor onbepaalde tijd bestaan. Productie heeft 50 metagegevensrecords, waarvan er slechts 12 daadwerkelijk worden gebruikt. Geen documentatie waarin het doel van configuratiewaarden wordt uitgelegd.

Patronen

Waar te zoeken	Hoe goed eruitziet
Triggerarchitectuur	✅ Trigger handler patroon consequent toegepast: dunne triggers delegeren aan handlerklassen, handlerklassen organiseren logica op triggercontext (vóór invoegen, na bijwerken), duidelijke methodenamen onthullen doel. Geen bedrijfslogica in triggerbestanden zelf.
Implementatie van servicelagen	✅ Business logica ingekapseld in serviceklassen gescheiden van controllers, triggers en batchinvoerpunten. Serviceklassen die zonder duplicering opnieuw kunnen worden gebruikt voor meerdere invoerpunten. Naamgevingsconventie wissen (AccountService, OrderProcessor).
Selectorpatroon	✅ SOQL-query’s gecentraliseerd in selectorklassen per object (AccountSelector, OpportunitySelector). Selectormethoden retourneren consistente veldsets. LDV-optimaliseringswijzigingen zijn één maal toegepast en hebben invloed op alle query’s.
Patroon van opslagplaats	✅ Gegevenstoegang geabstraheerd achter interfaces die testen met nepgegevensbronnen mogelijk maken. Repository-implementaties omvatten queryconstructie, caching en optimaliseringsstrategieën. Bedrijfslogica is afhankelijk van repository-interfaces, niet van concrete implementaties.
Componentontwerpnormen	✅ Lightning webcomponenten volgen het principe van enkelvoudige verantwoordelijkheid, maken eigenschappen zichtbaar voor configuratie, zenden events uit voor bovenliggende communicatie, ontworpen voor samenstelling en hergebruik. Componentenbibliotheek gedocumenteerd met gebruiksvoorbeelden.
Code-organisatie	✅ Logische pakketstructuur groepen gerelateerde klassen. Duidelijke scheiding tussen domeinlogica, gegevenstoegang, API-eindpunten en integratieadapters. Pakketafhankelijkheden stromen in één richting.

Anti-patronen

Waar te zoeken	Hoe slecht eruitziet
Triggers	⚠️ Alle bedrijfslogica rechtstreeks ingebed in triggerbestanden met diep geneste voorwaarden, geen scheiding van zorgen, geen handlerklassen. Meer dan 300 regeltriggerbestanden die validatie, bedrijfslogica en integratieaanroepen combineren. Onmogelijk om effectief te testen.
Query in lus	⚠️ SOQL-query’s uitgevoerd binnen herhalingslussen. Werkt met kleine gegevensvolumes, maar schendt de limiet van 100 SOQL-query’s bij het verwerken van bulkbewerkingen. Wordt alleen ontdekt wanneer via triggers brand wordt veroorzaakt bij het laden van bulkgegevens in productie.
DML in lus	⚠️ DML-instructies (invoegen, bijwerken, verwijderen) uitgevoerd binnen herhalingslussen. Schendt 150 DML-instructielimiet met bulkbewerkingen. Elke record wordt verwerkt in afzonderlijke databasetransacties in plaats van efficiënte bulkverwerking.

Patronen

Waar te zoeken	Hoe goed eruitziet
Records voor beslissingen over architectuur	✅ Belangrijke architectonische beslissingen gedocumenteerd in ADR’s opgeslagen in versiebeheer. Bijwerkingen leggen de context vast (bedrijfsfactoren, technische beperkingen), de beslissing (wat is gekozen), de alternatieven (waarom zijn ze afgewezen) en de gevolgen (afwegingen, voorwaarden voor hernieuwd bezoek).