Pablo Gonzalez’s Post

Read AutoRABIT's CEOs words carefully. Somehow "safety" is rarely considered when talking about Salesforce DevOps yet it's the one the hurts the most when done wrong. There's a ton of innovation we are delivering for our customers in the near future.

You should not split a business process across multiple Apex triggers on different objects. If you do this, it means that by design the process is not atomic as any part of the process could be invoked independently or in the wrong order. Also, if one part fails how do you roll back the entire operation across different triggers? How does a new developer know that multiple Apex triggers are meant to be understood as a single business process? Instead, you should group that logic in a single deep module (class or method) and encapsulate all the business logic for that process, end-to-end. This way you have control of the entire operation and in one part fails you can easily roll back to a previously known state. It also makes it explicit for other developers that the business logic is meant to be interpreted as a whole. Finally this brings cohesion to the module: logic that changes together should be placed together. #CleanApexCode

This event is set to become one the largest in Europe. Who's coming as a speaker?

Some people think I quit Salesforce DevOps to focus on Apex and writing my book. The truth is I have been on stealth mode for a few months building an incredible product at AutoRABIT . I haven't been this excited about a product since I built HappySoup.io I can summarize it in one word: Disruption

Everyone talks about simple try/catch statements for catching DML exceptions in Apex. What no one talks about is what to do when you get something like the example below: You made a simple update on an Account record and an exception is thrown multiple levels deep because of triggers in related objects. Think about it: - Who should handle this exception? Who owns it? - Should the update on the account fail because of an exception 4 levels deep on an unrelated object? - How does Apex know when one business process ends and another one starts? - Is the entire operation meant to be atomic? These questions are harder to answer but far more interesting!

How to properly use comments and when to avoid them is cause for endless debate in online communities. In this chapter, I start by debunking 2 popular misconceptions about comments: 1) Comments lie 2) Self-documenting code This is a preview of my upcoming book: Clean Apex Code, Software Design for Salesforce Developers https://lnkd.in/eFgj6j3H

I don't have a Dreamforce '24 selfie as I'm staying at home busy writing the upcoming Clean Apex Code book. To compensate, here's a picture from Dreamforce '13, more than 10 years ago! I had braces, no kids and no idea what Apex or DevOps was. And AI was a thing from the Terminator movies...

Aha! Comments in Apex Code Sometimes you are reading a piece of code that is really hard to understand. After reading for a bit, you may go “Aha! that’s what it does!”. Right there and then, add a comment explaining what you just figured out. Think what comment would’ve been useful 15 minutes ago when you started to decipher the code. That's a great comment. -- This is an excerpt from Chapter 6 of my upcoming book: Clean Apex Code. The chapter is titled "Comments don't lie, programmers do" 😊

I’m working on my book, Clean Apex Code: Software Design for Salesforce Developers, and I want to address something: many times, people get hung up on code aesthetics like where brackets go or whether you use camelCase or PascalCase. These details are important and they help with readability, but they don’t tackle the real challenge of *reducing complexity in large Apex codebases*. If you’re looking for a book on purely code aesthetics, like where to place your brackets, whether to use tabs or spaces, or whether to use semicolons in JavaScript code, this book is not for you. This book is for those who want to take their Apex skills to the next level by learning core software design principles that will serve them well not only in Apex but across other programming languages throughout their career. My book goes into the principles that really matter, like when to split methods, how to make methods deeper and more meaningful, reducing complexity, and when using comments is appropriate. Yes, there’s a chapter on naming best practices, but that’s just the start. The book goes on to cover advanced topics like object-oriented programming, modularity, cohesion, software design principles, and modern Apex enterprise patterns. These are the principles that make the difference between Apex code that scales and Apex code that is riddled with tech debt. Aesthetics matter, but they’re just a tiny piece of the whole. My focus is on helping you write Apex code that lasts.

For the first time in years, I will not have to travel to go to an amazing and large Salesforce community event. I'm really excited to attend the first ever Irish Dreamin' 💚 Who's coming to Ireland next year?