I’ve read a lot of Apex Trigger code in my career. While I was consulting, I was able to see the good, the bad, and the ugly when it came to Trigger implementations. For the triggers that took a wrong turn at some point, the story was almost always the same.
The initial trigger was small, and served a single purpose. Over time, as new business requirements emerged, that once tiny trigger started growing and growing into a monstrosity. New functionality was routinely tacked on and technical debt began to accumulate. Now the logic was hard, if not impossible to follow. It was also becoming increasingly difficult to maintain because even the slightest change might mean rewriting the whole trigger from scratch. The tests were unreliable. Trigger logic was executing out of order and governor limits were getting hit left and right. I took a good look at not only the bad triggers that I saw, but the good ones as well. I started coming up with some best-practices that would help developers avoid some of these pitfalls. So before we get into Trigger Frameworks, which is the subject of this article, let’s first talk about some of the best practices developers should be aware of when it comes to trigger writing.Click Here For More
No comments:
Post a Comment