I have copied the following over from the welcome thread because I think it bears some discussion.
Karthick Sundaram wrote:Welcome Chris, I have been on three greenfield software projects so far and all of them had degraded their initial design at some point either due to developers/architects leaving or because the design/code couldn't evolve because of other pressures from project management. But later on we come to the point where it becomes unmaintainable. That's the point when management is ready to listen. If we said that we could refactor and bring it to safety, that would be a relief for them. If we were not able to refactor, then either the project fails or if it survives, it is painful for the developers like long work hours for forever. I have seen that in two of my three projects so far. lucky enough to have escaped the first one. So refactoring is a serious need for developers like me.
Refactoring only when you have an unmaintainable mess is like saying you need to "clean up" the house only when you literally can no longer move around because of all the filth and rubbish you have allowed to accumulate.
Refactoring is an activity that you should be doing constantly, and if possible, for every few lines of code that you write, with "few" being in the ones or tens rather than in the hundreds. If you wait until you have a big mess before you think about refactoring, it's almost always going to be a daunting task at best. At worst, it will be impossible.
I maintain that if you only do Rename, Extract Method/Field/Constant/etc., and Composed Method refactoring 90% of the time as you write code while doing TDD then you can avoid almost all problems with code maintenance and design.
I say "while doing TDD" because refactoring is done at a very specific time in this practice and it should be done in a very purposeful and considered way.
I agree wholeheartedly! The sooner you refactor, the easier it is. Seriously.
Before you write a single line of code, take some time to do a little 'mental refactoring'. Go through the design in your head, think about how easy it will be to understand, to test, to extend, to change in response to changing requirements. Think about how requirements are likely to change in the future. This is the easiest refactoring of all, because you don't even have to change any code!
Refactoring is still pretty easy until you commit the code and share it with your co-workers. Take a moment to look through the code and refactor it for readability before you run that 'git push. Try to anticipate what the code reviewer is going to complain about, and fix it before they get the chance.
After this point, refactoring becomes a little more tricky because somebody might start depending on the code you want to refactor. You'll need to let others know what you're doing, perhaps via code reviews.
After that, as time passes, more and more code will end up depending on and coupling with your code, so it will become more and more difficult and risky to refactor. The moral of the story is, refactor as soon as you can!