Operational Excellence - DevOps-patronen
Lees meer over EPS Kisten van 75 x 70cm (60 x 80 cm) → DevOps Practices
Patronen
| Waar te zoeken | Hoe goed eruitziet |
|---|---|
| Set-up van Versiebeheer | ✅ Alle metagegevens opgeslagen in Git-bronindeling met behulp van Salesforce DX projectstructuur met .forceignore geconfigureerd om irrelevante bestanden uit te sluiten; alle teamleden klonen vanuit centrale opslagplaats |
| Gebruik van scratch-organisaties | ✅ Ontwikkelaars maken kortstondige scratch-organisaties vanuit de bron voor voorzieningenwerk, voeren wijzigingen terug naar versiebeheer en negeren scratch-organisaties na voltooiing van voorzieningen |
| Berichten vastleggen | ✅ Elke commit bevat een duidelijk, beknopt bericht waarin wordt uitgelegd wat er is gewijzigd en waarom; berichten volgen de teamconventie (bijv. “feat:”, “fix:”, “docs:“) |
| Bijhouden van wijzigingen | ✅ Elke metagegevens wijziging vastgelegd in versiebeheer met auteur identiteit, tijdstempel en diff tonen exacte wijzigingen |
| Codebeoordelingsproces | ✅ Alle productiegebonden wijzigingen stromen door pullverzoeken die goedkeuring van beoordeling vereisen vóór samenvoegen; declaratieve configuratie ontvangt dezelfde controle als code |
| Terugdraaiprocedures | ✅ Vorige versies herstelbaar vanuit Git-historie via Checkout of terugzetten bewerkingen; team heeft gedocumenteerd rollback procedures getest in niet-productie |
| Controletraject | ✅ Volledige wijzigingshistorie behouden in versiebeheer ter ondersteuning van nalevingsvereisten en beveiligingsonderzoeken |
| Vertakkingsstrategie | ✅ Consistent Git-vertakkingsmodel (GitFlow, GitHub-stroom of trunkgebaseerd) geschikt voor teamgrootte en releasefrequentie; gedocumenteerd en afgedwongen |
| Migratie vanuit organisatie | ✅ Transitie naar brongestuurde ontwikkeling voltooid vroeg in de levenscyclus van de oplossing voordat gewoonten verharden rond op organisatie gebaseerde ontwikkeling |
| .gitignore-configuratie | ✅ Opslagplaats sluit gegenereerde bestanden, gebruikersspecifieke instellingen en inloggegevens uit; omvat alleen bronbestanden die teams van plan zijn te versieren |
Anti-patronen
| Waar te zoeken | Hoe slecht eruitziet |
|---|---|
| Organisatie als bron van waarheid | ⚠️ Ontwikkeling vindt rechtstreeks plaats in gedeelde sandboxen met metagegevens die naar versiebeheer zijn geëxporteerd, zoals achteraf gedacht; organisaties en versiebeheer lopen uiteen, waardoor implementatiefouten ontstaan |
| Onvoldoende .gitignore | ⚠️ Repository omvat gegenereerde bestanden, gebruikersspecifieke instellingen, grote binaire bestanden of inloggegevens; bloats repository en risico’s van blootstelling aan beveiliging |
| Vage verbintenisberichten | ⚠️ Beloften zoals “fix bug” of “updates” bieden geen context voor wat er is gewijzigd of waarom; belemmert auditonderzoeken en toekomstig onderhoud |
| Grote onregelmatige verplichtingen | ⚠️ Ontwikkelaars commit grote wijzigingensets wekelijks in plaats van kleine incrementele commits meerdere malen per dag; moeilijk te beoordelen, moeilijk te isoleren mislukkingen |
| Direct naar hoofdpagina binden | ⚠️ Ontwikkelaars pushen wijzigingen rechtstreeks naar de hoofd-/productietak door beoordeling en validatie te omzeilen; elimineert kwaliteitspoorten |
| Geen vertakkingsstrategie | ⚠️ Team mist consistent vertakkingsmodel; ontwikkelaars maken willekeurige vertakkingsnamen en samenvoegpatronen; creëert verwarring en samenvoegconflicten |
| Binaire bestanden in Git | ⚠️ Grote binaire bestanden (PDF-bestanden, video’s, archieven) die zijn toegewezen aan Git-opgeblazen opslagplaatsgrootte en vertragende kloonbewerkingen |
| Inloggegevens vastleggen | ⚠️ API-sleutels, wachtwoorden, integratiegegevens of beveiligingstokens die zijn vastgelegd voor versiebeheer; creëert beveiligingskwetsbaarheid, zelfs na verwijdering uit latere vastleggingen |
| Samenvoegingsconflicten negeren | ⚠️ Samenvoegingsconflicten opgelost door één kant te accepteren zonder analyse; verliest wijzigingen of introduceert bugs |
| Geen verbintenisverificatie | ⚠️ Team verifieert nooit of vastgelegde metagegevens daadwerkelijk beoogde wijzigingen vertegenwoordigen; fouten in de metagegevensindeling of onbedoelde wijzigingen glippen door |
Patronen
| Waar te zoeken | Hoe goed eruitziet |
|---|---|
| Ontwikkelaarsssandboxen | ✅ Individuele ontwikkelaars gebruiken Developer sandboxen voor functie werk, eenheid testen en snelle herhaling; elke ontwikkelaar heeft een speciale omgeving |
| Developer Pro Sandboxen | ✅ Teams die beheerde pakketten ontwikkelen of hogere opslaglimieten vereisen, gebruiken Developer Pro-sandboxen voor samenwerkingswerk |
| Partial Copy Sandboxen | ✅ Integratietests gebruiken Partial Copy-sandboxen met representatieve gegevensvoorbeelden (10.000 records per object) die zijn geconfigureerd via gegevenssjablonen |
| Full Copy Sandboxen | ✅ Prestaties testen, productie-achtige fasering en validatie van gegevensmigratie gebruiken Full Copy sandboxen met volledige productiegegevens en configuratie |
| Besturingselementen voor gegevensgevoeligheid | ✅ Full Copy sandboxtoegang beperkt tot rollen die productiegegevens vereisen; Shield Platform Encryption gegevensmaskering toegepast voor niet-productiegebruik indien van toepassing |
| Integratie-eindpuntconfiguratie | ✅ Elke sandboxlaag verbindt met overeenkomende testeindpunten voor externe integraties; productie-integraties verbinden nooit vanuit sandboxen |
| Omgevingsspecifieke configuratie | ✅ Integratiearchitectuur gebruikt aangepaste metagegevenstypen of aangepaste instellingen om eindpunt-URL’s, inloggegevens en functievlaggen per omgeving te externaliseren |
| Automatisering na vernieuwen | ✅ Sandboxvernieuwingen activeren geautomatiseerde Salesforce CLI scripts die sandboxspecifieke instellingen herstellen, waaronder integratiegegevens, seeding van testgegevens, vlaggenstatussen van voorzieningen en e-mailbestelbaarheid |
| Planning vernieuwen | ✅ Sandbox vernieuwingsschema gedocumenteerd en gecommuniceerd; vernieuwingen gepland tijdens perioden met weinig activiteit om teamonderbreking te minimaliseren |
| Gegevenssjablonen | ✅ Partial Copy-sandboxen gebruiken goed ontworpen gegevenssjablonen die representatieve gegevens selecteren voor alle objecten die verwijzende integriteit behouden |
| Naamgevingsconventies | ✅ Sandboxen volgen duidelijke naamgevingsconventie die doel, eigenaar en vernieuwingscyclus aangeeft (bijv. “dev-integratie-q2”, “uat-release-2-4”) |
Anti-patronen
| Waar te zoeken | Hoe slecht eruitziet |
|---|---|
| Gedeelde ontwikkelingssandbox | ⚠️ Alle ontwikkelaars werken in één gedeelde sandbox die elkaars wijzigingen overschrijft; schept verwarring over wat de implementeerbare status is |
| Stale-sandboxen | ⚠️ Sandboxen die maandenlang niet zijn vernieuwd en aanzienlijk afwijken van de productieconfiguratie; testen in een niet-representatieve omgeving leidt tot implementatiefouten |
| Geen Data Governance in Full Copy | ⚠️ Full Copy sandboxen met productie-PII, financiële gegevens, HIPAA-gegevens die toegankelijk zijn voor het gehele ontwikkelteam zonder toegangscontroles of gegevensmaskering |
| Productie-integraties vanuit sandbox | ⚠️ Sandboxen worden rechtstreeks verbonden met productie-integratie-eindpunten waardoor het risico ontstaat dat testtransacties van invloed zijn op productiegegevens of externe systemen |
| Handmatige configuratie na vernieuwen | ⚠️ Sandboxvernieuwingen vereisen uren van handmatige instellingen voor opnieuw configureren herstellen; overhead ontmoedigt het vernieuwen van sandboxen zo vaak als nodig |
| Geen sandboxdocumentatie | ⚠️ Team mist documentatie over sandboxdoeleinden, vernieuwingsschema’s, gegevensinhoud of toegangsprocedures; ontwikkelaars raden welke omgeving voor welk doel moet worden gebruikt |
| Type enkelvoudige omgeving | ⚠️ Team gebruikt slechts één sandboxtype (doorgaans Developer of Full Copy) voor alle doeleinden; mist voordelen van de juiste sandboxstrategie per activiteit |
| Sandbox-hamsteren | ⚠️ Sandboxen toegewezen aan individuen of projecten en nooit vrijgegeven wanneer niet langer nodig; kunstmatige schaarste ondanks beschikbare licenties |
| Onvoldoende testgegevens | ⚠️ Testgegevens in sandboxen vertegenwoordigen geen productiegegevenskenmerken (volumes, relaties, randcases); testen in een onrealistische omgeving mist productieproblemen |
Patronen
| Waar te zoeken | Hoe goed eruitziet |
|---|---|
| Bronverbintenisfase | ✅ Ontwikkelaars wijzigingen aanbrengen in functievertakkingen in Git met duidelijke commit-berichten die context en reden uitleggen |
| Statische analysefase | ✅ Salesforce Code Analyzer scant Apex op beveiligingskwetsbaarheden (OWASP Top 10), prestatie-anti-patronen (SOQL in lussen, DML in lussen), codekwaliteitsproblemen (complexiteit, duplicatie) en beheerlimietrisico’s; wordt uitgevoerd in seconden en biedt onmiddellijke feedback |
| Testfase eenheid | ✅ Apex tests voeren validerende bedrijfslogica en naleving van beheerlimieten uit in een kortstondige scratch-organisatie of speciale integratiesandbox; goed geïsoleerde tests worden in minder dan 5 minuten voltooid |
| Implementatiefase van validatie | ✅ Metagegevens worden geïmplementeerd naar de integratiesandbox met behulp van Salesforce CLI met –checkonly vlag voor validatie-only implementatie uitvoeren van tests zonder het uitvoeren van wijzigingen |
| Integratietestfase | ✅ Geautomatiseerde tests valideren werkstromen met meerdere componenten, externe integratiecontracten, platformeventstromen en asynchrone verwerkingsketens op basis van gedeelde integratieomgeving met testgegevensbeheer |
| Scanfase van beveiliging | ✅ Extra beveiligingstools scannen op hard-coded inloggegevens, kwetsbare afhankelijkheden, CRUD / FLS-schendingen en nalevingsbeleidsschendingen; kritieke bevindingen break builds |
| UAT-implementatiefase | ✅ Wijzigingen die alle geautomatiseerde poorten passeren, worden geïmplementeerd in de gebruikersacceptatietestomgeving voor bedrijfsvalidatie; implementatie kan geautomatiseerd zijn of handmatige goedkeuring vereisen op basis van het veranderingsrisico |
| Productie-implementatiefase | ✅ Na UAT-goedkeuring worden wijzigingen geïmplementeerd naar productie met geautomatiseerde uitvoering met één klik, uitgebreide vastlegging en onmiddellijke terugdraaimogelijkheid |
| Uitvoeringstijd van pijplijn | ✅ End-to-end pijplijn is voltooid in minder dan 15 minuten voor typische wijzigingen waardoor snelle feedback mogelijk is; langer voor grote implementaties of uitgebreide testreeksen |
| Artefacten samenstellen | ✅ Pijplijn bewaart implementatiepakketten, testresultaten, beveiligingsscanrapporten en uitvoeringslogboeken voor naleving en probleemoplossing |
| Pijplijntooling | ✅ Teams gebruiken Salesforce DevOps Center voor platform-native CI / CD, of integreren met externe platforms (GitHub-acties, GitLab CI, Azure DevOps, CircleCI, Jenkins, Copado, Gearset, AutoRABIT) |
| Meldingen van storingen | ✅ Pijplijnfouten activeren kennisgevingen om auteur en relevante kanalen te binden met diagnostische context die snelle herstel mogelijk maakt |
| Filiaalbescherming | ✅ Hoofd-/productiefilialen beschermd die CI-controles en goedgekeurde beoordelingen vereisen vóór samenvoegen; directe verbintenissen voorkomen |
| Milieubevordering | ✅ Wijzigingen stromen door middel van gedefinieerde promotie pad (dev → integratie → UAT → productie) met validatie in elke fase |
Anti-patronen
| Waar te zoeken | Hoe slecht eruitziet |
|---|---|
| Handmatige implementaties | ⚠️ Wijzigingen handmatig geïmplementeerd via wijzigingssets of Salesforce CLI opdrachten met inconsistente stappen; menselijke fouten, gemiste stappen, gebrek aan controletraject |
| Geen statische analyse | ⚠️ Pijplijnen slaan Salesforce Code Analyzer of soortgelijke tools over; beveiligingskwetsbaarheden, anti-patronen voor prestaties, codekwaliteitsproblemen bereiken productie |
| Onvoldoende testen | ⚠️ Pijplijn valideert alleen minimaal 75% dekking zonder integratietests uit te voeren of belangrijke gebruikersstromen te valideren; regressies glippen door |
| Geen beveiligingsscannen | ⚠️ Pijplijnen scannen nooit op hard-coded inloggegevens, kwetsbare afhankelijkheden of CRUD / FLS-schendingen; beveiligingsproblemen ontdekt in productie- of beveiligingsbeoordelingen |
| Trage uitvoering van pijplijn | ⚠️ End-to-end pijplijn duurt 45-60+ minuten, waardoor frequente commits en vertragende feedbacklussen worden ontmoedigd; ontwikkelaars committen minder vaak en verzamelen grotere wijzigingen |
| Mislukte pijplijn | ⚠️ Teams negeren of overschrijven pijplijnfouten om deadlines te halen; kwaliteitspoorten worden theater in plaats van feitelijke controles |
| Geen testomgevingspariteit | ⚠️ CI/CD valideert in een omgeving met andere configuratie, limieten of gegevenskenmerken dan productie; het doorgeven van validatie garandeert geen succes bij de productie |
| Ontbrekende terugdraaimogelijkheid | ⚠️ Pijplijn automatiseert implementatie, maar biedt geen geautomatiseerde terugdraaiing; herstel van slechte implementatie vereist handmatige noodprocedures |
| Geen implementatielogboeken | ⚠️ Implementaties uitgevoerd zonder uitgebreide logging; fouten opsporen of implementaties controleren wordt moeilijk |
| Alles-of-niets testen | ⚠️ Pijplijn voert alle tests uit voor elke wijziging, ongeacht wat er is gewijzigd; 30-minuten testreeksuitvoeringen, zelfs voor documentatie-updates |
Patronen
| Waar te zoeken | Hoe goed eruitziet |
|---|---|
| Functievlaggen | ✅ Wijzigingen met hoog risico worden geïmplementeerd met voorzieningen uitgeschakeld achter het type aangepaste metagegevens of configuratie van aangepaste instellingen; maakt testen in productie mogelijk zonder blootstelling van de gebruiker, geleidelijke implementatie naar segmenten, A / B-testen en onmiddellijke terugdraaiing via configuratiewijziging |
| Bereik van voorzieningenvlag | ✅ Functievlaggen gereserveerd voor wijzigingen met hoog risico die van invloed zijn op kritieke bedrijfsprocessen, prestatiegevoelige bewerkingen of nieuwe integratiepatronen; niet elke voorziening heeft vlaggen nodig |
| Canary-implementaties | ✅ Bedrijfskritieke wijzigingen eerst vrijgeven aan kleine gebruikerssubset (5-10% via machtigingensets of filtering van gebruikerskenmerken); kanariecohort intensief bewaakt 24-48 uur meten van successcores, prestaties, foutscores voordat implementatie wordt uitgebreid |
| Implementatievensters | ✅ Implementaties die zijn gepland tijdens perioden met weinig gebruik, geïnformeerd door Event Monitoring API-gebruikslogboeken die feitelijke verkeerspatronen tonen; vermijdt piekgebruik, maandeinde sluiten, kwartaaleinde sluiten, belangrijke bedrijfsevents |
| Implementatiecommunicatie | ✅ Belanghebbenden ontvangen vooraf kennisgeving van implementatieperioden, inclusief verwachte duur, betroffen functionaliteit en tijdlijn voor terugdraaien van beslissingen |
| Terugdraaiprocedures | ✅ Gedocumenteerde en geteste rollback procedures voor elk implementatietype; team kan rollback uitvoeren in minder dan 30 minuten indien nodig |
| Terugdraaitesten | ✅ Terugdraaiprocedures gevalideerd in niet-productieomgeving vóór significante implementaties die zorgen voor herstelmogelijkheden |
| Implementatievalidatie | ✅ Rooktests na de implementatie valideren kritieke gebruikersstromen, integratie-eindpunten en belangrijke functionaliteit onmiddellijk na de release |
| Coördinatie wijzigen | ✅ Gecoördineerde implementatiestrategie wanneer wijzigingen meerdere systemen bestrijken of gesynchroniseerde releases vereisen voor Salesforce en externe platforms |
| Bewaking tijdens implementatie | ✅ Uitgebreide bewaking actief tijdens de implementatieperiode en de observatieperiode na de implementatie (24-48 uur), waarbij wordt gelet op pieken in foutscores, prestatievermindering of stroomfouten van gebruikers |
| Blauwgroen patroon voor integraties | ✅ Externe services die Salesforce fronten, gebruiken blauwgroene implementaties met behoud van twee productieachtige omgevingen, eerst implementeren naar inactief, verkeer overschakelen na validatie |
Anti-patronen
| Waar te zoeken | Hoe slecht eruitziet |
|---|---|
| Big Bang-implementaties | ⚠️ Grote releases met veel voorzieningen, refactoren en wijzigingen tegelijkertijd geïmplementeerd zonder geleidelijke implementatie; mislukking beïnvloedt alle gebruikers onmiddellijk |
| Implementaties van piekuren | ⚠️ Releases gepland tijdens piek kantooruren (middag, maand-end, kwartaal-end) wanneer het gebruik het hoogst is en de impact van problemen op de gebruiker gemaximaliseerd |
| Geen terugdraaiplan | ⚠️ Implementaties gaan door zonder gedocumenteerde en geteste terugdraaiprocedures; wanneer er problemen optreden, verschuift het team om herstel te achterhalen |
| Functie aan-/uit als achteraf bedacht | ⚠️ Functievlaggen die reactief worden toegevoegd wanneer problemen optreden, in plaats van proactief te worden ontworpen voor wijzigingen met hoog risico; beperkt terugdraaiopties tot volledige implementatieomkering |
| Geen implementatievalidatie | ⚠️ Wijzigingen geïmplementeerd naar productie zonder rooktests na de implementatie; team gaat ervan uit dat implementatie is geslaagd en gaat verder; problemen die uren later door gebruikers worden ontdekt |
| Niet-geteste terugdraaiprocedures | ⚠️ Terugdraaiprocedures gedocumenteerd maar nooit getest in niet-productie; tijdens het feitelijke incident mislukt de procedure of blijkt deze ontoereikend |
| Gelijktijdige wijzigingen in meerdere systemen | ⚠️ Gecoördineerde wijzigingen binnen Salesforce en externe systemen die zijn geïmplementeerd zonder synchronisatie of compatibiliteitstests; leidt tot integratiefouten |
| Geen bewakingsverbetering | ⚠️ Implementaties verlopen zonder uitgebreide bewaking tijdens implementatieperiode; problemen gedetecteerd door klachten van gebruikers in plaats van proactieve waarschuwingen |
| Weekendimplementaties | ⚠️ Belangrijke releases die vrijdagavond of in het weekend worden geïmplementeerd wanneer de dekking op afroep wordt verminderd en de beschikbaarheid van leveranciersondersteuning beperkt is |
Patronen
| Waar te zoeken | Hoe goed eruitziet |
|---|---|
| Dekking van eenheidstest | ✅ Betekenisvolle testdekking validerende bedrijfsregels, randcases, foutpaden en beheerlimietbenadering; overschrijdt aanzienlijk 75% minimumvereiste |
| Kwaliteit van eenheidstest | ✅ Tests valideren bedrijfslogica, niet platformfunctionaliteit; goed geschreven eenheidstests zijn snel (milliseconden), geïsoleerd (geen gedeelde status) en gericht (elke test valideert één gedrag) |
| Gegevensstrategie testen | ✅ Tests gebruiken @TestSetup methoden voor gemeenschappelijke testgegevens; vermijd SOQL-query’s in tests waar mogelijk; gebruik Test.loadData () voor het laden van statische resources |
| Externe afhankelijkheden bespotten | ✅ Unit tests mock externe aanroepen met behulp van test stubs en afhankelijkheid injectie waardoor snelle uitvoering zonder feitelijke HTTP-verzoeken |
| Integratietests | ✅ Valideer interacties tussen triggers, stromen, platformevents, batchtaken en externe aanroepen die in sandboxen worden uitgevoerd met representatieve testgegevens |
| Betrouwbaarheid van integratietest | ✅ Integratietests zijn herhaalbaar en deterministisch; sporadische fouten die worden aangepakt door middel van synchronisatiemechanismen zoals platform event replay ID’s en batch taak polling |
| End-to-end tests | ✅ Geautomatiseerde browser testen (Selenium, Playwright, Provar) valideert volledige user journeys voor bedrijfskritieke stromen uit te oefenen systeem via UI precies zoals gebruikers interactie |
| E2E-testfocus | ✅ E2E-tests richten zich op gebruikerstrajecten met de hoogste waarde vanwege de tragere uitvoering (minuten per test) en de hogere onderhoudslast van UI-wijzigingen |
| Testen laden | ✅ Prestaties gevalideerd onder realistische gelijktijdige gebruikersbelastingen en gegevensvolumes met behulp van Salesforce Load Testing-services of externe tools; onthult problemen met beheerlimieten, vergrendelingsbetwisting, prestatievermindering |
| Testfrequentie laden | ✅ Ladingstests worden uitgevoerd vóór belangrijke releases en periodiek (kwartaal) om prestaties te valideren bij 3 x - 5x huidige productievolumes |
| Testpiramide | ✅ Gebalanceerde testverdeling: veel eenheidstests (honderden, minuten), minder integratietests (tientallen, minuten), weinig E2E-tests (minder dan 20, minuten); snelle feedback aan de basis, uitgebreide validatie bovenaan |
| Testisolatie | ✅ Tests zijn niet afhankelijk van elkaar; kan worden uitgevoerd in een willekeurige volgorde; elke test laat het systeem in schone toestand of gebruikt @TestSetup voor consistent uitgangspunt |
| Negatieve testcases | ✅ Tests valideren foutafhandeling, validatieregelafdwinging, machtigingsafdwinging en gracieuze degradatie onder ongunstige omstandigheden |
| Controlelimiet testen | ✅ Tests valideren specifiek gedrag dat beheerlimieten benadert, waaronder SOQL-querylimieten, DML-limieten, CPU-tijd, heapgrootte |
| Continue testuitvoering | ✅ Tests worden automatisch uitgevoerd op elke commit via CI / CD-pijplijn; falende tests voorkomen implementatie naar hogere omgevingen |
Anti-patronen
| Waar te zoeken | Hoe slecht eruitziet |
|---|---|
| Testen voor dekking | ⚠️ Tests die uitsluitend zijn geschreven om een minimale dekking van 75% te bereiken zonder bedrijfsregels of randcases te valideren; tests die niets zeggen of triviale codepaden testen |
| Platformfunctionaliteit testen | ⚠️ Tests valideren dat Salesforce werk van records of SOQL-query’s opslaat in plaats van bedrijfslogica te valideren; verspilt moeite aan platformgaranties |
| Geen nepstrategie | ⚠️ Eenheidstests doen feitelijke aanroepen naar externe systemen; tests zijn traag, bros voor de beschikbaarheid van externe systemen en verbruiken API-limieten |
| Sporadische testfouten | ⚠️ Tests slagen of mislukken onvoorspelbaar op basis van uitvoeringstiming, gegevensstatus of uitvoeringsvolgorde van test; teams leren mislukkingen te negeren en opnieuw uit te voeren totdat tests slagen |
| Geen integratietests | ⚠️ Er bestaan alleen eenheidstests; het team valideert nooit dat triggers, stromen, platformevents en batchtaken correct samenwerken |
| Alleen handmatig E2E-testen | ⚠️ Kritieke gebruikersstromen handmatig gevalideerd vóór elke release; geen geautomatiseerde E2E-tests; regressies ontdekt in productie wanneer handmatig testen scenario’s mist |
| Testen zonder belasting | ⚠️ Prestaties nooit gevalideerd onder realistische gelijktijdige belastingen; problemen met beheerlimieten, vergrendelingsbetwisting of prestatievermindering ontdekt in productie |
| Afhankelijkheden van testgegevens | ⚠️ Tests zijn afhankelijk van specifieke records die bestaan in de organisatie of veronderstellen een bepaalde gebruikersconfiguratie; pauze wanneer sandbox wordt vernieuwd of configuratie wordt gewijzigd |
| Geen negatieve testcases | ⚠️ Tests valideren alleen happy path scenario’s; test nooit foutafhandeling, validatie afdwingen of machtigingscontroles; foutmodi onontdekt |
| Overgeslagen tests | ⚠️ Mislukte tests becommentarieerd vanuit @isTest en overgeslagen in plaats van opgelost; testreeks gaat achteruit naarmate meer tests worden genegeerd |
Patronen
| Waar te zoeken | Hoe goed eruitziet |
|---|---|
| Dekking beoordelen | ✅ Alle productiegebonden wijzigingen stromen door codebeoordeling via pullverzoeken die goedkeuring vereisen vóór samenvoegen; omvat Apex, Aura, LWC, stromen, validatieregels, machtigingensets, regels voor delen |
| Controlelijst voor criteria controleren | ✅ Expliciete controlelijst met betrekking tot beveiliging (CRUD / FLS-afdwinging, invoervalidatie), prestaties (bulkificatie, SOQL-optimalisering), naleving van beheerlimieten (verwerkingspatronen, recursiepreventie), onderhoudbaarheid (naamgeving, documentatie, complexiteit), testdekking (zinvolle tests, randcases), architectonische consistentie (ontwerppatronen, scheiding van zorgen) |
| Groottelimieten controleren | ✅ Pull verzoeken gehouden onder 400 regels van betekenisvolle wijziging waardoor grondige beoordeling; grote functies opgesplitst in kleinere incrementele wijzigingen die afzonderlijk kunnen worden beoordeeld en onafhankelijk implementeerbaar |
| Timing beoordelen | ✅ Beoordelingen voltooid binnen één werkdag behoud van ontwikkeling momentum en het geven van snelle feedback; vertraagde beoordelingen creëren context switching overhead |
| Geautomatiseerde controles vooraf | ✅ Statische analyse, eenheidstests en beveiligingsscans worden automatisch uitgevoerd voordat menselijke beoordeling wordt aangevraagd; geautomatiseerde controles vangen mechanische problemen op, zodat beoordelaars zich richten op ontwerp en bedrijfslogica |
| Gedistribueerde beoordelingsverantwoordelijkheid | ✅ Code review verantwoordelijkheid verdeeld over het team voorkomen van bottlenecks en het delen van Knowledge; junior ontwikkelaars beoordelen senior code en verklaren hun eigen code tijdens beoordelingen |
| Kwaliteit van opmerkingen beoordelen | ✅ Reviewers geven specifieke, navolgbare feedback met een motivering; maak onderscheid tussen vereiste wijzigingen (blokkeringsproblemen) en suggesties (leuke verbeteringen) |
| Documentatie beoordelen | ✅ Pullverzoekbeschrijvingen leggen uit wat er is gewijzigd, waarom het is gewijzigd, welke tests zijn uitgevoerd en eventuele speciale overwegingen bij implementatie of terugdraaiprocedures |
| Beoordeling van declaratieve configuratie | ✅ Stromen, validatieregels en machtigingswijzigingen krijgen dezelfde beoordelingsstrengheid als code; configuratie is architecturaal en verdient controle |
| Follow-up van opmerkingen | ✅ Alle opmerkingen van de beoordeling behandeld vóór merge; vragen beantwoord, wijzigingen geïmplementeerd, of motivering opgegeven voor waarom suggestie niet overgenomen |
Anti-patronen
| Waar te zoeken | Hoe slecht eruitziet |
|---|---|
| Geen codebeoordeling | ⚠️ Wijzigingen die rechtstreeks naar de productievestiging worden doorgevoerd zonder peer review; elimineert het primaire defectdetectiemechanisme |
| Rubber stempelen | ⚠️ Beoordelaars keuren pullverzoeken binnen enkele seconden goed zonder wijzigingen daadwerkelijk te onderzoeken; beoordeling wordt naleving van selectievakjes in plaats van kwaliteitspoort |
| Knelpunt voor enkelvoudige beoordelaar | ⚠️ Slechts één senior ontwikkelaar gemachtigd om code te beoordelen; creëert bottleneck en single point of failure; Knowledge geconcentreerd in plaats van gedistribueerd |
| Massale pullverzoeken | ⚠️ Pullverzoeken met duizenden regels wijzigingen over meerdere voorzieningen; onmogelijk om grondig te beoordelen, wat leidt tot oppervlakkig onderzoek |
| Vertraagde beoordelingen | ⚠️ Pullverzoeken zitten dagen of weken niet beoordeeld; ontwikkelaars verliezen context en gaan naar ander werk; opmerkingen over beoordelingen komen wanneer de ontwikkelaar van mentale context is veranderd |
| Geen beoordelingscriteria | ⚠️ Team mist expliciete criteria voor wat beoordelaars moeten onderzoeken; beoordelingskwaliteit varieert sterk per beoordelaar; sommige beoordelaars richten zich op stijl, anderen op logica, geen uitgebreid |
| Beoordelen zonder testen | ⚠️ Beoordelaars keuren wijzigingen alleen op basis van code-inspectie goed zonder vertakkingen te trekken en lokaal te testen of geautomatiseerde tests te valideren |
| Genegeerde geautomatiseerde controles | ⚠️ Beoordelaars keuren pullverzoeken goed ondanks mislukte statische analyse, beveiligingsscans of eenheidstests; verslaat doel van geautomatiseerde kwaliteitspoorten |
| Vijandige beoordelingscultuur | ⚠️ Beoordelingen worden persoonlijke kritiek of competitieve oefening in plaats van kwaliteitsverbetering door samenwerking; ontmoedigt leren en psychologische veiligheid |
| Geen declaratieve beoordeling | ⚠️ Stromen, validatieregels, machtigingensets en regels voor delen worden zonder beoordeling geïmplementeerd terwijl Apex code wordt gecontroleerd; creëert kwaliteitshiaat in de declaratieve configuratie |