I have a very cluttered code, and the current revision is almost complete, meaning all functionalities i wanted for this revision/sprint are done.
Should i finish this revision as it is and refactor it later or should i refactor it right now?
views:
123answers:
7
+2
A:
If you're on a deadline and it's something soon, it's probably not a good idea to really make massive changes. If you think the cleanup is manageable, go for it. What I would recommend you do is branch your current code base and do the refactoring in there. Then merge it back. Or you can use the branch as your release branch and refactor in trunk. The longer it stays cluttered, the harder it will be to maintain, so do it sooner than later if you think it's necessary.
SB
2010-04-24 23:20:45
+1 Seriously, I just spent my last two hours in a very ugly codebase!Refactor it right away. Once the code gets nasty, bad code starts to pile up and the new code you add starts to code around the shortcomings of old code, making it in turn bad code too. At some point you simply stop caring since the only options is a complete rewrite and are stuck in maintenance-hell.
Tigraine
2010-04-24 23:26:38
I have functions doing a lot of stuff at the same time, because i thought it was "faster if i did it here inside this function". But now it reached a point where i do not want that specific function doing more than 1 thing. Almost all functions are like that. I'm seriously thinking about chopping everything and define a good code structure,very modular and OO.
Jorge
2010-04-24 23:30:41
Sometimes that's the best refactoring. After finishing a project/iteration/whatever you always end up smarter as to how you should have done it, and it will go faster because you now have the whole picture. However a full rewrite is not always feasible due to other reasons. Just do a cost/benefit analysis.
Nick
2010-04-25 13:07:15
+2
A:
If the question regards making something easy to manage and use, and the question is "now or later", the answer is always NOW.
Projects that are "almost done" have a habit of taking longer to finish than anticipated.
Remember: The first 90% of the code takes the first 90% of the time, that last 10% of the code takes the last 90% of the time. =)
Chris Cooper
2010-04-24 23:22:44
+4
A:
There is no "correct" answer for this, it's really a matter of priorities?
- Does the code work?
- How well does it work?
- Are there deadlines?
- Is release more important than quality?
You have to consider all of these questions together. I typically find that refactoring can, especially on larger projects be much more time and effort then you think it may be. You may also be breaking things (this is where unit tests are amazingly helpful).
I typically will strive for release on commercial projects then refactor unless there's major problems with the existing code.
Aea
2010-04-24 23:23:32
It's a small project so far. The code works, but i often find myself commenting and uncommenting things to see a "different output". I think with a better structure i would just have to use different methods instead of the comment/uncomment procedure. No deadlines, quality is top priority.
Jorge
2010-04-24 23:36:14
@Jorge Quality top priority? Refactor now. You make the code more readable which allows you to spot errors more easily.
extraneon
2010-04-25 16:51:53
+2
A:
If you are coding to a requirement/api that is stable, there is no reason not to refactor now, if you have time.
If the api/requirements are a moving target, whether to refactor or not is going to be a situational and subjective decision.
BUT.....
If you haven't done so yet, write tests that give wide coverage before refactoring.
I cannot stress this enough.
Sky Sanders
2010-04-24 23:24:46
A big +1 for this. Refactoring without tests (especially without automated tools) is risky. Yet another reason to favor TDD (or at least writing the tests along with the code).
TrueWill
2010-04-24 23:27:13
@true - true that, but tests after is better than nothing and yields a lot of the same benefits as test first.
Sky Sanders
2010-04-24 23:28:34
+2
A:
Do the refactoring as part of your implementation. Have full unit tests so you can refactor without introducing defects.
zumalifeguard
2010-04-24 23:36:43
+1
A:
Refactor now. Procrastinated refactoring is difficult refactoring. Today the code is fresh in your mind and unsullied by tomorrow's changes; it's as ripe as it will ever be for refactoring. Ripe but not yet rotten.
Carl Manaster
2010-04-25 16:50:08