Q: What’s a “best practice,” and what’s a “best practice” as applied to Salesforce development?
First, a general explanation of a best practice.
A best practice is a widely-accepted, agreed-upon set of steps or procedures for solving a problem. The term is used in tons of different disciplines, but particularly in the software industry where complex projects require the inputs of many contributors.
Within the software industry, and within the world of Salesforce administration and development, the definition is even more narrow: a best practice refers to a rule (or a corollary to a rule) that we should not break.
So yes, these are Salesforce’s version of the ten commandments — though you have more than just a moral obligation to abide. If Salesforce development wrote a constitution, best practices would be the articles and the amendments and the preamble, all of it. They’re pretty damn important.
When we follow best practices, we avoid making the mistakes of our predecessors; we treat them as the principles that guide our actions as we build new functionality for our users. If sandboxes allow us to take a hippocratic oath to “first do no harm”, best practices give us practical ways to obey such an oath.
Following best practices has positive externalities outside of the obvious benefit of helping us to not repeat mistakes; we generally end up with more efficient and secure code, and in turn we keep our technical debt at a manageable level.
You can find lots of lists of best practices in Apex development. I’ll give you an abbreviated version, the broader practices which each encompass more specific obligations:
- Bulkify your code
- Separate your concerns
- Set standards and conventions
By bulkifying, we avoid code inefficiencies and respect governor limits. Best practices such as “don’t query in a loop,” “one trigger per object,” and “use @future methods properly” are all really cases of code that isn’t written with efficiency in mind.
When we separate our concerns, we break what we’re building into layers. This helps us to not write cryptic or inefficient code, to not repeat ourselves, and to create a system which others can more easily understand and expand upon.
By setting standards and conventions, such as naming conventions and code formatting standards, we keep our house in order. We make it easier to locate and update work we’ve already done, and we have a better idea of where new efforts fit into the schema we’ve already defined.
That’s all, cheers! Check out the other Conversations here.