Showing posts with label patterns. Show all posts
Showing posts with label patterns. Show all posts

Wednesday, 29 January 2025

Book Review - Salesforce Anti-Patterns


 Disclaimer - I didn't purchase this book, I was given a pre-release copy by Packt Publishing to review

I've been interested in anti-patterns since I read a short article, more years ago than I care to remember, that covered 3-4 of them. When I joined the Salesforce ecosystem, the anti-pattern I saw most of the time was the big ball of mud, which I still reference in talks to this day, "These systems show unmistakable signs of unregulated growth, and repeated expedient repair"- something all of us who have been here for a while are familiar with. I was therefore curious when Packt Publishing reached out and asked me to review the second edition of Lars Malmqvist's book on Salesforce Anti-Patterns - which of my old favourite would I see in there, and what was new in the world of bad solutions to problems that look good at first glance. It's fair to say I wasn't disappointed.

This is a great book for any aspiring architect, as it will teach you the red flags to look out for, which aren't always obvious. Sometimes the problems they indicate take months or even years to appear, but appear they surely will. Recognising this at the outset will save you a lot of angst.

It's also a great book for experienced architects, as it gives you facts rather than feelings with which to argue against a particular approach. Instead of saying that you've seen this kind of thing before and it didn't end well, you can point out the planned (or current) strategy exhibits the classic symptoms of a named anti-pattern, talk knowledgeably about the likely consequences, and advise on alternatives that will lead to better outcomes. I also like that this book isn't entirely focused on programming or technical anti-patterns - it covers the human side of things too, such as communication, collaboration, allocation of work. 

While there are plenty of the old favourites in there, that apply equally to any technology project rather than just Salesforce, there are also a number that you'll only see in a Salesforce project. These are related to specific characteristics of Salesforce like sharing, licensing, the data model, so you are unlikely to encounter them elsewhere.

Each anti-pattern is explained through a scenario, followed by a description of the problem, how it is presented as the solution to a problem, and the likely outcome of using it (rarely good), followed by a description of a better solution. Each chapter concludes with key takeaways and, in a nice touch, advice around the topic area for the CTA review board. A second nice touch is the covering how the introduction of/reliance on AI can bring you into an anti-pattern that you might otherwise have avoided.

One thing I will call out though - the likely real-world experience is that the worst of the anti-pattern is rowed back, but there still isn't the appetite to accept the better solution - life is rarely that neat and tidy. And that's okay - as architects and consultants our job is to advise and make the customer aware of the risks involved. Once that is done, the final decision rests with the customer, and it will be an informed decision, aware of the potential outcome. As long as all stakeholders agree and accept the risk, nobody can point fingers later. Striving for perfection and coming up a bit short is far better than accepting failure at the outset!

The second edition is available at https://packt.link/U7I6R - you won't regret buying it.



Wednesday, 5 September 2012

Book Review - Advanced Apex Programming

Disclaimer: Dan Appleman sent me a copy of the book to review.  I was going to buy it anyway and reading it has convinced me that would have been one of my better decisions.




In a first for the Bob Buzzard Blog, its book review time. If you are a Force.com developer you may well have seen a flurry of activity in early August around a new book by Dan Appleman entitled "Advanced Apex Programming". My curiosity was piqued by the news as it was immediately clear to me (and no doubt many others - the wonder of hindsight!) that there was a big gap in the market here. It received the Dave Carroll seal of approval shortly after, which is more than enough justification to purchase as far as I'm concerned.

The first line of the introduction promises that this book is not a rehash of the Salesforce Apex documentation and it was a relief to find that really was the case, even towards the end of the book which in my experience of development books is when authors can run out of steam and resort to regurgitation.

The style of the writing is quite conversational, which makes the text sections an easy read for a book that covers advanced development techniques and patterns. The example code is often a different matter - not because its badly written, but because it takes (or took me anyway!) a couple of iterations to understand exactly what it is doing. Its worth putting the effort in to understand the code though, as when you do get to grips with it there will be a few light bulb moments when you realise how useful this new technique you have learnt would have been in the past.

Probably the most interesting section for me was Application Architecture and Patterns - there are some great concepts for trigger handling and asynchronous processing. I also learnt a few things about Apex - at least one of which made me want to bang my head against a wall and cry out "why?". I'm pretty sure that knowing these facts will save any reader several times the book's cost.

The final chapter of the book covers patterns and approaches for developing managed packages and is definitely worth reading and re-reading if you are in that space. Dealing with the presence (or lack thereof) of Person Accounts, for example, is something I've never really thought about in this context, even though I have worked with a number of organisations that have this feature enabled.

A refreshing change for a book presenting development best practice was the recognition that:

(a) the point of professional software development is to make money, and
(b) developing solutions for individual customers on a consulting basis is very different to developing applications intended for widespread use

and thus your approach to writing code and tests needs to reflect this.

Finally, a few words for the less experienced. If you are relatively new to the Apex programming language, you'll find large parts of this book a struggle. However, there is one chapter that every Apex programmer should be made to read before being let loose on a live organisation and that is chapter 3 - Limits. Limits are something that all designs should take into account, because regardless of how unlikely you feel it is that your code will ever be used in a way that would breach limits, you can't predict what will happen in the future and what other code yours will be forced to co-exist with. This chapter has some excellent examples of how code can fail to scale and what you can do to avoid this.

I learnt a lot from reading this book, more than I'd expected to, if I'm honest, and I'm sure I'll learn more when I use these patterns in anger and re-read chapters. I'd recommend it if you are looking to improve your Apex development skills (and if you think your Apex development skills can't be improved, then you should definitely read it!).