This week's book giveaway is in the OCAJP 8 forum. We're giving away four copies of OCA Java SE 8 Programmer I Study Guide and have Edward Finegan & Robert Liguori on-line! See this thread for details.
It's basically a set of methods you can use to simplify your code, making it easier to test and maintain. XP suggest that you write a test, code, refactor, write a test, code, refactor, etc. In other words: first define what you want to achieve, get it working next and then make it clean and maintainable. Refactoring by hand is a chore, a good way to learn it is to get a nice IDE with refactoring support. IntelliJ IDEA, for instance. Here is a list with many refactoring tools.
Originally posted by Wouter Zelle: It's basically a set of methods you can use to simplify your code, making it easier to test and maintain. XP suggest that you write a test, code, refactor, write a test, code, refactor, etc. In other words: first define what you want to achieve, get it working next and then make it clean and maintainable.
You don't need to use this development cycle to get value from refactoring, though. Refactoring is accommodating the fact that program design invariably degenerates over time. So if you have to clean up the code regularly if you don't want to end with a "ball of mud". The "Refactoring" book is showing indications of design problems (so called "code smells") and providing solutions to remove them in tiny little steps. The purpose is to evolve the system to a better state while sustaining its perceived behaviour and having a working system every couple of minutes. Like the Design Patterns book, it also gives the patterns names (like the "Jealousy" code smell iirc), simplifying communication between developers. IMO the book is a definite must-have.
The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
Joined: Apr 12, 2002
You don't need to use this development cycle to get value from refactoring, though.
True, it's just a guideline. I usually just refactor when a smell hits me in the face. The point I was trying to make was that refactoring, coding and testing are strongly related. Refactoring makes your code easier to test and expand with new features. So you should really be doing it while coding. Don't create seperate tasks in the future where you will be refactoring parts of your code (unless it really is a mess ), do it when you see a problem. Refactoring is coding.