How often do you refactor code?

g33k · 2008-11-04 03:19:41

<confession>When i started coding, I used to refactor my code with in 24hrs of writing it </confession>
I would write that script, then few hours later would get a better way of doing stuff!

The problem is a lot of time is wasted in re-writing the script and unit-testing it. The software engg books advice to sit for 6-7 hrs designing the stuff. This seems bit tough to me.

How do you manage these? Any recommendations?

How long should the code remain "as it is" once it's written?

Cappy · 2008-11-04 05:16:01

I generally refactor my code when the code needs to be expanded to do something beyond the original scope. For instance, maybe I wrote a program to do X but then later I find out that X is really just a subcategory of Y. It's usually easier for me to refactor the main code than try bending a program past its original limitations. Otherwise, I always end up bug hunting AND still end up with crappy, thrown together code.

Unit Testing isn't really worth it imo, unless you're working with a large program that you plan to patch for a long time. That's where Unit Testing helps - bug regressions and patch collateral damage.

Last edited by Cappy (2008-11-04 05:21:33)

Dusty · 2008-11-04 15:10:13

I spend about 60% of my time refactoring. That makes the remaining 40% at least an order of magnitude more productive. Its never a waste of time to refactor.

Eg: my MSc supervisor told me not to bother refactoring or documenting my code for my thesis project because it was a one off thing that would never be touched again. I didn't listen. About six months later I had to come back to this project unexpectedly, with my thesis deadline looming. I didn't really remember the code, but I was very thankful that I had spent the time refactoring earlier.

I'm a big fan of unit tests too, but Cappy may have a point in them being less useful for small projects. You can usually tell when the threshold is required; your project starts breaking randomly and you just can't seem to keep all the parts in your head anymore.

Dusty

Arkane · 2008-11-04 15:29:35

I usually go full speed without thinking back on anything until I reach the threshold Dusty wrote about, and then cleaning up seems like to much of a pain so I simply give up and start another project. That's probably what you'd call the unproductive hobbyist programmer syndrom...

But if it's something like a school project that I'd actually better finish I usually have a refactoring session every 2-3 coding sessions. I could never really discipline myself to do serious unit testing.

Last edited by Arkane (2008-11-04 15:31:39)

Zeist · 2008-11-04 19:35:55

Cappy wrote:

I generally refactor my code when the code needs to be expanded to do something beyond the original scope. For instance, maybe I wrote a program to do X but then later I find out that X is really just a subcategory of Y. It's usually easier for me to refactor the main code than try bending a program past its original limitations. Otherwise, I always end up bug hunting AND still end up with crappy, thrown together code.

I agree to some extent. When a piece of software that I'm writing gets changed specifications (which happens far too often on some projects) I see it as better to re-do my design and refactor my code rather than to just try to stretch it and bend it into place.

Other than that I think that the biggest needs for refactoring can be avoided with a good enough design and plan for how to write the code. I see it as useful to spend about 70% of the time on any project designing and planning and about 30% on actually coding. It doesn't remove the need entirely though and as such probably about 10% of the coding time will still be used for refactoring even when the specifications don't change since there always seems to be something I forget to plan for no matter how hard I try.

I agree with Dusty on unit tests, they are a real blessing on bigger projects.

g33k · 2008-11-05 14:02:28

Thanks for the insightful replies folks. I will learn to spend more time on design/plan. Don't think there's any escape from that.

vik · 2008-11-09 10:04:21

I refactor my code way too often. The problem with starting a program that you intend to accomplish some task is that you realize that are more and more details you didn't anticipate at the start. As these details start to pile up, I begin to re-organize in my head how these details will be implemented. In OOP, refactoring is a MUCH bigger timesink than in procedural programming. In fact, I'd say redesigning/moving code between/into objects becomes a big deal in OOP. My problem with OOP is that it's almost a requirement to refactor even as you go from idea->implementation. In procedural, refactoring is not a big deal, but debug time is a drawback if you're working with some of the traditional procedural languages. I'm not sure which approach I like better from a purely design standpoint.

Last edited by vik (2008-11-09 10:06:57)

Arch Linux

#1 2008-11-04 03:19:41

How often do you refactor code?

#2 2008-11-04 05:16:01

Re: How often do you refactor code?

#3 2008-11-04 15:10:13

Re: How often do you refactor code?

#4 2008-11-04 15:29:35

Re: How often do you refactor code?

#5 2008-11-04 19:35:55

Re: How often do you refactor code?

#6 2008-11-05 14:02:28

Re: How often do you refactor code?

#7 2008-11-09 10:04:21

Re: How often do you refactor code?

Board footer