Salesforce- best practice

What is best practice?

-        Best practice is considered by some as a business buzzword, used to describe the process of developing and following a standard way of doing things that multiple organizations can use. These are the behaviours and skills that contribute the most to success and used to maintain quality.

Why do we need best practice and pattern for project?

Get below benefits with this

o   Efficient

o   Security

o   Quality

o   Minimize technical flaw

o   Process oriented

o   Improve performance

What to do?

-         Use standard for :

o   coding style

o   documentation

o   Design pattern

o   Naming convention

-        Best Practice for development

            1.  Keep code   clean and concise

a.      Reusing code in several places

b.      Write a single method and reduce the clutter in your code

             2. Always keep comment to understand for what this logic

             3. Always write header in method and class to explain the purpose of this and where this is being referred      

             4. Do not put queries in for loops

a.      If you are making any method call inside for loop, then check if that method contains any soql.

             5.  SOQL In for loop for large datasets

For (account eachAccount :  [select id,name from Account]){

}

                          6. . Shall use maps for queries

 - a fundamental technique and trick to use in order to make SOQL queries, DML transactions, and Apex triggers more efficient

             7. Avoiding SOQL Injection

             8. Use relationship to reduce queries

             9. Do not put DML statement in FOR loop

             10  Only use one trigger per object

             11.   Keep logic outside of trigger

             12.   Write the logic in such way that to handle bulk record processing

             13.   Use of the Limits Apex Methods to Avoid Hitting Governor Limits

             14.   If possible always use declarative approach rather than code, as it is easy to maintain and efficient for                    application.

             15.   Code coverage

a.      You should aim for 100% code coverage.  Even though Salesforce mandates 75% code coverage across your apex classes when you deploy to production, you should always aim for 100%.  This is not to say you cannot leave work until your class covers that last 3%, but the goal being as high a code coverage as is sensible

              16.   Write meaningful unit tests

a.      Use System. Assert statements liberally.

  17.   Test all conditions

a.      Check for nulls, boundary conditions, assert that your exceptions were thrown or handled properly

18.   Never use dummy code coverage

19.   Never test with existing data

20.   Always write test method to test single record, large set/bulk of record, positive and negative scenario and user accessibility scenario.

21.   Avoid Hardcoding IDs

22.   Maintain application log, when any exception occur in application, make an entry in application log for that which can give enough information to resolve the issue.

23.   Enable Apex Governor Limit Warning Emails:

When an end-user invokes Apex code that surpasses more than 50% of any governor limit, you can specify a user in your organization to receive an email notification of the event with additional details. 

1. Log in to Salesforce as an administrator user.

2. Click Setup | Manage Users | Users.

3. Click Edit next to the name of the user who should receive the email notifications.

4. Select the Send Apex Warning Emails option.

5. Click Save.`

Maintain checklist:

Access this checklist from below link:

Download checklist

S. No.	Question	Answer
1. Visualforce
1.1	Why Visualforce and not standard UI
1.2	Does it have a controller
	∙ Standard controller or custom controller
	○ If custom controller, then why not standard
	∙ Does it have Apex code (extensions for standard, or custom controller/extensions)
	○ See Apex section #2 below
1.3	Does it have URL parameters and if so, are they escaped
1.4	Is it mobile ready (HTML5 vs. Touch)
1.5	Is CSRF on GET Requests Checked (v28.0 and beyond)
1.6	Does it use custom CSS or JS libraries
	∙ jQuery, Angular, etc.
1.7	Is there opportunity for re-use using VF components
1.8	Does it use VF templates (composition)
1.9	Are there any dependencies on: components, other VF pages, or static resources
	∙ If using multiple static resources, are they zipped for performance
1.1	Is it embedded in a standard page (i.e. Panel)
1.11	Is it for an action override
1.12	Does it follow naming conventions as defined at your organization
2. Apex
2.1 General Apex Guidelines
2.1.1	Sharing (with/without/none)
	∙ If without sharing, then why
	∙ If none, then why
2.1.2	Are you using inner classes where possible
2.1.3	Are you using custom settings or constants (FINAL) for non-dynamic variables in code
2.1.4	Does your class have large number of properties
2.1.5	Do you have methods with large number of lines (> 45)
2.1.6	Are there any orphaned (or obsolete) classes, properties and methods
2.1.7	Is the API version the latest, if not, then why
2.1.8	Is code bulkified
	∙ No SOQLs or DML statements in for loops
2.1.9	Are you checking for selectivity of SOQL statements using Explain Plan tool in Developer console (with at least 10k rows)
2.1.10	Exception Handling
	∙ For SOQL queries and DML statements
	∙ Is there a need for custom exception classes
2.1.11	Test methods – are they embedded in the main class
	∙ Should be in separate Test Classes (enforced staring with v28.0)
	∙ Do test methods have assertions - positive and negative
	∙ Test Data in test methods - is it generated in Test
	∙ If not generated and using Org data , then why (e.g. Content)
	∙ Are you using Test Data Setup Framework – part of core
	∙ Use of startTest() and stopTest()
	∙ Do test methods leverage different users and profiles
	∙ Are you using bulk updates in test methods
	∙ Are you checking for limits usage in test methods
2.1.12	Code & Naming standards
	∙ Global constants
	∙ Code comments and tagging
	∙ Null checks
2.2 VF Controllers & Extensions
2.2.1	How are fields being retrieved (addFields() vs. SOQL vs. VF Binding)
2.2.2	Does controller have SOQL
	∙ Does SOQL use bind variables to prevent injection
2.2.3	Separation of business logic from controller
2.2.4	Early vs. late binding
	∙ Late binding helps with view state management
	∙ Early binding helps page load performance
2.2.5	Use of action attribute vs. controller constructor
	∙ Controller constructor runs before page action
	∙ Constructors do not allow DML, have to be done in action
2.2.6	View state management and use of transient variables
2.3 Triggers
2.3.1	Are you using a Trigger Handler framework wherein the business logic is separated into a separate handler class
2.3.2	Multiple triggers on objects (should be N/A if using base)
2.3.3	What trigger events
2.3.4	Recursive handling
2.4 Batch Apex
2.4.1	Are you using a framework for logging DML results using helper classes?
2.4.2	Is there an associated schedulable class
2.4.3	Are you using daisy-chaining feature
2.4.4	Are you using Stateful and AllowsCallouts
2.5 Web Services
2.5.1	Are you leveraging the mock testing framework to test webservices
2.6 Email Services
2.6.1	Custom objects for logging and error handling