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:
| 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 | |
