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 there 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 the 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 into 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.
• Planning a Data Migration: Start the migration with few records only and this can lead to a 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 logic is the must.

Application Development:

• The application should have a purpose.
• 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

Test Classes:

• 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. There could be several test functions in 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

Deployment:

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