sf1 - apex development best practises

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