We have come a long way from understanding the common software development problems and their solutions. Indeed, there must be some scenarios wherein it feels like an overkill or overdesign and yet some solutions may seem better than the design patterns. The idea behind design patterns is to find a structured and robust solution for common problems and not for specific problems. As problems keep on evolving, so will the solutions.
With our development experience and knowledge of design patterns, we can identify the best solutions or design patterns for code development and structuring. Similarly, there are some development solutions, which are regarded as bad solutions or anti-patterns.
Numerous anti-patterns could be listed in a book, but we are trying to highlight some very common pitfalls or bad solutions from a Salesforce customization standpoint.
Often, Salesforce configuration options are suggested as the first option or solution to any given problem. For example, the formula field. Formula fields are fast and easy ways to show calculated field values driven from the same or related objects (parents or grandparents). Formulas are easy to create and manage and are very handy when values are to be shown dynamically.
However, we should understand how a formula field really works under the hood. Formula fields are calculated fields (values are not physically stored), which are calculated every time a record is retrieved. The formula field value gets calculated only if it is a part of the retrieval process. This means that an additional calculation is to be performed for each object record that is retrieved. Now, this will not impact when you are merely looking at the record in view mode or are retrieving a limited number of records. But when you retrieve bulk records via code or reports, the use of more and more formula fields degrades the system performance. Furthermore, when formula fields are used in queries or report conditions, this further degrades the application performance. The next two sections describe the two types of formula field.
A formula field is said to be deterministic when the value of the formula field changes only when the related record or field gets changed. For example, if we want to have a formula field to show 20% of the amount field, then it can be written as follows:
Formula Field = 0.2 x Amount
The preceding formula will change only when the dependent amount field gets changed.
A formula field is said to be nondeterministic when the value of the formula field changes without the related record or field being modified. For example, if we want to detect whether the logged-in user is the owner of the record or not, the following formula can be used:
Formula Field = IF( OwnerId = $User.Id , true, false )
In the preceding formula field, its value will vary as per the logged-in user even though there is no update on the record.
Tip
To improve the performance, we can contact the Salesforce support team to enable a custom index on the formula field. However, indexing can be done only on the deterministic formula field. You can read more about this approach on the official Salesforce developer blog at https://developer.salesforce.com/blogs/engineering/2013/03/force-com-formula-fields-indexes-and-performance-gotchas.html.