[quietbritishjim]

I realise this is an unpopular opinion, but I really didn't like the previous book. Don't get me wrong, I definitely think refactoring is a good thing (in moderation!). But Fowler presented a list of possible refactoring operations, including step by step instructions... for very trivial things.

In the introduction he drew comparisons with GoF design patterns book, saying he wrote it hoping people would refer back to it as they do to that book. Yes, sometimes I need to rename a function or split it in two, but do I really need to dig out a reference book to look up how to do that? And the comparison to design patterns is crazy, those are at a far higher level of abstraction and are correspondingly less obvious (and more interesting).

[hyperpape]

I never read more than a fraction of the first edition, but I found it valuable. The key idea was that refactoring was a methodical, careful process that consists of steadily taking the code from one working state to another. At the time, refactoring was a dirty word at my company, and people didn’t distinguish it from rewriting code in any arbitrary fashion.

[quietbritishjim]

This sounds mostly like the first chapter, which was the bit I enjoyed the most. That was about automated testing, and a whole book about that might've been quite useful.

[hyperpape]

Automated testing is great, but you can apply the core idea to code without automated tests. The difference is that you have to be even more mechanical and cautious.

In addition to the principles about refactoring, reading a few of the examples helped to drive in how methodical it was.

[tankerdude]

I've found out that in my decades of software engineering that what I take as trivial and simple actually isn't for folks who haven't really delved into it or they are mid or junior level engineers.

I'd rather do skim reading on stuff that I already know than for them to skip over it just in case there was a fundamental issue that was missed (or deemed trivial).