But When I look at code now I only wrote a year ago, I feel a strong impulse oft to bang my head on the desk. I was trying to deliver clean code, but my programs were rambling, full of long functions and even longer classes with multiple responsibilities, smart but difficult to understand ideas, and above all, lots of comments ...
What Was I Thinking? Well, in fact I thought I was doing a pretty good job. And I'm not saying I was a bad developer then, but this book Showed me a lot of ways to do it better. It is no academic tome, but full of practical advice. And the value of the advice is clear on the first read. The authors speak from experience. They have spent Decades in the Software Industry. They know what works in the long run, and what just will not fly.
The advice here is nothing new. In fact you'll here most of it during your education, if you 're a formally trained developer. Only, nobody tells you why. This book does.
And now for the criticism. I do not have anything new to add - the dogmatism and inflexibility of the author has been Criticized in other reviews, and I agree, indeed he sometimes takes the decomposition too far. You have to credit with the Professional Developers Ability to understand functions with two or even three lines - there is no need to break every piece of code down to the smallest atom. But then, this book is not written for robots, but for thinking, professional, humans. You do not have to slavishly follow every bit of advice. Take your picks.
I use a lot of the techniques from this book in my daily work. Especially I love and apply the "Boy Scout Rule": Leave every piece of code you touch in a better state than you found it in I dare say, it has made me a better programmer.. I'm still working on the rich and popular part, though ...
