What do you consider before refactoring code?

Question

I've got an application that just shipped. Since I wrote it, I've learned about amfphp and propel. Both would be 'nice' to be used in the application but I can't say that it would be required at this point.

What types of things do you consider before you refactor code?

Answer 1

Should I?

Just be cause I can refactor the code does not mean that I should refactor the code. In many, many cases, there are far more important things that need to be done. Like fixing defects.

Now, if we're talking about refactoring the code because I am already in that particular block of code and working on it as a part of defect resolution or code maintenance, that's a different story altogether. But refactoring just for the sake of refactoring? That sounds like busywork born out of boredom. Surely you don't have an empty defect list.

Answer 2

Have unit tests to check the code after refactoring.

Answer 3

Effort required versus benefit received and where it fits prioritywise with other work.

Answer 4

How maintainable the refactored code will be. Hindsight is 20/20 but with a shipped product, elegant but cryptic design can be a nightmare to maintain. Also, flexibility in the refactored design to allow for feature enhancements is very important.

Answer 5

How likely am I to break existing functionality? Unit Tests are a great safety net here as are automated refactoring tools.

Will the code really be easier to understand and maintain afterwards? This can be a difficult question to answer and it takes experience to get better at answering it.

Answer 6

Create a fork for the current production code base in your source control and do all the refactoring in the experimental branch of the source control.

Answer 7

Unit test would be very nice, but if the code is not covered by unit tests you should have some other means to ensure that you don't break the code. If you can your hands on a copy of production databases, perhaps even some live prod input, you should have a fair chance.

In a privious project we actually recorded all ingoing data for 14 days and saved a snapshot of the prod db at the start and end of those 14 days and we were then able to compare the state of the db using the old code and the new code. But Unit tests sure would remove some of the fear :-)

Answer 8

I sniff the code. If I don't like the smell (in other words, it doesn't smell like me) then I pee all over it until I like it.

Since software techniques need cool names like Agile or Design Patterns, I call this Canine Refactoring.

After rewriting the code I use it for a while myself, Eating My Own Dogfood.

Answer 9

I have to give a +1 to Drejc. The single most reason why not to refactor is if you don't have unit tests. But even that doesn't mean you should not refactor. I should say that my modus operandus is code functionality first and then always refactor to deal with design-debt. Repeat ad-nauseaum.

The "good enough" pattern is probably the most used programming methodology on earth, and that's one reason why our software is buggy and messy. Instead of chosing the least energy "path", we always choose the least energy "step".

But, beware! Refactoring without the proper tools (and this will depend on the language and IDE) is like hammering a screw: you can get there, but it won't be effective (and you can get in trouble).