Since I do not have a formal education in software development, I have worked hard for years in order to fill in some of those fundamental gaps and grow in positive ways. I see this all as part of Investing in Myself via Career Calculus, but it has led me to study some people and topics that are quite interesting. One of those each of those is Refactoring by Martin Fowler.
Refactoring has a variety of definitions which range from the mundane to the slighly less mundane. The most applicable and informative I have found is: Improving the design of existing code. Some may see this as worthless and even a waste of time when new development pays the bills, but I believe wholeheartedly that they're missing the point.
This is the same as Martin Fowler's stance. From the beginning of the book, he points out that the true strength of refactoring is being able to have the exact same functionality of code before and afterwards. What's the value of this? Simple. If you can change or completely re-write the underlying functions without having to change anything else, then you can incrementally improve and replace parts of the system during its lifetime. Have you even built a system that didn't change over time? This gives unprecedented power and flexibility to the developers and maintainers of the codebase over time, but this important aspect cannot be met without a set of rigorous automated unit testing that can be run at any time. Being able to test quickly and accurately gives the ability to ensure that functionality is preserved at all times. Therefore, when new development must occur, the code will be cleaner and more flexible for future development.
Fowler describes this foundation and proceeds to provide simple examples of a number of common refactorings. Although some of them include changing the fingerprint of the class, method, etc, the potential problems are mitigated by the compiler and unit testing.
One of the best aspects of this book for me was that “Ah Ha!” moment when I realized that I had done many of these refactorings. This made some of the material remedial, but it never hurts to see that you're on the right cource. Fowler did not write this book to be the definitive source on Refactoring or on Design Patterns such as the Gang of Four's Tome, but as a primer and an introduction from the computer science academia into the software development world. I think he succeeds at doing this and laying a foundation for future work in this direction.
Overall, I found this book helpful and will keep it with my the rest of my Software Development Practices Bookshelf and give it an 9/10 for no significant weaknesses and the usually interesting tone considering the relative dryness of the material. Even if you hate the idea of Design Patterns and Unit Testing, this is well worth it. I also picked up the Refactoring Workbook, so I should be able to review that shortly.
For further information on Martin Fowler or Refactoring, check out his bliki (blog/wiki combination) at: http://martinfowler.com/.