views:

275

answers:

9

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?

G-Man

+9  A: 

Have unit tests to check the code after refactoring.

Drejc
Good point - by definition you need a way to verify functionality hasn't been broken. I don't think this is the only consideration though.
Jim Anderson
Of course not, but in my opinion this is the most important one.
Drejc
I don't know - if a program needed rework but had no unit tests, I wouldn't skip refactoring, I'd just be careful. I look at them as a safety net, but I would never refactor just cause I had them, or not refactor cause I didn't.
Brian B.
If there is no automated testing then the whole application must be retested by hand (again), which is considerably higher effort than with tests. Of course a final integration test can never be skipped.
Drejc
@Brian B. - Be definition, refactoring requires code to continue to behave the same (despite other changes). If you don't have unit tests, how do you verify the behavior has not changed. What is worse? Poorly written code that works or clean code that does not?
Jim Anderson
+6  A: 

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

Jim Anderson
+1  A: 

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.

omermuhammed
A: 

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.

jussij
A: 

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 :-)

Kasper
A: 

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.

Zan Lynx
So you pee on it, then eat it? It's really hard for me not to down-vote that.
Jim Anderson
+4  A: 

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.

Mike Hofer
I agree refactoring is best done when you're making changes to the code anyway.
tjjjohnson
What about coping with design? If you "never" refactor, just because things work, then you'll surely end up in a big ball of mud...
Hugo S Ferreira
In this particular case there was no mention of design problems - simply that there are some new goodies out there that could be used.
Brian B.
Regarding Hugo's question: There is no silver bullet. The question is, "Should I?" If the design would significantly benefit from the refactoring (perhaps performance or maintainability), by all means, do so. But don't take such an operation lightly. Each refactoring opens the code up to defects.
Mike Hofer
+1  A: 

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.

tjjjohnson
A: 

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).

Hugo S Ferreira