Salesforce Development Best Practises

1. Apex Development Best Practices
http://bit.ly/sf1-dev-bp
Sebastian Wagner, @tquiladotcom, Technical Architect
@seb__wagner

2. “I cannot teach anybody anything,
I can only make them think”
Socrates

3. Agenda
 Principles
 Process
 Development
– Conventions
– Queries
– Loops
– Tests
 QA

4. Process
 track requirements
 separate development sandboxes
 use source control (git, Mercury, SVN)
 automate deployment with CI
 iterate

5. 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?

6. 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

7. 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

8. 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

9. 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

10. DEV – Error Handling
Exceptions and errors are managed using
exception 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

11. DEV – Error Handling
 insert Account Deactivation Handler
 https://gist.github.com/sebwagner/5e556d492fa2cc010d
c9

12. 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)

13. Query - Conditions

14. 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

15. Query – Efficiency

16. 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()

17. Loops - Limits

18. 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

19. Testing – Code Coverage ‘Alternative’

20. 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

21. Testing – Test Data

22. Testing – Test Data

23. 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);

24. Testing - Assertions

25. 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

26. Testing - Scenarios

27. Testing – Bulk Tests
Code should be bulkified, so should be the tests
 ensures you don’t hit governor limits
 can uncover performance bottlenecks

28. Testing – Bulk Tests

29. Thank you
http://bit.ly/sf1-dev-bp
Sebastian Wagner, @tquiladotcom, Technical Architect
@seb__wagner