Refactoring: Improving the Design of Existing Code

Apologies for the lack of postings lately. The good news is that I'm insanely busy (how I like it;) and have gathered a few bits of wisdom to pass along for your consideration.

I'm just finishing up Martin Fowler's book, Refactoring: Improving the Design of Existing Code. This book has fundamentally changed the way I approach application architecture and development. I've begun to employ its recommendation (even before I finished the book!) and have already reaped huge rewards in the quality of my code.

The book is a library of refactoring techniques. Like all good books, some of the concepts were already familiar, others were new and thought-provoking. As developers, we all have a concept of what refactoring is. It's nice to see it formalized in this book.

Some of the key tenets:

• You spend 10% of your time creating code and the other 90% maintaining it. It makes sense to put in the extra effort to make it readable as well as functional.
• The code you write is not for the compiler. It is a communication medium between you and other developers (or future-you).
• It's better to write 10 lines of code that are easy to read and understand, than three lines that require 15 lines of comments to explain. OK, your SWF might be 50 bytes larger. I won't tell if you don't.
• As you refactor, you'll end up needing less and less comment blocks because the intent of the code becomes self-evident (by descriptive class, method and variable names, for example).
• A big one for me involves the planning stages of application development. It says that getting into too much detail, at the design stage, regarding how an application will be coded is usually wasted effort. Better to have a basic game plan and a team of developers that have the skills to spot problems and refactor them during the coding process. Mix this with some well-defined best practices and you've got a potent recipe for good code.
• Finally, if you're spending more than 6 hours a day programming, take the last hour to refactor the code you've just worked on (Oliver-style). Or start the next day with an hour of refactoring (Chad-style).

At first it seems like extra effort to enforce all these principals, but I've already seen remarkably good code result from this discipline.

The books is available at:
amazon.ca
amazon.com