Here are some common mistakes Salesforce developers make:
-
Writing custom Apex code without knowing if that feature already exists in the Salesforce CRM administration.
Apex is a very important feature of Force.com in Salesforce. It gives the ability to write custom code for any kind of functionality. If we compare it to other languages, custom code increases the total development/testing costs. So before initiating any custom development, one should invest some time in comparing the requirement with the Force.com configuration such as workflows, validations and formula fields that can give great alternatives to custom code.
-
Writing test cases just to cover code and not actually verifying whether the code would run with good and bad data input/scenario.
It is true that Salesforce forces to create a test case that covers at least 75% of code overall. But, the main purpose of the test cases is to ensure whether the code written by you runs smoothly for bulk data (try to test your feature with 200 records), the code runs correctly with good data, and throws expected error messages with wrong input.
Sample test class:
@isTest
global class CustomControllerTest {
@testSetup static void setup() {
// Create all the test records here.
}static testMethod void customFunctionTest() {
//Fetch the records using SOQL that may be needed to pass into the CustomController apex class.
// Start Test
Test.startTest();
// Call the functions using class instance
Integer response = CustomController.customFunction(testRecords);
CustomController.customFunctionUpdateStatus(testRecords); // No return type, update the status to Completed at back-end
// Make assertion to compare the Expected Vs Actual output. This can be done in 2 ways,
If you have return type of the function you called above
System.assertEquals(response, 1);
If the function is void but you know which field is supposed to be updated.
ListupdatedTestRecords = [SELECT Id, Status FROM CustomObject WHERE Id =: testRecord.Id];
System.assertEquals(updatedTestRecords.size() > 0, true);
System.assertEquals(updatedTestRecords[0].Status, ‘Completed’);// Stop Test
Test.stopTest();
}
}
-
Not leveraging the automatically generated screens to reduce development time
Visualforce allows us to design any user interface referring to the Salesforce object. I have observed that most of the designers create a completely new VF page to replicate the standard Edit/Detail layout. This can be time-consuming and expensive to develop.
As an alternative, you can use Salesforce Visualforce Generator, a Heroku app that helps in autogenerating the layout in some clicks. Further, you can customize it accordingly.
Link to the app is https://visualforce-generator.herokuapp.com/#/login
You have to log in to your Salesforce org and allow you to access the org. Once done, you will be presented with a list of standard + custom objects in a list and the page mode.
-
Using incorrect relationships between objects when it comes to Many-to-one.
Database Relations in Salesforce:-
Many to Many – Many to One
– Junction Object – Master-Detail
– Lookup
– Self
– HierarchicalOne should understand the need, purpose, and consequences of using all four types of Many-to-One relationships.
Refer below link to understand when to use which relationship.
https://www.janbasktraining.com/blog/what-does-salesforce-use-as-a-database/ -
Not knowing how to structure for code reuse
Visualforce and its controllers, or Apex triggers can be used for writing custom code. Visualforce helps in designing complex UIs using custom controllers which can be reused in other Visualforce pages. Similarly, any common UI can be made by embedding Visualforce components into VF page.
In context with the controller, if logic has to be used every time a record is updated from the custom UI or standard detail page, then that can be written in a trigger using appropriate condition. -
Leaving maintenance and enhancements for others to worry about
By the time, more and more data gets populated into the system. It happens that the developers write code in a hurry without thinking of inefficient code’s consequences. They may start running into governor limits, thus a need to re-write the program completely. There are certain design principles that can be used to avoid rewriting the code later, for example, considering governor limits for SOQL or DML operations made in a single transaction and using the accurate loops to avoid CPU time limit error.
-
Not paying attention to code optimization
- Never use a hardcoded URL or Salesforce ID.
Whenever we deploy apex components to different Salesforce organizations, it will throw an error because that Id may belong to another object in deployed org. It may happen that the Id we used in the code does not even exist there. It will break the feature. Also, it is possible that while testing you may not find the issue because the Id does exist in the deployed org. - Do not overload the page with large data as it may throw the View state error or make the interface working slow.
- NOT BULKIFYING YOUR CODE
Apex code should always be written so that it can handle bulk data at a time. The main idea behind this is to have an optimized code so that the feature works efficiently. Moreover, to avoid governor limits.
For example, an external call is made via Salesforce SOAP API which inserts a batch of records. If a batch of records invokes the same Apex code, all of those records need to be processed as bulk. In this scenario, the code should be handled to process bulk records because it has maximum chances of hitting governor limits. - MULTIPLE TRIGGERS ON THE SAME OBJECT
An object is supposed to have only one Apex Trigger. If we create multiple Triggers for a single object, we will not be able to connect the flow of all the triggers and expect it to execute synchronously. It might happen that the apex logic conflicts with the other trigger belonging to the same object. - REACHING SOQL QUERIES LIMIT
As a multi-tenant system, we can not allow a user on a CRM instance to make millions of API calls per minute. This will affect the performance of other customers in the same instance. This is the reason Salesforce has governor limits which restrict the number of API calls over a time period, which restricts writing bad code.
For instance, there should never be a SOQL query or any DML operation done inside a FOR loop. For one transaction/session, an apex request can use 100 queries. If the session tries to use beyond this limit, the process will stop immediately thus throwing a run-time exception. In case the data loader is used to push records (say more than 100) for that particular object, and the SOQL query is used inside a loop, it will throw an error.
- Never use a hardcoded URL or Salesforce ID.
jQuery allows the user to create powerful and dynamic webpages that run without any hiccup. With StudySection, you have the liberty to choose among beginner or expert level jQuery certification exams to help you excel in this career field.
