Ø DML:
Use a DML for a list of records instead of 1 DML per record, (bulk).
Dirty check of record is very important. In your Apex code, before performing any update DML, check if data is even changed or not? Code in Maximum time, where DML is done on record but it already has same value in Database. We need to issue one extra SOQL and compare. It will save CPU time as well DML governor limit. Its huge game changing approach in Large Data Volume orgs.
Do not perform DML inside of any loops.
Ø Triggers
Don't forget that trigger handle up to 200 records per execution.
Don't put the logic (include SOQL or DML) in the trigger, use a handler class for such logic.
Don't push trigger.New to the handler class method, you should filter on records that are in related scope. You will increase performance, reduce governor limits consumption, and even limit regression risks when updating the class.
Create Single trigger per event and per object. Multiple triggers for the same event of an object would not ensure that the execution order would always be the same, giving unpredictable behavior in production. Managing multiple events in the same trigger would also reduce maintainability with spaghetti code.
Put bypass logic in the trigger for each handler class. This would prevent running some code for some users. For instance, a technical user doing data migration will have improved performance if some business logic is not triggered.
Always optimize. Even if you think it is not needed, as your trigger can be run from another trigger, which can reach governor limits.
Even Beware of over optimization side effects; when optimizing SOQL queries and DMLs, you will probably use structured maps indexed by IDs. This consumes a lot in memory as triggers are limited in heap size and each trigger in the transaction can consume much heap. Always Free memory if such structures are not needed after usage.
Ø Controllers
Bind your pages with the code using "Page.VisualforcePageName" instead of "new PageReference('/apex/VisualforcePageName')". Impact and dependencies will be better managed (like, when renaming the page), and this is the only way to be compatible with CRSF protection.
Reduce ViewState to get better performance.
Secure your code (SOQL injection, etc.). If you leverage an URL parameter you should make sure that it is of the expected type with a correct value & character.
Ø Test Classes
Prefer creating multiple testMethods in a test class instead of one big method, Its help in terms of maintainability.
Avoid using seealldata=true in test classes to avoid conflict (locking contention) with real production data.
Always assert() in test methods.
Leverage a @testSetup method to reduce execution time and increase maintainability.
Test the limits (bulk) logic.
Use test.startTest() after data preparation and test.stopTest() before asserts.
It is better to do Test Driven Development (TDD). It is more productive development.
Prefer target 85% code coverage per class.
Ø Visualforce
Keep you page light weight (few fields, simple DOM, avoid frameworks), for performance and usage.
Remove commented code (<!-- ... -->) to increase maintainability and improve server parsing performance.
Do not hardcode access to Visualforce Pages (value="/apex/pageName") as it will break when CRSF is enabled. Use either {!$Page.PageName} or {!URLFOR($Page.PageName)}
Reduce frameworks usage to keep the page light weight and performant (RAM footprint, network impact, CPU consumption, etc.)
Managing errors. An error can still occur, warn the user with putting one of the following tags on the top of your page: <apex:pageMessages /> or <apex:messages />
Comments