General discussion


The benefits of code refactoring

By Mark W. Kaelin Editor ·
Refactoring is, very simply put, the revision of code in order to make it more efficient, maintainable and easier to work with. This TechRepublic download covers the subject in detail:

The download makes the case for code refactoring, but how many developers in the TechRepublic community actually take the time to do it?

This conversation is currently closed to new comments.

42 total posts (Page 1 of 5)   01 | 02 | 03 | 04 | 05   Next
| Thread display: Collapse - | Expand +

All Comments

Collapse -

Well I do

by Tony Hopkinson In reply to The benefits of code refa ...

when allowed of course. Or when I can get away with it. A lot of the time it's just quicker to rewrite the code to your latest understanding of it's required function(s), than to try and bend it to make it work.

Collapse -

rewrite vs "enhancements"

by jck In reply to Well I do

I spent over two years recently writing the work order system for a power company to do line work. Toward the end of the contract, there was suggestion of "enhancing" the software to make changes to align it "procedurally" with another division of the parent corporation who does power in another area of the country, which was supposed to "improve" it.

The DBA and I looked at it, and concluded it would be faster just to re-develop the application in .NET rather than retrofit the VB6 application with upgrades, modifications and then test it properly.

Not to say that sometimes modification isn't the more viable and most expedient solution...just my experience that unless it's a very localized mod, it is usually only means far longer development time and headaches over what partnering functionality must also be re-examined in the process.

As for re-factoring...whatever happened to just calling it an "improvement" or "optimization" or making it "more readable"? I think it's a term to give management a way to make senior management feel they're approving important work.

another two bits given

Collapse -

Me as well

by jck In reply to Well I do

I try to revisit code when there is time, which is not often. Especially if it has a history of reports from the end-user that it has something like a "performance" issue, i.e.- queries are slow, etc. Then when there's an open window of time while I'm waiting on decisions for a current project to proceed, I do that kind of thing.

As for making it more "friendly", I don't generally remark or document my code well. If I had to go back and write in small briefs for every code module and procedure I've ever written in 15 years, I'd have wasted probably 5% of work hours...not only because of having to write them with the original code, but also having to go back and make sure I change or add info to it to keep it in line with current versions as the functional requirements change. Yes, I have worked for a lot of people who don't define their processes to me on the first design, or change the process in the middle of the coding. *sigh*'re absolutely right..sometimes the rewrite is preferable...especially when the project has grown to a point that shared code re-writes would require extensive design analysis, re-code, and re-test.

Collapse -

Not a maintenance programmer anymore..

by Dr Dij In reply to Well I do

Wow, now I'm a 'Refactoring Engineer'.
I should ask for a raise.

I knew there was a reason people were interested in XP, because they don't need to maintain code anymore, (or do any designs), just 'refactor it'.

There's a good book explaining problems with XP. And a hilarious chapter about the XP picnic, where nobody plans ahead.

Extreme Programming Refactored: The Case Against XP
by Matt Stephens and Doug Rosenberg
Apress ? 2003

Collapse -

Yes but not often

by StephenCairns In reply to The benefits of code refa ...

I would say that its a rare luxury to get the chance to revisit the existing satisfactory code, at least with official sanction anyway. But if I find code that could be rewritten with elegance and I have the time then I do it. Anyone not do this?

Collapse -

Depends on how you define elegance

by Tony Hopkinson In reply to Yes but not often

If you mean readable, uncomplex and easier to maintain then yes.
If you mean clever, complex and obtuse then as much as I enjoy coming up with such things, using them in corporate source is a hanging offence in my book

Collapse -


by apotheon In reply to Depends on how you define ...

Elegance in code is related to simplicity of design without loss of functionality or extensibility. Remember, when writing good code, you're not done when there's nothing left to add: you're done when there's nothing left to take away.

Collapse -

As Necessary, When Necessary

by sbockelman In reply to The benefits of code refa ...

A good time to refactor, especially in environments where this may be frowned upon as "rework" (to the unititiated or old-school managers), is when...

- fixing a bug
- adding a feature
- addressing performance concerns

I often start these activities by refactoring. That is to say, I follow the methodical approach that is the DISCIPLINE of refatcoring, not that I simply rewrite the code (those are different things!)

In each of these cases, I am going to need to write new tests anyway, so this gives me a prime opportunity to perform the refactorings. Also, since I expect to refactor in these cases, I can provide time/effort estimates that include this work (and effectively 'hide' this activity from the unenlightened if necessary).

I may also refactor when READING some code, as a way of "making notes on my understanding" of it, but this is not necessarily a necessary case.

I do not refactor when...

- The code is already as simple as it needs to be.
- There is other high-priority work outstanding (that can be done effectively without first refactoring some releated code, that is)
- There aren't sufficient tests or other verifications available to ensure that changes do not have unintended side-effects (and I cannot create them for some reason)

I highly recommend Mr. Fowler's introductory treatise and catalogue of refactorings. Read it in conjunction with literature debating extreme programming, agile methods, and test-first development. (Notice, I said "debating", because I think it is valuable to examine various points-of-view). I think this could help anyone better understand refactoring and the contexts in which it is popular and useful, ncluding myself (I mean, what do I know?)

Otherwise, I thought this particular article was perhaps a little weak. The resources may be more valuable than the article itself. But as an overview, I suppose, if the point is to raise awareness...that's all good.

Collapse -

sounds like

by jck In reply to The benefits of code refa ...

upper-level management and business-heads have come up with "code refactoring"...a term that makes them sound like they're tasking their programmers to do some major, algorithmic, scientific re-work that will reap great benefits.

What ever happened to just saying "optimizing and documenting code"?

I need another cup of coffee...

Collapse -

Well as I understand it

by Tony Hopkinson In reply to sounds like

The discipline of re-refactoring arose from , porting to the new in thing languages.
Or when somebody realised how crap an application designed with RAD was. Before that it was called Phase II.

Back to Web Development Forum
42 total posts (Page 1 of 5)   01 | 02 | 03 | 04 | 05   Next

Related Discussions

Related Forums