For the last eleven months or so, I’ve been working a lot as a salesforce developer. In this time, I’ve learned an incredible amount about Salesforce. This blog article is a culmination of all the different things I’ve experienced and learned along the way. The syntax for Salesforce Apex is very similar to Java, but there’s certainly some different challenges.
For the most part, I’ve become a lot more concerned about the use of resources. Salesforce.com is a multi-tenant environment; this means that resources are shared amongst many. As a result, Salesforce must impose some limits, these limits are called governor limits can be found through out the system. One of the most common limits is the number of SOQL queries that can be done in a transaction and the number of lines of code that can be run.
The easiest way to get around these limits isn’t to look at using Future Methods (See my blog post called “What are Future Methods “) or other techniques, instead try to use native Salesforce functionality like workflows. For me, avoiding governor limits has been one of the most frustrating parts of developing in salesforce / apex. My first time experiencing a governor limit was in a long loop that queried the Primary Contact for an Account. I would have been far better off using the SOQL binding and then looping through the results after. (And it proved to also be faster when I ended up testing it.) In development, it’s very difficult to hit governor limits. SOQL queries should be avoided in loops.
Triggers should always be coded for bulk processing. Queries and operations should usually be done on some sort of collection like a list. It’s incredibly easy to hit the SOQL limits if your code will run in a very active organization. On a sandbox, you’ll probably never experience this while debugging or building the code.
Validation Rules are your friend. In the book “Clean Code”, Bob Martin was adamant about not repeating yourself and keeping things simple. By using validation rules we can keep our code clean and stop from repeating ourselves in multiple places. Validation Rules
Controllers should do the very minimum required to get a record, display a record, and save a record. If possible, pages should use standard controllers and then controller extensions to do any logic or processing. Anything else, should probably happen in a validation rule or a trigger. Unit Testing is vital because it’s impossible to test everything by hand, and Salesforce requires at least 75% code coverage across all classes and at least 1% code coverage for each trigger.
When developing custom logic for Salesforce, there’s no such thing as just a few minutes for development if a bug creeps in. Deploying code into production from a sandbox instance can take anywhere from half an hour to a few hours depending on the size of the codebase. Previously, I’ve done unit testing in .NET and in PHP and found it very helpful in reducing bugs. In Salesforce, the overall code coverage must be at least 75% for a deployment to be successful.
That’s a few things I’ve learned about Salesforce the hardway. What things have you learned since you started?
