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.

Trigger:

• 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.
• Webservice 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

Visual Force:

• 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 View-state: 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

Web Service:

• 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

Data Model:

• 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.

Click Here to read more