Thanks for sharing your point of view and previous experiences here.
Here are some of the point you can write on:
Anyway, feel free to share any thought, tip or best practice you can think about refactoring issues !
And there is a book, interestingly enough he titled it Refactoring.
What must be the main refactoring goals ?
For me, it's maintainability.
Do you plan refactoring specific code-reviews ?
I do that with standard code-review.
One of the main goals of refactoring is simplifying the code and making it more readable. The goal in refactoring is not to mess with the functionality.
In my experience, I have used refactoring at two level of project development.
First, any time I am working with existing code, I try to find areas to not only add the new required functionality, but to add it in such a way that enhances the current design. To give a more specific example, instead of copying code, or just adding some new methods, see where common functionality can be factored out into a separate class or method and then used by both the new and legacy code. Of course, any existing tests should still work and could possibly have to be modified.
The other opportunity for refactoring is at each "break" in development which typically happens at milestones. The processes with which I have been involved try to plan some time for reflection at these point before plowing through the next development cycle. This is when you get to look back and see how the code can be improved to handle the upcoming goals.
Here's my take on these questions :-)
To remove code smells
Most IDEs will have refactoring facilities to assist with refactoring. But IMHO the essential tool for enabling refactoring is a unit-testing framework like junit
Practice Test Driven Development
Not if you practice Pair Programming
I'd say there are two good times for refactoring:
Refactoring just for the sake of refactoring is often a waste of time; you probably have something more valuable to do with that time.
Excel.
I'd guess that 90% of my refactoring consists of replacing duplicated code with method calls. Unfortunately, there's no tool that I know of to do this automatically (though there are plenty of tools to extract methods and such). And it's hard for the human eye to spot tiny differences in code that's mostly the same.
So I use an Excel template which can compare from two to six sets of code. I use one worksheet for each number of duplicates. In the one for three sets of code, for instance, columns A through C are blank. Column D contains this:
=IF(AND(A1=B1,B1=C1),"=","***")
=IF(AND(A2=B2,B2=C2),"=","***")
=IF(AND(A3=B3,B3=C3),"=","***")
etc. for a thousand lines or so down.
When I have code that appears to be duplicated, I copy each set of code and paste it in parallel columns in my spreadsheet. The lines that really are the same show up as =. The lines that are different show up as ***.
This keeps me from introducing bugs by replacing code that isn't really duplicated. I can then go back and focus on the lines that have differences, often by replacing literals with parameters. (For instance, if one set of code has int myNumber = 5; and another set has int myNumber = 6;, I pull the 5 and 6 out into a parameter so the line ends up as int myNumber = myParam; in both cases.)
After a bit of work, I paste the code sets again and compare. Through this iteration, eventually I end up with = all the way down, at which point the code is genuinely duplicated, and I can replace all instances of it with an extracted method.