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. 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
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 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.
Application 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
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. 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:
- 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.
Recent Comments