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.

DevelopmentTrigger:

  • 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

VFiconVisual 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

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

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

gearApplication Development:

  • Application should have a purpose. The applca
  • 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, visit learnacademy.org developer bootcamp to know more.
  • AppExchange Development Checklist

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

deployment-icon-mDeployment:

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

Author: AJ

Share This Post On

Submit a Comment

Your email address will not be published.