The quality of Salesforce code can be very difficult to judge. The primary reason is that Apex, Visualforce, and Javascript are literally different languages – indecipherable to most of us. And most project stakeholders don’t have the spare time to learn Javascript. Despite these challenges, determining the quality of custom code is critical. Luckily, there are a couple way to do this without learning new languages and reading through code.
Direct Analysis
If you are a developer or have access to someone who knows Salesforce development, there are analysis tools that can help you take stock of your situation directly. PMD, CPD, ESLint, Apex tests, and Jest tests are a few of these.
Indirect Analysis
In addition to direct analysis, custom code can be analyzed by looking for the indirect signs – or the effects – of potential code problems. Let’s look at some of the most obvious ones:
- Failed deployments: If deployments fail due to unit test failures or inadequate coverage, you’ll need to take a look at your Apex unit tests.
- Instability: If you’re seeing exceptions and error messages in your Apex jobs, scheduled processes, or every-day interactions with Salesforce, custom code is not running as expected.
- Failing unit tests: As discussed above, many customers’ first indication of unit test failures is during deployment. Other indicators include complaints from developers or a constant stream of defects in existing features. Without clean and comprehensive unit tests, new development is extremely difficult.
- Failed security review: If you develop App Exchange packages, you’re required to periodically submit your application for security review. Salesforce will scan your custom code for potential quality problems and security risks. They use a Checkmarx scan, other tools, and live reviews to verify that your code meets their Secure Coding Guidelines. If concerns are found, you’ll need changes to custom code to bring your business into compliance.
- Low data integrity: Defects in your code may be causing data to be wrong or missing. If integrity problems are severe, Salesforce will not reflect the reality of your business and will become unusable.
- Security / data breach: A security breach is an incident of unauthorized access to your data, applications, networks or devices. It results in information being accessed without authorization and can often be traced back to custom code. Although no one is immune to a security breach, well-designed custom code can make you less vulnerable.
- High development expenses: When code is poor quality or has deteriorated, it becomes expensive to modify. Your project teams will not enjoy working in such a state.
- Failed projects: Are projects becoming death marches dreaded by everyone on the team? Messy custom code can slow your teams velocity and cause enhancement / defect spirals that kill your efforts.
- Scalability failures: Perhaps the original code worked fine in a sandbox with limited data, but now you’re seeing exceptions and failures everywhere. If code was not designed to be scalable, it will need to be revisited.
- Low user adoption rates: The overall and devastating result of all these issues is that all your good intentions will be for naught. No one will use a slow, buggy system whose data cannot be trusted.
We hope you don’t recognize many of the Salesforce custom code problems above in your own environment. But if you’re like many Salesforce customers, the custom code in your environment is causing some of these issues and could use some attention.
Top comments (0)