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!).