refactoring production code - is it worth the risk??
Author
Part philisophical part technical question I guess [grin]... Do you think its worth it to re-factor production code in a large system to 'clean it up'??? I'm talking about a complex back-end server application if you need to be specific...
This system deals with extracting data from one system, generate requests to an external, then importing data back in... It is very difficult to unit test - because of the amount of volume there is, and how many different parameters there are.. it could take weeks to fully test every use case.. which, even when doing major updates, it is hard to get the users themselves to fully UAT properly... let alone doing unit testing yourself...
So what is your general opinion on situations like this?? and maybe not specifically on back-end server applications.. just in general.. in games even... Is it worth it to clean up code and make what seems like 'simple' logic clean ups / refactoring changes in working production code?? Perhaps only refactor code when you are working on new builds?? Due to the risk involved.. is it better to just leave the code a bit ugly?? But then how do you look at yourself in the mirror or fall asleep at night??? haha... [lol]..
If you can afford the time (and maybe the time of your fellow programmers), refactoring is always good if the code is to be reused, and if it's in uglyness. It can be damn hard, so do only minor changes, one by another.
If the code will be maintained or reused, it is always worthwhile to refactor. If the code is shipped and forgotten, the value declines sharply.
That's an easy one.
Calculate/estimate the cost to do it:
- how many hours of programmer/QA/project manager time to implement it?
- what is the likelihood of failure, how much would that cost the business if it happened?
Calculate/estimate the savings to do it:
- how many fewer hours does it take to maintain over its lifetime?
- how less likely is it that you introduce bugs with the new code, what's the cost of those bugs?
- are you more likely to retain employees because they work with less crappy code? what's the cost saved there via retraining?
- what business opportunities do you gain by being more able to extend your code to accommodate them?
Then compare. It's not going to be hugely accurate, but will give you a quick idea if it's a good idea, a bad idea, or debatable. And it's a good starting point to see why refactoring games is not nearly as useful as refactoring long lived business systems; why refactoring mission critical code is more dodgy than fiddling about with the color of your login screen.
In your particular case, it might be better to leave the structure as is; just make formatting/commenting/localized cleanups.
Calculate/estimate the cost to do it:
- how many hours of programmer/QA/project manager time to implement it?
- what is the likelihood of failure, how much would that cost the business if it happened?
Calculate/estimate the savings to do it:
- how many fewer hours does it take to maintain over its lifetime?
- how less likely is it that you introduce bugs with the new code, what's the cost of those bugs?
- are you more likely to retain employees because they work with less crappy code? what's the cost saved there via retraining?
- what business opportunities do you gain by being more able to extend your code to accommodate them?
Then compare. It's not going to be hugely accurate, but will give you a quick idea if it's a good idea, a bad idea, or debatable. And it's a good starting point to see why refactoring games is not nearly as useful as refactoring long lived business systems; why refactoring mission critical code is more dodgy than fiddling about with the color of your login screen.
In your particular case, it might be better to leave the structure as is; just make formatting/commenting/localized cleanups.
In my experience, large refactoring projects are rarely worth it. Small focused refactoring projects tend to be much more useful. But be sure that you can keep the changes small and focused. It's easy for these things to get out of hand and end up everywhere.
A back of the napkin cost benefit analysis as suggested by Telastyn is a great idea. My general rule of thumb is "Can I reasonably complete and test this in a day." If so, I do what I can to get it added to the project plan.
A back of the napkin cost benefit analysis as suggested by Telastyn is a great idea. My general rule of thumb is "Can I reasonably complete and test this in a day." If so, I do what I can to get it added to the project plan.
In my experience management is virtually always opposed to refactoring. They view it as creating risk for a "working" system in a way that doesn't directly add to the bottom line. No amount of arguing about long-term benefits will be successful unless you can somehow spin in some short-term gains. Keep this in mind when giving your pitch.
My philosophy is that you shouldn't be afraid of it. There really isn't much difference between refactoring and bug fixing. Do appropriate refactoring when you can and the situation warrents. For large legacy systems keep the changes tight - don't try to change an entire subsystem in one shot. The goal is to move toward a better world, not to try to change the whole world at once.
My philosophy is that you shouldn't be afraid of it. There really isn't much difference between refactoring and bug fixing. Do appropriate refactoring when you can and the situation warrents. For large legacy systems keep the changes tight - don't try to change an entire subsystem in one shot. The goal is to move toward a better world, not to try to change the whole world at once.
Anon: Yup, this is my experience, too. They often also dislike when you want to document stuff. Now I hear, that after I have left my last job, they have really trouble understanding my code (it wasn't that bad, but then I was the only one with deeper PHP knowledge; and if I know features of a language that make life easier and rollout sooner, I use them), which would have been no problem if it'd just be documented (esp. the interfacery).
People have so many definitions of "refactor", trying to use the word with any sort of public consensus definition is very difficult.
Original post by graveyard filla
Do you think its worth it to re-factor production code in a large system to 'clean it up'???
It can be.
What are you "cleaning up"?
In the TDD world, there is this simple mantra: Red, Green, Refactor. It means write a test that fails, make it not fail, then make everything you touched a little more beautiful.
Let's get this out of the way: Rewriting code just for the sake of changing it really bad. Don't do it.
I really like the (current) summary statement of refactoring at Wikipedia: Code refactoring is the process of changing a computer program's internal structure without modifying its external behavior or existing functionality ... to improve code readability, simplify code structure, change code to adhere to a given programming paradigm, improve maintainability, or improve extensibility.
The reason to refactor is to make the code a better place for the next person who has to maintain it.
After you have touched a piece of code, review the causes of difficulty and correct them. The Wikipedia list above is fairly concise and comprehensive for those changes.
Without impacting the behavior or functionality, you are doing one of these:
* Improving readability (through renaming, adjusting whitespace, or comments)
* Simplifying code structure (consolidate/extract a class, consolidating/extract a function, promote to base class, etc.)
* Adhere to a programming paradigm (see the book Refactoring to Patterns)
* Improve maintainability (replacing a small block of code that was hard to maintain with something that is easier to maintain)
* Improve extensibility (consolidate/extract into class trees or namespaces or other logical units)
If you have to modify functionality, you are not refactoring.Quote:Is it worth it to clean up code and make what seems like 'simple' logic clean ups / refactoring changesLogic changes are not refactoring, they are implementation changes. You are removing the old implementation and creating a new implementation.
Do not confuse the two. Either you are adjusting your interfaces without logic changes (refactoring), or you are modifying your logic (encoding or recoding).Quote:Perhaps only refactor code when you are working on new builds??Every time you compile you have generated a new build.Quote:Due to the risk involved.. is it better to just leave the code a bit ugly??Good refactorings have near-zero risk involved.Quote:But then how do you look at yourself in the mirror or fall asleep at night???If something tripped me up in code, it must be corrected.
Even if that change is creating some additional comments in the file.
Is there going to be another version released at a later date?
Do you have an adequate test suite?
Do you have a proper source control setup?
Do you have something better to do?
If yes, yes, yes and no, then by all means go ahead.
The best way, of course, is to refactor as you go, and thus not let the code get noticeably ugly. Worrying about a spot here and there is counter-productive, though. We've all written code we're ashamed of. (I do it all the time :D )
Do you have an adequate test suite?
Do you have a proper source control setup?
Do you have something better to do?
If yes, yes, yes and no, then by all means go ahead.
Quote:is it better to just leave the code a bit ugly?? But then how do you look at yourself in the mirror or fall asleep at night???
The best way, of course, is to refactor as you go, and thus not let the code get noticeably ugly. Worrying about a spot here and there is counter-productive, though. We've all written code we're ashamed of. (I do it all the time :D )
Author
thanks everyone... great input by all... pretty much about what I was expecting to hear.. I guess great minds think alike [grin]..
As far as a 'refactoring project'.. at least at my current job, that would never, ever happen. Try justifying to the business that we aren't going to roll out a new piece of functionality because we want to 'clean up' existing code.. They would laugh at us... at best.. More likely scenario, it just makes my boss look 'stupid' to the business... Refactoring is something that we have to do without telling anyone.. lol.. at best, we pad our estimates to account for it, and that's the best and only hope... In some cases we can justify to them that they need to UAT a piece of functionality that was never changed.. and in those cases we are able to refactor.. but they are rare...
So from my experience, I just re-factor code ONLY if I am adding NEW functionality to the code that I want to refactor. And even then - no 'MAJOR', as you said 'changing the world' type refactoring.. just little things that bother my OCD... or, more importantly - only refactor the code that you are about to unit test and have users UAT anyway.. in that case, the refactoring really comes almost 'risk free'.. because at least if a bug is discovered later in production.. there's a entire group of people that will get thrown under the bus for it, rather then just you who wanted to clean up the code.. [grin]
I guess I was wondering, if you completely put the politics aside though, is it really worth the RISK of changing working production code, in cases where you are NOT planning on actually releasing new functionality... in that case.. I'm still wishy washy, even about SMALL and local refactoring changes.. I look at it this way - the code works now, we know that for sure... even touching it to make what could be a SIMPLE clean up has even a 1% chance of causing a production bug... therefore with that logic, we should not refactor at all... I was just curious if others felt that way, but I guess it's more complicated then that...
As far as a 'refactoring project'.. at least at my current job, that would never, ever happen. Try justifying to the business that we aren't going to roll out a new piece of functionality because we want to 'clean up' existing code.. They would laugh at us... at best.. More likely scenario, it just makes my boss look 'stupid' to the business... Refactoring is something that we have to do without telling anyone.. lol.. at best, we pad our estimates to account for it, and that's the best and only hope... In some cases we can justify to them that they need to UAT a piece of functionality that was never changed.. and in those cases we are able to refactor.. but they are rare...
So from my experience, I just re-factor code ONLY if I am adding NEW functionality to the code that I want to refactor. And even then - no 'MAJOR', as you said 'changing the world' type refactoring.. just little things that bother my OCD... or, more importantly - only refactor the code that you are about to unit test and have users UAT anyway.. in that case, the refactoring really comes almost 'risk free'.. because at least if a bug is discovered later in production.. there's a entire group of people that will get thrown under the bus for it, rather then just you who wanted to clean up the code.. [grin]
I guess I was wondering, if you completely put the politics aside though, is it really worth the RISK of changing working production code, in cases where you are NOT planning on actually releasing new functionality... in that case.. I'm still wishy washy, even about SMALL and local refactoring changes.. I look at it this way - the code works now, we know that for sure... even touching it to make what could be a SIMPLE clean up has even a 1% chance of causing a production bug... therefore with that logic, we should not refactor at all... I was just curious if others felt that way, but I guess it's more complicated then that...
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
