Book Reviews
Working Effectively with Legacy Code
Misleading title. Should be called ‘Fowler’s Refactoring + Meyer’s OOP + Mumblings’. I wouldn’t like to say I don’t recommend this one, since a lot of people found it useful – which is why I picked it up. However, to me its a time waster, everything this guy says is either obvious, blurry, or an idea from another book.
His ‘techniques’ are things that you already do subconsciously while refactoring code, and they’re really so straight forward they’re intuitive to do. example: how do you test a private method – his solution, is make it public, or rethink your design. I just “love” the rethink your design answer.
I’m not afraid stating that a book s#$%, books are the biggest time wasters when they don’t give you anything new or useful.
Practices of an Agile Developer
This book however was great. Its a light read, very fluid, nice examples. What I liked about it is some of the agile practices it offered to consider, like CI and code ownership, as well as something I already did but didn’t know it was called that way – a ‘daylog’. A daylog is where engineers (in other, more materialistic forms of engineering) keep their problems and solutions log, things that they stumbled on through out the day. The author recommends keeping such in a wiki, available to the whole team.
The author also isn’t afraid to cover awkward situations, like how do you behave when you join a new team? how do you fight the urge to point out mistakes in other’s code? how do you keep meetings short? how do you deal with management?
This one covers so much, in such a summarized form that its able to be straight to the point and be a weekend read easily.
Release It!
Seems to be a great continuation to Practices of an Agile Developer. The title here is misleading too, it should be called ‘Real world practices: the missing manual’. This book is priceless, finally someone went in there and covered real world applications pitfalls, and not only that, he went ahead and formalized a set of patterns and anti-patterns which we all engineers have grown to like. Among the pitfalls the author identifies common software ‘cracks’ – for example, in order to identify weak points in an massively consumed application, you would need to go over integration points – between systems. You would also need to take a better look at anything that involves resources. He shows real world failures, as well as a bearable analysis of them. The patterns are cataloged in a neat way too.
I’m half way through and I’m fascinated, this book would be the best present a developer can get these days – so get it NOW.