1: Bulkify your Code:
Handles more than one record at a time. When a batch of records initiates Apex, a single instance of that Apex code is executed. It handles the all the records in the batch in order to write scalable code and avoid hitting governor limits.
2: Avoid SOQL Queries or DML statements inside FOR Loops
If we are wrting the SOQL and DML ‘S in for loops it excutes no of iterations which means more iteration in this loop for this cause we got governer limit exceded and got run time exception.
3: Bulkify your Helper Methods
Apex methods are properly designed to handle bulk records. These methods should be written to be invoked with a set of records, especially if the method has a SOQL query or DML operation.
Utility or helper methods are efficiently written to handle collections of records. This will avoid unnecessarily executing inefficient queries and DML operations.
4: Using Collections, Streamlining Queries, and Efficient For Loops
combination of using collections and streamlining SOQL queries can substantially help writing efficient Apex code and avoid governor limits.
5: Streamlining Multiple Triggers on the Same Object
As earlier i said govner limit for trigger on soql is 100. To reduce the redundancy.
Instead of only the one trigger getting a maximum of 100 queries, all triggers on that same object will share those 100 queries. That is why it is critical to ensure that the multiple triggers are efficient and no redundancies exist.
If developed independently, it is possible to have redundant queries.
6: Querying Large Data Sets
The total number of records that can be returned by SOQL queries in a request is 50,000.
Force.com platform split your large query results into batches of 200 records .
7: Use of the Limits Apex Methods to Avoid Hitting Governor Limits
Apex has a System class called Limits that lets you output debug messages for each governor limit.
you can evaluate the output to see how the specific code is performing against the governor limits.
System.debug('Total Number of SOQL Queries allowed in this Apex code context: '
8: Use @future Appropriately
- No more than 10 method calls per Apex invocation
- No more than 200 method calls per Salesforce license per 24 hours
- The parameters specified must be primitive dataypes, arrays of primitive datatypes, or collections of primitive datatypes.
9: Writing Test Methods to Verify Large Datasets
Apex code executes in bulk, it is essential to have test scenarios to verify that the Apex being tested is designed to handle large datasets and not just single records.
API can send multiple records per batch, leading to the trigger being invoked with several records. Therefore, it is key to have test methods that verify that all Apex code is properly designed to handle larger datasets and that it does not exceed governor limits.
10: Avoid Hardcoding IDs
Code should be writing in dynamically not statically because code change from one environment to another environment .
So write the code dynamically.