Jump to content

What is the purpose of refactoring software?


dennis-fedco

Recommended Posts

This will be somewhat of a brain dump with somewhat vague questions.  To summarize it right now, something about "refactoring software" has been bugging me.  The length of the process, the work it takes, and the time, and the "no immediately visible results" that it produces.

 

There have been numerous questions on "do I refactor or rewrite".  Depending on circumstances, one choice may work better than another, although historically for working projects (projects people are using continuously), refactoring seemed to do better, since it does not break things as much as rewriting does.  And when things break all at once, such as when introducing a rewrite (which most likely has different behavior, UI, feel, workflow, etc. etc.), people tend to get upset.

Well, refactoring seems to smooth out the 'upsetness' over a much longer period of time.  People change as software changes, and each change is not as abrupt as with a rewrite.

There are books written about refactoring software.  That process takes time and work, `while not changing the functionality of the software`.  Little improvements can be done here and there, but the main point becomes improving the internals of the software without affecting the outside behavior, the user experience.

From the business end, *there are no changes!*.  We have developers *doing busy work* without showing anything to the business, until perhaps much later.  Is that bad?  Where I work, I have business people scoff at "what have we been doing" quite regularly, and saying things like "add convertion from one unit system to another?  Just put it in!"  Which ends up me staring into vastness of legacy code and taking 2-3 weeks to "put it in", what in someone's mind takes a day at the most.  But that's cuz maybe I'm slow, but I chose to refactor relevant code first, at least moving View items into respective view containers as a first step.

What is the purpose of refactoring software?  What, per se does it make better?  What expectations can be set?  What do I do next time someone says "it is taking too long", other than saying ... cuz I am refactoring!

Link to comment
Share on other sites

This is a problem most employed developers experience. Clean code, refactoring, testing, .., all those good bits do not convert in more ROI. "It works!" is the one and only measure in our industry. I have worked with cowboy programmers, and even with people who write stuff like:

 

function a($b, $c) {
  // do stuff with $b and $c, and create variables like $d, $e, $f, ..
}
Not example function names, literally named like that. When I complained about it they replied it works and it goes faster then what I wrote. A part of me simply wanted to do the very same thing, write code just the same way until it was such a ball-of-mud that I could go to them and say:

 

NO I CANT FIX IT, NO ONE CAN! BUT HEY YOU KNOW WHAT IT IS FAST

Link to comment
Share on other sites

This thread is more than a year old. Please don't revive it unless you have something important to add.

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.