Great Programming Books: Fowler’s “Refactoring”
As a part of my goal of learning as much as possible about programming, I’ve set out to read all of the “classics” of Computer Science / Engineering books. And since everyone has their own definition of what a classic is, I’ll share my own $0.02 on the subject.
Of course, if I stuck to the traditional knowledge of the subject, I’d have the same list that everyone else has, so I’ll try to be a little bit more unique through the series and put a few books on there that might not be typical. These are books that improve your perspective on how to design and write software, as well as specific technology books that I find to be really well-written and useful, even if they don’t teach anything specifically about software design.
However, this first book isn’t atypical at all, but it’s something that changed how I approach programming, especially when working with others’ code. And the fact of the matter is, after you’re done learning how to program and start working professionally in the field, you’ll most likely be working frequently with other people’s code. Even if you’re a one-man shop, learning to refactor properly will make adding features to your code easier and cleaner, and helps you to write elegant, maintainable code.
One of the best things that Fowler discusses in the book is, not only what refactoring is or how to do it, but when to do it. his cheat sheet in the back of the book identifies what he calls “code smell” – common code mistakes that result in lousy code, and what to do about them.
If you take away only one thing from this book, it’s this: if you go to add a feature to existing code and it’s not trivially easy to add in, refactor the code until it is. Hacking in code all over the place to make something happen will work for awhile, but you’ll eventually turn the code into an unmaintainable mess.
And if you have room for two things, here’s the 2nd takeaway: unit tests are very important, they let you refactor the code without wondering if you broke anything. If you spend time debugging an issue, it helps you exactly one time. You could spend an equal amount of time writing a unit test that catches the issue, and it helps you over and over.
