Monday, July 30, 2018

Best Practices in Salesforce (Article By Sunil Sharma)

Hello Audience, Sharing some best practices which will help you to make efficient and scalable Salesforce Solutions. This article gives you an idea of important key best practices of developing and designing Code/Configurations Solutions on the Force.com Platform.

Best Practices for Salesforce Development
  • Try to use configuration instead of code wherever it is  possible. Despite configuring the things there are certain actions which cannot be achieved using Configurations Standard Settings, thus, it leads to adding some custom code, which results in Customization where Customization means adding Apex Code.
  • Try separating the modules clearly by following MVC Architecture (like -model / controller / trigger handler/utility class / view / tests).
  • Try avoid writing duplicate codes - add separate utilities/base classes, subroutines, etc. For e.g - Suppose you have a requirement of integrating Salesforce with some other external system and you have some VF pages that makes callouts to an external endpoint, so instead of writing callout logic multiple times you can write the logic in one Utility class and can use this class multiple times whenever required.
  • Always Prevent SOQL injection - To prevent a SOQL injection attack, avoid using dynamic SOQL queries. Instead, use static queries and binding variables. SQL/SOQL injection involves taking user-supplied inputs and using those values in a dynamic SOQL Query. If the input is not validated, it can include SOQL commands that effectively modify the SOQL statement and trick the application into performing unintended commands or malfunctioning.
  • Try to handle the potential errors in the Code.  You can comment cases where errors should be ignored. Apex provides a framework for handling the exceptions. You can use try-catch-finally statements to catch system exceptions. You can also use custom exceptions to throw your own custom errors  and then display the appropriate messages when required. These techniques  gives Users a better experience.
  • Provide useful and complete documentation for classes & methods - It would be good if you can maintain a documentation of Development Components like Apex Classes & its methods etc, VF Pages and their controllers, and Triggers etc. The documentation helps in keeping track of all development aspects of an application and it improves on the quality of a development work. Its mainly used in the development, maintenance and knowledge transfer to other developers. Successful documentation makes it easy to access the information and also provides a way for new developers to understand/learn the Project in a lesser time.
  • Write small, clear, indented, single-purpose methods.
  • Try to use descriptive names for classes, properties, methods, variables, etc.
  • Try to use whitespace to improve readability in the code.
  • Make sure to use CamelCase classes, interfaces, methods, properties, and variables, ALL_CAP finals.
  • Try to use spaces instead of tabs.
  • Make properties and parameters final when possible.
  • Make Sure - No SOQL, DML, or @future calls inside loops.
  • Use static queries, binding variables or escapeSingleQuotes to prevent SOQL injection attacks.
  • The trigger and asynchronous code should be bulkified. It should run efficiently for bulk data as well as for small amount of data.
  • Use asynchronous code (future, batch, scheduled) when possible.
  • Please Do not hard code any Ids in Code.
  • Create at most one trigger per object. In case you want multiple functionalities to be performed through trigger then make use of ‘Handler Classes’. 
  • Always try to make “Logic-Less” Triggers - The role of the Trigger is just to provide the logic responsibilities to some other handler class. Trigger testing is difficult if all of the application logic is in the trigger itself. Writing methods inside Triggers will also not help in this scenario as these methods can’t be exposed for test purposes. You also can’t expose logic to be re-used anywhere else in your org. Hence, writing Handler class and breaking different logics into different modules (methods) proves to be a useful technique and also provides a way to modularize and reuse the code whenever required.
  • Use custom settings, labels, or metadata types for configurable settings and preferences.

No comments:

Post a Comment

Governor Limits Example-Too Many DML Statements :151

Governor Limits Example : Too Many DML Statements :151 (Sunil Sharma) Example:Code Hitting Governor Limits System.LimitExceptio...