Governor Limit is Your FriendThe idea of Governor Limits was not introduced by the Force.com Platform. This concept in the same name or with a different terminology exists in all the Cloud-Based Multitenant Platforms. The Application that you have developed runs on the Force.com Server, which is not just for you but for many others using the same Force.com Platform to run their Applications too. In other words, no one completely owns a server and no one can ever write crappy code that could lead to the monopolization of the resources and would leave the other tenants at stake!
Most of us tend to write SQL queries in the form – SELECT * FROM TableName. We really don’t focus on the fields that are actually needed to solve the purpose and just query all the columns of the table. This isn’t really entertained on the Force.com Platform. There is no * or ALL operator in Force.com SOQL! This was planned by the creators of the Force.com SOQL engine for a reason. They do not want you to do this and end up burning the Heap Size Limit by unnecessarily querying irrelevant fields and disturbing the Governor Limits. We should take care about selecting the columns for the SOQL query. One should ensure that only the necessary columns are selected so as to ensure that we are not putting the whole application into trouble just for the sake of a single SOQL query. We should also pay close attention to writing selective queries. Most of us tend to write Queries where the WHERE clause looks something like this- …. WHERE ColumnName != NULL. We should try and avoid such cases and ensure that the WHERE clause is controlled by at least one Index based column so as to speed up the query execution and to ensure that we don’t break the Governor’s rules such as the Number of Rows returned by a SOQL query.Don’t be lazy about Unit Test Classes – aim for 100% code coverage To be honest – I was really lazy about writing Test Classes but the fact is that we cannot afford to do so. When building the Apex Controller class and the Visualforce page to get the functionality done, we become so happy when it is up and running. But can we guarantee that it’s good to go and your team can start using it? Will that code of yours handle all the cases? What if the User gave some bad inputs? Will the code handle both positive and negative cases or is it just tested for the happy path? Thanks to the creators of the Force.com Platform for enforcing a rule that ensures that classes deployed to the Production environment must have an aggregate Code Coverage of 75%. When we write Test Classes we have to make sure that the Test Classes covers both Positive and Negative Test Cases. A Test Class is never called a Test Class without ASSERT statements. We should make sure that there are appropriate usage of ASSERT statements and the Apex Class being tested achieves 100% Code Coverage and not just the 75% limit. One Trigger Per SObject Recently, our Salesforce Consultant team was assigned with a project which dealt the optimization of Apex Triggers in a Salesforce Organization. The client said that they were hitting Governor Limits very often and some of their business processes have been at stake due to improper functioning of the triggers. This is a frequent situation faced by most of the Companies using the Salesforce CRM to handle their internal business processes. The main cause of such errors is badly coded Apex Triggers which does not obey the rules a developer must follow when writing code on a multitenant platform such as the Force.com, and the presence of multiple triggers on the same object that fire on the same DML events.
When implementing triggers in Force.com, the most important fact that has to be kept in mind is – One Trigger Per sObject. The main advantage of this is that-
- Streamline the Order of Execution – If we have multiple triggers on the same sObject that fire on the same event, then there is no guarantee that the triggers would fire in the order that you like
- Maintenance will never be a threat anymore.