Code Quality Patterns

Learn more about Well-Architected Resource and Cost Optimization → Code Organization

This consolidated pattern page covers code quality and maintainability practices for Resource Optimization. It includes guidance on standard vs custom code decisions, technical debt management, design standards, documentation practices, and governance. These patterns help maintain development velocity, reduce defect rates, and enable long-term solution sustainability.

Patterns

Where to look	What good looks like
Performance at scale	✅ Testing validates that declarative solutions meet performance requirements at projected data volumes. Load testing in Full Copy Sandbox with realistic data confirms scalability before production deployment.
Maintainability analysis	✅ TCO analysis compares long-term maintenance burden of declarative vs custom approaches including upgrade effort, testing requirements, and skill requirements for future teams.
Mixed approach architecture	✅ Solutions combine declarative and programmatic approaches where appropriate. Flow orchestrates high-level logic while Apex handles complex calculations. Formula fields compute simple derivations while Apex processes bulk operations.
AppExchange evaluation	✅ Before building custom code, evaluate existing AppExchange packages providing similar functionality. Document evaluation results including packages reviewed, capability gaps, and TCO comparison.

Patterns

Where to look	What good looks like
Backlog visibility	✅ Technical debt items tracked in backlog with clear labels, context explaining why code needs improvement, business impact of leaving it unaddressed, and estimated remediation effort. Invisible debt cannot be prioritized or managed.
Incremental improvement	✅ Boy scout rule applied during feature development: leave code better than found. Teams remediate debt incrementally during related feature work rather than requiring large dedicated refactoring projects. Code reviews verify incremental improvements.
Prevention over remediation	✅ Quality gates in CI/CD enforce standards before code reaches production. Code Scanner, ApexGuru, and complexity metrics integrated into pull request validation. Blocking issues prevent merge until resolved.

Anti-Patterns

Where to look	What bad looks like
Backlog management	⚠️ Technical debt acknowledged verbally but never tracked in backlog. No visibility into debt accumulation. Debt remediation always deferred in favor of feature work. Velocity gradually declines, teams cannot explain why.
Quality gate bypass	⚠️ CI/CD quality gates frequently bypassed under schedule pressure with intention to fix later. "Later" never happens. Code Scanner failures marked as known issues and ignored. Complexity thresholds raised to accommodate poor implementations.
No remediation capacity	⚠️ 100% of sprint capacity allocated to feature work with zero capacity for technical debt remediation. Debt accumulates indefinitely. Major refactoring projects required every 18-24 months consuming entire quarters.
Configuration debt	⚠️ Custom metadata types and custom settings accumulate without cleanup. Unused configuration persists indefinitely. Production has 50 metadata records, only 12 are actually used. No documentation explaining purpose of configuration values.

Patterns

Where to look	What good looks like
Trigger architecture	✅ Trigger handler pattern applied consistently: thin triggers delegate to handler classes, handler classes organize logic by trigger context (before insert, after update), clear method names reveal purpose. No business logic in trigger files themselves.
Service layer implementation	✅ Business logic encapsulated in service classes separate from controllers, triggers, and batch entry points. Service classes reusable across multiple entry points without duplication. Clear naming convention (AccountService, OrderProcessor).
Selector pattern	✅ SOQL queries centralized in selector classes per object (AccountSelector, OpportunitySelector). Selector methods return consistent field sets. LDV optimization changes applied once, affecting all queries.
Repository pattern	✅ Data access abstracted behind interfaces enabling testing with mock data sources. Repository implementations encapsulate query construction, caching, and optimization strategies. Business logic depends on repository interfaces, not concrete implementations.
Component design standards	✅ Lightning Web Components follow single responsibility principle, expose properties for configuration, emit events for parent communication, designed for composition and reuse. Component library documented with usage examples.
Code organization	✅ Logical package structure groups related classes. Clear separation between domain logic, data access, API endpoints, and integration adapters. Package dependencies flow in one direction.

Anti-Patterns

Where to look	What bad looks like
Triggers	⚠️ All business logic embedded directly in trigger files with deeply nested conditionals, no separation of concerns, no handler classes. 300+ line trigger files mixing validation, business logic, and integration calls. Impossible to test effectively.
Query in loop	⚠️ SOQL queries executed within iteration loops. Works with small data volumes but violates 100 SOQL query limit when processing bulk operations. Discovered only when triggers fire on bulk data loads in production.
DML in loop	⚠️ DML statements (insert, update, delete) executed within iteration loops. Violates 150 DML statement limit with bulk operations. Each record processes in separate database transaction rather than efficient bulk processing.

Patterns

Where to look	What good looks like
Architecture Decision Records	✅ Significant architectural decisions documented in ADRs stored in version control. ADRs capture context (business drivers, technical constraints), decision (what was chosen), alternatives considered (why they were rejected), and consequences (trade-offs, conditions for revisiting).