Embed Size (px)
Citation preview
Ajay Dubedi
www.ajaydubedi.com
www.ajaydubedi.com
7 Checkpoints for Salesforce Developer
As a Salesforce developer you are supposed to take some mandatory precautionary measures for development, testing and deployment. Development in itself could be a complex job. We should be careful enough while we are designing the UI or implementing any business logic. This piece of advice can be a long list of Do’s & Dont’s but I will be summarizing the top 7 domains under which a novice or a seasoned developer can make mistakes.
● Less Code in Trigger: Business logic should be written in Apex classes and purpose of writing
a trigger should be to divert the various update, insert, delete, before, after control flows to
the correct Apex class. Context-Specific Handler Methods should be their in Apex classes.
● Bulkification. While developing a fresh trigger we should always think of the possibility that
the records in the object can be inserted, updated, deleted by a User in bulk using API, Data
Loader tool or custom Multiple edit page etc.
● NULL Check: This is a very basic check which every developer learns in the course of testing
triggers which they developed.
● One Trigger for One Object: Creating multiple triggers on the same object will cause
warnings in Checkmarx Code review for Appexchange.
● Self looping triggers: Beware of this and make sure you use a Static field in class to verify the
trigger is not getting called multiple times.
● Web Service callouts from Triggers: Can’t hit more than 10 callouts at a time. Design Patterns
are good solution for this.
● Trigger Frameworks and Apex Trigger Best Practices
Trigger
www.ajaydubedi.com
● SOQL: Make sure the query is having a limit or an intelligent WHERE clause. A query
can be written in Salesforce in multiple ways.
● Design: If the Logic permits then use components and divide the screen in separate
pages or Wizard steps.
● Use Static Resource for all the CSS and images. Separate JQuery, Javascript files will
also be good.
● Check Viewstate: Make sure that the Salesforce view state size is always in check.
● Action Tags: The lesser number of action tags the less will be callouts to Salesforce
controller(Server). Most of the simple business logic/validations can obviously be
carried to client side scripting.
● Best Practices for Improving Visualforce Performance
VisualForce
www.ajaydubedi.com
● Commit Rollback exception. This should be taken care of
● SOAP: We should have the clear understanding of WSDL we are going to use in Salesforce.
Web Service, parameters, range and return value. SOAPUI is one of the best desktop based
tool to do a dummy test.
● WSDL FILE size limit may some time demand trimming: Will need WSDL expertise for this job.
● REST: The services resources should be identifiable and a developer should be aware of the
methods to call, their consequences & return results. Once can always use various online
tools to do this dummy testing
○ Apigee○ Resttesttest○ Crosschecknet○ Runscope
Web Service
www.ajaydubedi.com
● Make sure that the Data model is planned way ahead before
deployment. Final stage data model changes may cause
business logic changes too.
● Data Types of Fields should be chosen wisely. Remember once
a field is having certain values in production and if you wish
to change the Datatype of that field then all the record values
from that field may get lost.
● Planning a Data Migration: Start the migration with few
records only and this can lead into few tweaks in Data model.
Data migration can be a one time task and very crucial to the
initial setup so taking care of existing Objects, fields and
business/programming logics is must.
Data Model
www.ajaydubedi.com
● Application should have a purpose. The applica
● Choose the application Prefix carefully: While creating a managed package
Prefix can be set only once.
● Test for all the Salesforce editions before release.
● Create Aloha app for Professional edition. Aloha Apps don’t count against
your system limits for apps, tabs, and objects.
● Always complete your testing with Beta version of the application rather
than jumping on to Release.
● Remember to deprecate the Beta version application once you have a
Released version ready.
● AppExchange Development Checklist
Application Development
www.ajaydubedi.com
● Test Class Version: Make sure the version of Test classes are above 22.0 or later will be best.
● For urgent deployment one may tend to use mock code coverage of huge dummy class but this should
be avoided.
● Test Data: Setup test data in Unit test methods. Using Utility functions to create test data can be very
helpful. SmartFactory
● Bulk Testing: Bulk Testing should always be done for objects having triggers.
● Business logic and Scenario based Test Classes: The purpose of writing test classes is to test the
business logic being executed correctly by your code without any failures. Their could be several test
functions in a classes to test all the user scenarios end to end.
● Positive and Negative Testing: Make calls to methods using both valid and invalid inputs.
● An Introduction to Apex Code Test Methods
Test Classes
www.ajaydubedi.com
● Link Mapping: Make sure that final deployment is having the correct Integration mappings,
External Url mappings,
● Code coverage 75%: Salesforce mandates 75% overall code coverage and >0% code coverage
for triggers. We should tend to get code coverage above 95% for a future healthy and less
maintenance org.
● Hard-coding Ids is a deadly affair: Don’t try Hard-coding Ids until it is absolutely necessary.
In Live(Production) org we may have a situation that we are not able to define a page
component or record or specific element by Name or Unique Id then we can take the help of
Hard-coded Ids. The only situation I remember is pre populate some fields or do some tweaks
on VF pages in production.
● Always make sure that the components being deployed to production is on the latest version
or same version as of production.
Deployment
www.ajaydubedi.com
