💃 Let's Unpack Salesforce Development Best Practices 🕺

Good morning, Salesforce Nerds!

Inspired by a literal 💩-ton of Salesforce Developer Best Practices articles on the interwebs, I thought I’d put together a list too. 🤙 

I’m not saying this is the be-all and end-all. But rather a daily reminder type of list.

As you go through your discovery, design, and build these things can go a long way in helping you build a resilient Salesforce solution! 🔥 

TABLE OF CONTENTS

Let's Unpack Salesforce Development Best Practices

• BE SURE TO BULKIFY

• FOLLOW YOUR ORG’S FRAMEWORK

• SECURITY IS KING

• TEST MEANINGFULLY

• RESPECT THY LIMITS

COSTCO-STYLE CODING

BE SURE TO BULKIFY

Even non-dev’s have heard this one.

This has got to be the most repeated piece of advice for Salesforce dev’s. Hand’s down. 💯 

And for good reason.

You’re sharing compute resources with other Salesforce customers. They can’t having you writing code that’s gonna bottleneck someone else.

So it make sense the mothership is going to be watching your every move. 👀 

Remember the basics:

✅ Structure your code to work with collections of data

❌ No SOQL inside of a loop

❌ No DML inside of a loop

✅ Use Lists or Sets as method parameters

DON’T DO YOUR OWN THING

FOLLOW YOUR ORG’S FRAMEWORK

This should go without saying.

If you team is using a development framework to write code. Then don’t ignore it and do you own thing. ⛔️ 

That’s an PR to decline.

If you’re not using one, then implement one. We still ❤️ Apex Enterprise Patterns. Probably always will!

You want to have a standard to do things like:

✅ Handle and/or log exceptions

✅ Organize queries into re-usable methods

✅ Leverage design patterns

✅ Implement trigger handling logic

ALWAYS REMEMBER TO LOCK UP

SECURITY IS KING

Security is everyone’s responsibility.

You don’t want to be the team that just accepts all profiles when creating that new field! 😶 

You’ll best serve your team, organization, and your Salesforce career if you bake security into everything you do.

We’re talking:

❌ Don’t overuse the Without Sharing notation

✅ Perform security checks before executing DML

✅ Enable & enforce MFA

❌ Don’t put off evaluating user privileges

IF YOU DON’T DO THIS, I’M SENDING IT BACK

TEST MEANINGFULLY

Another one of those “boring” best practices. 🙄 

I’ve been writing software for 20 years and have yet to meet a dev that enjoys writing tests.

I’m starting to think they don’t exist … 🦄 

But, this is CRITICAL. We must be sure our code is resilient and will stand up the greatest test of all time … users.

Just keep this in mind:

✅ Cover all scenarios - positive, negative, and null

✅ Assert your test results - consider it mandatory

❌ Don’t rely on just 75% code coverage. Aim for 90%

✅ Use the runAs method to test in different user contexts

TRY NOT TO GET BURNED

RESPECT THY LIMITS

Can’t be said enough.

Most of these best practices will help you avoid issues with governor limits, but you’re always going to need to keep one eye on this ball. ⚾️ 

Always remember you’re sharing compute resource with other companies.

You’ll need to act accordingly. 🫡 

While designing your code, try:

✅ Use asynchronous processing where appropriate

✅ Write selective SOQL

❌ Don’t ignore bulkification - see #1 👆️ 

✅ Watch for trigger recursion

SOUL FOOD

Today’s Principle

and now....Salesforce Memes