SFDC Development Best Practices

These are fundamental core concepts that need to be taken care as minimum and apply the latest and greatest features from the ever-evolving Salesforce platform to keep up with the constantly changing business processes and priorities.

This post lists all the concepts at a high level, and we will follow up with detailed posts on individual topics..

Let’s get on to it now…

Basics

DRY – Don’t Repeat Yourself –  Avoid duplication, redundant code, any manual repeated actions in your development/deployment process. Automate wherever possible.

KISS – Keep it Simple Stupid – People (including product and service users) generally want things that are simple, meaning easy to learn and use. Avoid over-engineering.

YAGNI – You Aren’t Gonna Need It -always implement things when you actually need them, never when you just foresee that you need them. Avoid complicated patterns, frameworks, packages /libraries that are not going to be used or not relevant to a unit of work.

SOC – Separation of Concerns (Modular Programming) – ” The goal is to design the system so that functions can be optimized independently of other functions so that failure of one function does not cause other functions to fail, and in general to make it easier to understand design and manage the complex interdependent system.” Do one thing well vs. “do all the things at once or in one place.”

Salesforce Platform Development

Logical & Physical architecture

• Learn/Understand the platform architecture
• Understand the different layers and interactions between them (UI < – > Business < – > Database)
• Understand the Vertical & Horizontal components’ details in the platform architecture  (Apps, APIs, AI, Database, etc..)
• Force.com vs. Salesforce – understand the difference between the core platform and the packaged apps running on the platform (SaaS & PaaS)
• Understand the communication and data flow between Login / Authentication servers to App servers to Database

Multitenancy – Multitenancy is the fundamental technology that clouds use to share  IT  resources cost-efficiently and securely.

Metadata – Metadata is analogous to the subject, which represents all standard objects. Metadata represents all components and fields in Metadata API. Instead of identifying each component with an ID, each custom object or custom field has a unique full Name, which must be distinct from standard object names, as it must be when you create custom objects or custom fields in the Salesforce user interface.

Limits! Limits! Limits!
understand why it’s there, appreciate its existence, work within the limits & not around it. Identify When to Code & When Not to

With Salesforce platforms, there are different ways to implement a solution – Code vs Low Code vs No Code

Code

If you end up with Code, consider

Environment

• Coding Standards (one that evolves with your project)
• Choose the right IDE (less of dev console) Source Control Design & Build
  • Minimalist Approach, Simple & Modular Design Scale for future Test – Robust test cases maintain
  • Regular Refactoring 3 releases a year with a bunch of new features in every release – good to revisit customizations (not just code) to see how we can retire/ replace/ enhance
    

Apex

Security – FLS, Sharing, SOQL injection, run code analysis

Performance – Identify Sync vs Async operations – moving non-real-time,long-running  data-intensive operations into Background jobs – Schedulable / Batchable / Queueable

Avoid Hardcoding – Make use of Custom Metadata, Settings, Labels, etc.. and avoid hardcoding wherever possible

Error Handling – Exceptions, Logging & notifications
Not always Clicks vs. Code.. sometimes it’s Clicks with Code

Triggers

Use trigger frameworks e.g handler patterns –

Trigger frameworks can help significantly reduce the amount of development effort as the org continues to grow more and more.

Here are some advantages of using trigger frameworks:

• Maintenance of Triggers is a lot easier if the trigger logic isn’t in the trigger.
• Unit testing is a lot less complicated when the logic isn’t in the trigger.
• It’s easier for teams of developers to work in a single code base if triggers are implemented consistently

Don’t build all the logic directly into the trigger. Delegate to the handler methods based on the events

Avoid Multiple triggers on a single object – order of execution is not guaranteed

Bulkify – handle mass data operations, not just a single record
Understand Transactions & Rollbacks Avoid Recursion

Avoid Recursion – make sure your triggers are not getting into recursive loops and hitting performance issues or governor limits.

Data

Data Structure & Modeling – Standard objects, Custom objects, Relationships, field types.

SOQL & SOSL – Understand the difference between the two and apply Search vs Queries based on the context.

Perform data operations (DML) in bulk – Alway use collections to perform DML operations instead of record level DML

Selective Queries – apply filters and get the right subset of data needed to minimize processing time

Visualforce

Page

• Transact only the data required for the UI, avoid posting back unnecessary data
• Keep the ViewState minimal Delay / Lazy Load the components not required immediately.
• When working with large datasets, try using pagination.
• Utilise caching for static reference data

Controller

• With Sharing – So the page accesses only the data accessible for the current user
  
  

Lightning

UI – Base Components The base components handle the details of HTML and CSS for you. Each component provides simple attributes that enable variations in style. This means that you typically don’t need to use CSS at all. The simplicity of the base Lightning component attributes and their clean and consistent definitions make them easy to use, enabling you to focus on your business logic

Data Access – LDS (Lightning Data Service) Use Lightning Data Service to load, create, edit, or delete a record in your component without requiring Apex code. Lightning Data Service handles sharing rules and field-level security for you. In addition to not needing Apex, Lightning Data Service improves performance and user interface consistency

Communication – Events (Application & Component Events)

Security – Make use of Locker Service compatible libraries and ensure the communication between the components are following the defined structure.

Performance – Caching

Testing

Build Robust Test Cases – covering both positive & negative use cases. Don’t just focus on code coverage, Avoid using fake test methods. Use Asserts, verify expected vs actual results

Test Data Factory – Test Data Generation
Using Test.start and Test.stop methods to define the transaction boundary

Integration

There are plenty of options for Integration with Salesforce – Point to Point API, Appexchange apps, Middleware ETL, File based, etc.. Understand the use case and identify the right fit for the solution.

Choose the right API for the given scenario – SOAP (Enterprise, Partner), REST, Streaming, Bulk, Tooling, Metadata, Standard vs Custom API SOAP vs REST
REST – There are some recent enhancements to Salesforce rest api… Composite option (Batch, Tree mode)
Other Options – Platform Events, Lightning Connect (oData), External Middleware, Appexchange apps

SalesforceDX

Automate! Automate! Automate!

Developers can now build collaboratively and deliver continuously with Salesforce DX, Whether you’re an individual developer or working as part of a large team, Salesforce DX provides you with an integrated, end-to-end lifecycle designed for high-performance agile development

Consider taking help of tools like Autorabit, Gearset, Copado, Flosum, etc..which works with DX Time to move away from Changesets

Understand the development and deployment flow with the new developer experience

• Source Control < – > Scratch Orgs < – > Sandboxes < – > Production

Thanks for Reading…