.jpg)
Static analysis tools are very powerful instruments to help run engineering teams successfully. They can process large amounts of code in a very scalable way and help enforce security and code quality checks systematically, minimising human error.
As architects, finding the right solution may not be a straightforward task. Every tool has its own pros and cons and there are many considerations to be factored in before making a recommendation. This articles explores some common mistakes to avoid when evaluating static code analysis tools, specifically in the Salesforce space.
1. Not thinking about the type of metadata supported
Salesforce comes with a wide range of low-code to pro-code development options. Your static analysis solution must adequately support the tools, paradigms, and frameworks you use for development, and plan to use in the future. Different solutions have different capabilities, and it's important to analyse fit carefully when looking at a solution.
- Relevant pro-code languages for your team (Apex, Visualforce, Aura, LWC). What is my team using right now? What will the team be using in the future?
- Ability to scan metadata and low-code (Flows, Process Builder, Workflows, Objects, etc)
- Repo setup, including source format you use (e.g. metadata vs SFDX), folder structure, etc.
2. Not looking at rules in details
The catalog of rules determines what checks can be performed automatically by your static code analysis tool. One common mistakes is comparing tools based on the number of rules they provide out of the box, without considering the value each rule brings. For example, some tools may put strong emphasis on syntax checks, while leaving other architectural aspects uncovered.
3. Underestimating noise
The accuracy of your tool naturally determines the amount of noise to your developers. Inaccurate tools cause distractions and are more likely to be ignored by the developer. Key considerations include:
- Are detection based on syntax or is the tool capable of traversing the code flow?
- Can the tool detect problems that spread across multiple files?
- Can the tool traverse nested calls?
- How common are false positives/negatives? How are they handled?
4. Disjointed development experience
Your tool must support your workflow well, have minimal overhead on your developers and provide an integrated, cohesive development experience.
- How easy is for developers to launch a scan?
- Can the developers bypass/ignore it?
- Are the right information made available to developers at the right time?
- Can it be run continuously and automatically?
- Does it fit well into your development workflow?
- Does it integrate well with your version control?
- Does it integrate well with your CI/CD tools?
- Can it be run continuously and automatically?
- Does it fit well into your development workflow?
- Does it integrate well with your version control?
- Does it integrate well with your CI/CD tools?
- Can developers omit/bypass/skip it?
- Can exceptions be easily managed?
- Can false positives be managed?
5. Wrong cost structure
Whether you decide to buy and off-the-shelf solution or build it yourself, you should consider cost as a key part of the equation. The cost of a tool need to align with the value you get and align with the way you run costs. When going for a commercial solution, always consider the following:
- Is this the best licensing model for me?
- What is the ongoing cost to maintain (e.g. upgrades, security patches, etc)
- Does the tool require additional software that is sold separately?
- Is the cost reasonably aligned to the value you are getting?
