Apex Development Best Practiceshttp://bit.ly/sf1-dev-bp
Sebastian Wagner, @tquiladotcom, Technical Architect@seb__wagner
“I cannot teach anybody anything,I can only make them think”
Socrates
Agenda
Principles Process Development
– Conventions– Queries– Loops– Tests
QA
Process
track requirements separate development sandboxes use source control (git, Mercury, SVN) automate deployment with CI iterate
Requirements
Understand– What is expected?– Why, what are the drivers?
Think– How to implement?– Impact, Dependencies
Challenge– Can it be flexed, to match platform features?
Platform Advantages
Config over Code– workflows instead of triggers– Page Layout vs. Visualforce
Native over Custom– standard instead of custom objects– re-label field
Install/Deploy over Build– AppExchange– Github
XP Principles
MVP - Minimum Viable Product (80/20 rule)– focus on the core features
KISS - Keep It Simple & Stupid– the simplest solution to meet the requirement– easy to use, read and change. looks simple
DRY – Don’t Repeat Yourself– Components, Labels, Templates, Abstraction, Service
Classes YAGNI – You Arent Gonna Need It
– implement only WHEN you actually need it– avoid over-engineering
DEV – Structure
The structure of code and config is clear and understandable
be consistent use a naming convention self describing names declare constants and literal values in variable or
config
DEV – Comments
Loops and more complex parts of the algorithms are clear and commented
clear code (what) over comments (why) provide context and help understanding describe purpose of classes and methods do NOT comment trivial code
DEV – Error Handling
Exceptions and errors are managed usingexception handling
catch in user facing code (e.g. in trigger or controller)
provide useful description if necessary descriptive error messages do NOT catch exceptions in service methods,
unless you return your own error object
DEV – Error Handling
insert Account Deactivation Handler
https://gist.github.com/sebwagner/5e556d492fa2cc010dc9
Query - Conditions
All SOQL queries are appropriately restricted by a WHERE clause or a LIMIT parameter
filter records by SOQL rather than code use of indexes (Id, Text, Number) whenever
possible follows best practices for Query Optimizer (e.g.
avoid to filter on NULL)
Query - Conditions
Query – Efficiency
Efficient use of queries for good performance
cache records for re-use in context avoid querying the same object multiple times exclude fields that are not needed lazy load Blob and Large Text fields
Query – Efficiency
Loops - Limits
Beware of the Governor Limits
loops (for, do-while) do NOT invoke– SOSL/SOQL statements– DML statements
method calls which use limits are not invoked in loops where avoidable e.g. Describes, Callouts, sendEmail()
Loops - Limits
Testing – Code Coverage
Code coverage is no lower than 90%. yet it is not everything, but
high coverage => less bugs => less frustration keep testability in mind when writing code,
because if you can’t test it, it's an indicator for Code Smell
Testing – Code Coverage ‘Alternative’
Testing – Test Data
Tests setup their own test data@isTest(seeAllData=false)
do NOT rely on organization data if org data is need, limit to methods use test data classes or methods for re-use
Testing – Test Data
Testing – Test Data
Testing - Assertions
Assertions are used to validate expected results
true testing, validation rather than only execution
+1 assert per test method use the message parameter to provide context
system.assert(Object,Object,message);
Testing - Assertions
Testing - Scenarios
Tests validate positive and negative outcomes
Positive: execution with valid data / params Negative: execution with invalid data / params use system.runAs() to test
– Dynamic Apex – Methods using with sharing or without sharing – Shared records
Testing - Scenarios
Testing – Bulk Tests
Code should be bulkified, so should be the tests
ensures you don’t hit governor limits can uncover performance bottlenecks
Testing – Bulk Tests
Thank youhttp://bit.ly/sf1-dev-bpSebastian Wagner, @tquiladotcom, Technical Architect@seb__wagner