SF1 - Apex Development Best Practises
Download as PPTX, PDF4 likes1,680 views
This document provides best practices for Apex development at Salesforce, covering principles, processes, development conventions, testing, and more. It recommends tracking requirements, using source control, automating deployments, writing efficient code, handling errors properly, writing tests with assertions and different scenarios, and avoiding governor limits. The goal is to produce code that is well-structured, commented when needed, performs efficiently with queries and loops, has high test coverage, uses test data properly, and can be tested at scale.
Ad
More Related Content
What's hot (20)
Viewers also liked (8)
Ad
Similar to SF1 - Apex Development Best Practises (20)
Ad
Recently uploaded (20)
![Get & Download Wondershare Filmora Crack Latest [2025]](https://cdn.slidesharecdn.com/ss_thumbnails/revolutionizingresidentialwi-fi-250422112639-60fb726f-250429170801-59e1b240-thumbnail.jpg?width=560&fit=bounds)
SF1 - Apex 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)
- 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
- 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);
- 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
- 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