The benefits of code refactoring

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

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*

And...you'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.

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

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

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.

I don't know who coined the term,
but I think "refactoring" is not so much a description of the act of modifying code to "optimize", "fix", or otherwise "clean it up", but rather a specific set of (named) mechanical steps or certain strategies for achieving that end.

I find it to be more closely aligned with the notions of PATTERNS and best practice design principles than with the notions of hacking or rework or rewriting.

Learning the vocabulary of refactoring alone tends to help programmers recognize and avoid certain inefficiencies and/or maintenance problems even when they create "fresh" code.

Ultimately, it seems, if one studies the existing refactoring catalogues, one finds that a particular strategy or technique is more appropriate in a certain context than another and vice versa; there are refactorings to use to reverse the effect of another, for instance.

Recognizing the contexts and knowing a specific way to refactor is what the current literature and tools are intended to accomplish.

I recommend everyone who has posted (or will post) a remark to this topic will at least read Martin Fowler's book or visit his website before forming any firm conclusions (cynical or otherwise).

You had this on it's own thread. Absolutley no need to follow me about and post it thetre as well.

Saturation = wet !

Considering that simpler, cleaner structure to the code makes it more secure anyway, I don't see how any programmer with two brain cells to rub together wouldn't get something akin to refactoring in when doing security updates to the code.

It may be the case that your job is succinctly defined as: "produce low cost solutions that meet customer needs", but that is only one of a myriad possible mission statements. In that context, your comments may well be on-the-mark, however...

I think you *may* be missing the point on a few of refactoring's core fundamental tenets.

First, it has nothing to do with "optimizing" in the typical sense of performance or response times. That type of effort is decidedly NOT refactoring. And it is far more disciplined than "tinkering" or beautifying.

Secondly, generalization is only one of many ways to redesign code to make it better. In fact, sometimes, it is better to refactor code that is too generalized (read: confusing) and make it more specific to its use. Also, refactoring and reuse are separate concerns. While I might refactor in order to reuse, I may refactor for many other valid reasons.

Finally, refactoring seems to be more common and enthusiatically embraced by "extreme programmers" and other "agile" developers who would certainly roll their eyes at the notion that you should allocate more time to requirements analysis in order to avoid the need to refactor.

It just doesn't work that way in most real-world scenarios.

Requirements arise (and change) over time; our (and our customers') understanding of a solution grows and changes over time and sometimes grows only as the system is developed or even used.

Refactoring as a disciplined approach allows this evolution to occur without leaving behind a trail of messy code that costs more to maintain than it should. And it provides customers with (at least partial) solutions more quickly than other approaches, requiring significant up-front analysis and design).

I would never recommend "tinkering", nor refactoring code that will never need to be modified (say, a one-off script to migrate some data, for instance), but...

If you have ever had to maintain, enhance, and generally "live with" an application for more than 2 or 3 major releases, then I think you could benefit from knowing how to refactor effectively.

In the end, refactored code is going to produce the lower cost solution for you and your customers.

And if that is your job, don't ignore the tools available.

I suspect from your comment, "why haven't you got another contract to make money out of your time?", that you may be a programmer-for-hire. Perhaps you write the first version, take the money, and run. I've met several such professionals and there's nothing necessarily wrong with that, but... I feel there are different priorities for programmers tasked with maintaining code. For these people, refactoring ultimately saves time and money, lowers the level of frustration, pain, and even (dare I say) monotony that can lead to lower productivity and quality.

So, everyone should consider carefully what their job is; it may differ from yours.

A good set of requirements, they're usually clipped on the to the airborn porcines circling your place of employment.

Refactoring should not change the function of the code. It can make it prettier, faster, more efficient, less bloated, reduce the footprint etc etc. Re-engineering for code re-use does change function.

The test that refactoring has been successful is that the code still does what it did and doesn't do anything it it didn't used to do.

If you embark on refactoring and re-engineering (extensivley) you indeed have forgotten what you are here for. We are meant to engineer solutions not problems.

As to your last point, I tend to add properties and stub out methods for potential but as yet unrequired functions if it's sensible in design terms. It's not something you should spend a great deal of time on, but if the requirement is obvious enough to do on the fly, then it probably will be used.

Not so long back I was called into to re-engineer an application where they now wanted more than one order per customer (I know, couldn't have predicted that could they !). I had to change 99% of the code because of it's scope but all I did was attach order number to the order related items instead of customer which they'd used.

Doing it in the original design would have took several hours, reworking 200 objects and forms, restructuring the database and then scripting the required migration took two months along with the extra functionality the new requirement implied.
Stupid, short sighted and a massive waste of valuable resource to save an estimated two weeks development time.

An attitude like that is responsible for code bloat and bugs. Code has a lifetime that extends well beyond its initial release. I'm sure we all have code we maintain that has a long history. How often has everyone spent large amounts of time tracking down a bug in poorly written difficult to read code? Personally, I like to consider refactoring everytime I have to visit a chunk of code. Most often there is no reason for refactoring to be done. But, when "the code smells", as Martin Fowler likes to say, then it is time to refactor.

In many aspects of production continuing improvement of quality is a given, but in software it's cost.
I use your approach too but only if the code is going to be upadted regularly. Some on the core routines on the VMS systems I work haven't been changed in fifteen years. The later devlopments grafted on top for iterative projects, get refactored/re-engineered on a regular basis.
A good point about the process is it should be ongoing, an extra few hours per development is easily absorbed, go ask management for six months development time to go through the entire code suite though. Don't advise holding your breath waiting for a Yes, no matter how valuable it would be.

I've been programming for almost 35 years now. I've seen a lot of "styles" and "fads" come and go. Recently, I had the opportunity to participate in a couple of projects using the XP methodology. I'm not convinced XP is "the way" -- we certainly had problems with it, even with some very experienced XP mentors guiding us.

But I came out of the experience totally convinced of two things:

Testing, especially unit testing, is essential. We wrote (almost) all our code in "test first" mode. At first this felt really weird, but after doing it for a while, it gives me much more confidence that the code does what I want it to, no more and no less. When I go back to "old" code, the first thing I want to do is to write tests covering the functionality I'm about to change. I just don't feel comfortable without them.

Refactoring is a good thing. As others in this thread have said, refactoring does not mean optimizing, it does not mean generalizing, and it should NEVER change the functionality of the code. After refactoring, the same tests should produce the same results. If they don't, you blew it. This means that refactoring without a good test suite is hazardous.

Like others, I often refactor before making changes. I do this for many reasons. Sometimes I need to break out functional units so I can use them in a different way. Sometimes I need to extract an interface so I can reimplement it for the new functionality. Sometimes I just find that the code I'm working on is not clear and I want to understand it better -- refactoring can be a great way to do this. Sometimes I find duplicated code and want to extract it into one place. Sometimes I find a piece of code that just "smells bad", and I want to refactor it to reduce the smell.

Refactoring, done intelligently and with forethought, can result in code that is cleaner, more elegant, and easier to maintain. It doesn't have to take a lot of time. In fact, with a good IDE with refactoring support, it can be almost instantaneous. Because refactoring does not change program function, it can often be done mechanically. In Eclipse, for example, I can select several lines of code and run "extract method" in less time than it took me to type this paragraph. I can click on a variable and rename it (and all its uses) in 2 seconds. I can push a method up into a superclass or down into subclasses as easily as saying it.

I would say that unit testing and refactoring are two tools that will remain in my toolbox. The more I use them, the easier they are to do, and the more I feel "naked" without them. By refactoring all the time, it's not a big deal, and it improves the quality of the resulting code.

Here's a (hokey) analogy: You can keep your home clean by always putting things away when you're done with them, throwing your dirty clothes in a hamper, putting dishes in the dishwasher, etc. It takes very little time for each of these activities. Or you can leave things wherever you last used them, wait until the bedroom floor is covered in heaps of dirty clothes, and until the sink and counter are full of dirty dishes. Then you put in a marathon effort to "clean everything." In the second case, you'll have trouble finding things you need, the shirt you want to wear today is probably dirty, you've got no clean glasses to drink from, and you exhaust yourself on "clean up day", probably not finishing the job. Which way do you live? Which way would you rather live?

it's funny (but so NOT funny). I've been playing the consulting game for a number of years now, and had a revelation not too long ago. I've worked with guys who can talk a great game, know their technology, can bang out great documentation, and deliver an application that works. These are the criteria on which a person is judged because they all have an explicit impact on profitability/billability/delivery. The problem comes down to the fact that the underlying code sucks. The question we've got to ask is why it sucks.

I don't think these guys are stupid guys; neither are they lazy (in the bad way). They just don't KNOW how to write good code. And how could they? I think of application development as my art, so for me, improving my code, learning to 'grok' OO, etc is the goal rather than a means to an end. Even with my great interest, though, it took me some time before I had an epiphany and really understood the difference between procedural and OO. OO isn't syntax, and objects aren't a convenient way to categorize methods. I think the industry suffers from an education issue -- sadly, this lack of understanding contributes to people questioning the value of refactoring. Ironically enough, understanding refactoring is a good way to improve one's OO understanding.

Take thy face hence !
seems appropriate

Perhaps if you amplified your statement, there could be some discussion of it.

Just a thought

Glad someone brought up the bard, because the "pound of flesh" (Merchant of Venice) analogy is so apropos. Dev without refactoring (which happens more often than not in the real world in my experience) is like taking out a loan -- eventually you've got to repay that loan with interest, and the bill keeps getting bigger and bigger.

Brian well said. However I think the majority of environments do not allow any kind of refactoring to get in. The place where I am currently consulting, keeps having me re-write all of their C++ reports for specific areas of "code improvement". Why, because it doesn't work now, it is slow as anyting, and they want it all on the backend.

It irritates me when I make suggestions and they are ignored or put off. I am constantly told I need to consult with "so-and-so" and with each solutions provided after speaking with "so-and-so" , which keeps coming back to refactoring by the way, I am told to go consult with another person. Of course, none of these people ever get back to me.

So, I have 5 projects 5 months behind schedule and not looking like they are going to move forward anytime soon. I think that the environment of the company has to be open for refactoring to work. Moreso then getting programmers on board to do it.

I've seen more than a few companies invest so much money in a piece of software, that it was cheaper to take it up the a$$.
Classic.
Got put on a project to review a full suite of software for maintaining a spare inventory, purchasing, requirement planning etc. At the start when I was given the task of seeing how well it fit I was told that it did and it would on account of it already being purchased !!!
True as I'm sat here. Good salesman, sh1te IT director. Fit was about 60% !