||New Reviews| |Software Methodologies| |Popular Science| |AI/Machine Learning| |Programming| |Java| |Linux/Open Source| |XML| |Software Tools| |Other| |Web| |Tutorials| |All By Date| |All By Title| |Resources| |About||
Keywords: Refactoring, reusing code, Java, test-driven development, JUnit
Title: Refactoring: Improving the Design of Existing Code
Author: Martin Fowler et al
Publisher: Addison WesleyISBN: 0201485672
Level: Intermediate/Advanced developer
Verdict: Essential reading
In this classic title Martin Fowler first presented the ideas of code refactoring to a wider audience. It does much more than simply introduce the idea of refactoring code, it also presents related ideas, such as test-driven development, regression testing, code simplification and more.However, it is the idea of refactoring that is at the core of the book. The key idea is that developers should, (and do), spend time reworking existing code, even where that code works. This isn't about improving code for specific ends, such as performance optimisation, though there may be spin-offs that help optimisation. It is about working on the structure of the code so that it is clean, well-structured, easily understood, maintainable (even by the person who developed it). And, so that argue goes, clean, uncluttered code is easy to enhance, maintain and reuse. Testing is central to the idea of refactoring. It's no good refactoring code if at the end of the day you break it. So constant unit testing is part and parcel of refactoring. Self-testing code is essential if refactoring is to be a successful part of your development process. The book, therefore, includes a chapter on using JUnit to build your tests and shows how to combine these into test suites to comprehensively check your work. Indeed Fowler makes a persuasive case for test-driven development - in other words you build your tests before you build the code. In addition to the discussion of the pros and cons of refactoring, there is a solid practical core to the book. A large chunk of the book is a catalogue of refactorings, organised by topic (composing methods, moving features between objects, organising data etc). This catalogue is more than just a collection of patterns, the focus is very concrete. Each refactoring includes sample code to show the problem and the solution, reasons for doing the refactoring, the step by step mechanics and some examples. While the examples and the code are all in Java, the principles extend to any object oriented language, and in particular there is discussion of C++ and SmallTalk. However there is much that can be usefully gained here by any developer working with objects, whether it's C#, Python or VB .Net. When do you need to refactor? This too is discussed in the book, in particular in a chapter co-authored with Kent Beck, where bad smells in code are discussed. The bad smells are associated with code that needs simplifying, and they provide a set of useful pointers. Certainly there was a strong feeling of recognition reading about some of the smells. It's no surprise that this book has been so influential. Just as it's no surprise that it remains controversial. The idea that programmers should spend time 'fiddling' with code that works still makes some people see red (particularly project managers and those people who pay programmers to hammer out code). It seems counter-intuitive - how can programmers really become more productive by messing around with working code - yet this ignores the underlying fact that developers spend more time maintaining code than writing new code. Anything that makes that process more productive, (and more interesting), has got to be a good thing.