Salesforce.com has been both a business application and a development platform for a decade. It is being used as an integration hub for the cloud because of the number of its APIs and available adapters. Evaluation of an SFDC system configuration for its sustainability and manageability is necessary.
Here are some rules to look out for in an SFDC instance, and why they matter.
Optimize unused objects and unused fields
If you have historical objects that are no longer active (but do hold data) and fields that are explicitly marked as deprecated, having hundreds of mystery fields just makes things harder to understand and manage.
Manage reports and users
The number of reports should be less than the number of users. For any one object, there shouldn’t be a mix of code, workflows, and flows. While each of these technologies works fine individually in the appropriate use cases, with any level of sophisticated processing they do not play well together. Mixing these technologies on a single object makes the transactional flow harder to understand and causes lots of flaky behavior and annoying failure modes.
Apex code test methods
Apex code test methods should be at least 75 percent the size of the code under test. If the code is the least bit interesting, it will have branches and calculations. Setting up the data conditions to cover all the branches and do any level of testing for results/outcomes takes lots of lines.
For any one object, there shouldn’t be more than one trigger, and it should be small (ideally, just one line). You can get away with a couple of simple triggers on a given object, but can’t control the order of execution among an object’s triggers. The only way to guarantee that any complex processing is done right every time is to have one trigger per object.
Classes can be as big as you want, but individual methods should fit in a single screen. Anything bigger than 15 lines is probably a mixture of methods and should be refactored for simplicity and comprehensibility.