Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Salesforce Development Best Practices

17,857 views

Published on

These are the slides from a presentation given to the San Diego Salesforce Developer Group on September 16, 2014.

The presentation highlights why coding standards and design patterns are important parts of creating a scalable, maintainable Salesforce Enterprise Org. A series of specific implementation and architecture recommendations are outlined. Finally, models for process and governance are provided to help the viewer take steps to bring about change in their Org.

Published in: Software

Salesforce Development Best Practices

  1. 1. Salesforce Development Best Practices people Vivek M. Chawla @VivekMChawla September 16, 2014
  2. 2. Introduction 2 Vivek M. Chawla Senior Salesforce Engineer @VivekMChawla
  3. 3. Overview • Why standards, design patterns, and best practices matter • Implementation and Architecture • Process and Governance • Three things you can do TODAY 3
  4. 4. Why Patterns and Best Practices Matter • Efficiency • Security • Quality • Minimize Technical Debt 4
  5. 5. What is “Technical Debt”? “Work that needs to be done before a particular job can be considered complete or proper. If the debt is not repaid, then it will keep on accumulating interest, making it hard to implement changes later on”. In other words… “All the things, big and small, that left undone will eventually come around to bite you in the ass”. 5
  6. 6. Salesforce Technical Debt Accrues FAST • Too many “System Administrators”. • Changing the data model and adding business logic is EASY. • Less institutional knowledge of Salesforce (typically) 6
  7. 7. Salesforce “Gotchas” are Painful Salesforce development takes a lot of effort to do right. • Governor limits can cause pain unexpectedly if not considered early on in the design process. • Deployment is tricky business • Team development is either the Wild West…or Soviet Russia. 7
  8. 8. Specific Recommendations IMPLEMENTATION & ARCHITECTURE 8
  9. 9. Create Standards For… • Coding Style • Documentation • Design Patterns • Naming Conventions 9
  10. 10. Coding Style Apex code should follow a consistent coding style for the following areas. • Whitespace – Always use spaces for indentation. Do not use tabs. • Block Indentation / Column Limit – Indent new blocks with two spaces. – Code within a 100 character column limit. • SOQL Queries – Break SOQL Queries across multiple lines. • Fields named in the SELECT clause appear alone, one per line. - List fields in ascending alphabetical order. • WHERE predicates appear alone, one per line. *See the Google Java Style guide for additional guidance 10
  11. 11. Apex Documentation Use block-formatted (/* */) comments to create Apex code documentation headers. • File Headers • Method Headers 11
  12. 12. Apex File Headers • File headers should include… – Description of purpose. – Names / emails of the author, and subsequent editors. – Date of creation, and last modification. – Related metadata (eg. classes, triggers, objects, VF pages). • Apex REST classes should… – Note the HTTP methods they serve. – Note endpoints when using multiple base URIs per method. • Triggers and Trigger Handler classes should… – Note the Actions being caught and processed. • Use @deprecated when a class is no longer in use. 12
  13. 13. Apex Method Headers • Standard (non-test) method headers should include… – One or two sentence description of purpose. – @param description of each parameter – @return description of the return type, noting likely returned values / outcomes. • Test method headers require only… – Description of the test’s functional logic. 13
  14. 14. Visualforce Documentation Visualforce Pages and Components should be simultaneously documented in two places. • File Headers • Metadata “Description” Fields 14
  15. 15. Visualforce File Headers • Use HTML (<!-- -->) comment blocks. • File headers should include… – Description of purpose. – Names / emails of the author, and subsequent editors. – Date of creation, and last modification. – Related metadata (eg. classes, objects, pages, components). • File headers should respect a 100 column width limit. 15
  16. 16. Visualforce Metadata Descriptions • Edit via Setup or -meta.xml • Write for a non-technical audience • Summarize File Header documentation, including… – Short description of purpose. – Date of creation – Full name of original author. – Administrative notes (if known). • Update only if core functionality changes 16
  17. 17. Non-Code Metadata Documentation Add descriptions for ALL non-code metadata! • Description fields typically hold 255 characters – 1000 for Custom Objects and Fields • Descriptions should include… – Short description of purpose – Date of creation – Full name of creator – Administrative references 17
  18. 18. Specific Recommendations DESIGN PATTERNS 18
  19. 19. Salesforce-Specific Design Patterns • Triggers • “Bulkified” Code • Separation of Concerns 19
  20. 20. Triggers • One trigger per Object – Guaranteed order of execution (at least for your code!) • Implement logic in a separate “trigger handler” class. • Use static variables to prevent trigger recursion • All logic MUST be “bulkified”. 20
  21. 21. What is “Bulkified” Code? • Acts on collections, rather than single objects. • Designed with governor limits in mind – SOQL Queries • NEVER perform queries inside of loops! • Query using sets, rather than single-value predicates • Use SOQL For loops when expecting more than 300 records. - Use selective queries! – DML Operations - Always perform DML on collections of SObjects. - Be aware of “hidden” DML, eg. Database.ConvertLead(). - NEVER perform DML inside of loops! – Future Calls - Max of 10 @future calls per execution context. - No callouts from triggers! Business logic often requires use of @future methods. - @future methods called from Triggers MUST be designed for bulk! 21
  22. 22. “Bulk” Design Patterns • All code should be “bulk” code! • Public static methods should always be “bulkified” • Public instance methods can sometimes be “non-bulkified”. – But they should have a really good reason! Commit to “bulk-first” design, and it will eventually become second nature. 22
  23. 23. Separation of Concerns • What is SOC? – Class architecture? – Naming conventions? – Mumbo Jumbo? 23
  24. 24. Separation of Concerns (High Level) Entrypoint Layer Invocation Layer Service Layer Utility Layer Activities that invoke Apex – API / UI Based Create/Update/Delete – Visualforce Page / Component Load – SFDC Asynchronous Queue, Apex Scheduler “First Line” of Apex Code – Visualforce Controllers and Extensions – Triggers and Trigger Handlers – Web and Email Services – Asynchronous and Scheduled Apex Domain and Function-specific Business Logic – LeadServices.cls, AccountServices.cls, etc. – RegistrationServices.cls, CpqServices.cls, etc. Supports the Service Layer – Utility Classes – Model / Wrapper Classes* – Selector Classes 24
  25. 25. Separation of Concerns (Low Level) LeadConvController.cls 25 SFDC API Based Create/Edit/Delete UI Based Create/Edit/Delete LeadConv.page Asynchronous Apex Scheduler Queue Operation Operation LeadTrigger.trigger LeadTriggerHandler.cls LeadIntAsync.cl s LeadIntBatch.cls LeadCleanJob.cls ContactServices.cls LeadServices.cls AccountServices.cls ContactSelector.cls LeadConversionUtil.cls ConvertedLead.cls AccountSelector.cls
  26. 26. Naming Conventions • Apex and Visualforce Names • Apex and Visualforce Identifiers • Objects, Fields, and other Metadata 26
  27. 27. Apex and Visualforce Names • Use UpperCamelCase • Avoid using underscores • Use full names, rather than abbreviations (in most cases) – If using abbreviations, be consistent! • Test classes append “Test” to the name of the covered class 27
  28. 28. Choosing a Name Apex • First word(s) should be the API name of the related component. – If too long, use a consistent best-approximation – Ignore underscores • Middle word(s) can provide context (optional) • Last word(s) should indicate “functional type” of the class – Reconsider design of classes that don’t fit one functional type Visualforce • For Visualforce names, be descriptive but brief – Controller classes incorporate the Page / Component name 28
  29. 29. Apex Class and Trigger Name Suffixes Functional Type Name Suffix Examples Trigger Trigger AccountTrigger Trigger Handler TriggerHandler AccountTriggerHandler VF Controller Controller NewAccountController VF Controller Extension ControllerExt AccountControllerExt Service Class Services AccountServices Utility Class Util AccountDupeCatcherUtil Selector Class Selector AccountSelector Model / Wrapper Class Varies… Accounts / AccountWrapper Web Service (SOAP) Ws AccountToolsWs Web Service (REST) Rest AccountToolsRest Email Service EmlSvc AccountCreateEmlSvc Asynchronous (Future) Async AccountIntegrationsAsync Asynchronous (Batch) Batch AccountMigrationBatch Scheduled Apex Job AccountCleanupJob 29
  30. 30. Apex and Visualforce Identifiers • Variable Names – SObjects • Type of SObject should be clear by looking at name – Collections • Should always be plural! • Method Names – UseCamelCase…but the first character is always lowercase. • useCamelCase() All should… • Use descriptive words. – Rapid clarity to others is important! • NEVER use single-character variables. 30
  31. 31. Objects, Fields, and Other Metadata Create and follow common rules for… • Use of underscores to separate words in API names. • Capitalization of words in API names • Must API names and labels match? 31
  32. 32. Specific Recommendations PROCESS / GOVERNANCE 32
  33. 33. Recommendations • Agree on specific org-wide standards, patterns, and practices. • Refactor code and data model • Define a regular Quality Control Cycle. 33
  34. 34. Agree on Standards • Figure out what they are • Socialize with your team • Seek support from management 34
  35. 35. Refactoring Your Org 35
  36. 36. Quality Control Cycle Quarterly (Day 0 / 90) •Data Quality Inspection •Field Trip Report •Code / Data Model Cleanup •Process Analysis / Improvement Mid-Month (Day 15) •Code Review Monthly (Day 30) •Code Review •Data Quality Inspection Mid-Month (Day 45) •Code Review Mid-Month (Day 75) •Code Review Monthly (Day 60) •Code Review •Data Quality Inspection 36
  37. 37. Three Things You Can Do TODAY • Create a one-page Standards Document • Make sure you’re using one trigger per object • Commit to two code reviews 37
  38. 38. Discussion Q & A 38
  39. 39. people Thank you! Vivek M. Chawla @VivekMChawla 39
  40. 40. Appendix • Google’s Java Style Guide – http://bit.ly/GoogleJavaStyle • Separation of Concerns – Dreamforce Presentation (Video) – “Apex Enterprise Patterns” • http://bit.ly/DF2013SOC – Andrew Fawcett’s Blog – “Apex Enterprise Patterns – Separation of Concerns” • http://bit.ly/FawcettBlogSOC – DeveloperForce Technical Library – “Separation of Concerns” • http://bit.ly/DevForceSOC 40

×