Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

ziggy (25)

ziggy
  (email not shown publicly)
AOL IM: ziggyatpanix (Add Buddy, Send Message)

Journal of ziggy (25)

Wednesday March 02, 2005
12:08 PM

Refactoring: Making your code suck less

[ #23459 ]
For the last six months, I've been working on a project at $WORK to bring order to the main webapp our team has built over the past N years. My task was basically, "make this code suck less", modulo some constraints like use the same environment, and make the new code work side-by-side with the old code. Fair enough, just a [long overdue] refactoring project.

The project has gotten to the stage where we are starting a slow rollout of this codebase, and now documentation is the focus. The problem is, I've got all of this new code that uses some OOP-fu to clean up some long-standing issues, and there's no clear way to document the little beast. It's the Inside Macintosh[1] problem all over again!

Feels like it's time for a little more refactoring. Time to clean up the new code so that it does the same thing, but is easier to document and extend. That'll make my immediate job easier, but also make it easier for new developers to adopt.

Why more refactoring now? Because refactoring is like an oil change for your car. The longer you delay, the worse it gets, and the more damage it does. Delay long enough, and everything seizes up, which leaves you two options: major remediation, or a total replacement. Refactoring (or regularly changing the oil), is a minor cost to pay for ongoing high performance.

The XP folks say that a day without refactoring is like a day without sunshine. That's a pretty extreme view to take when dealing with management that treats refactoring as expensive retrograde work producing no net value. (Fortunately, I'm not in that position. Now.) Maybe the answer is the 10% solution: can you afford to spend one day every other week to make your code suck less? Not fix every problem, but just make it suck less?

 

[1] The original edition of Inside Macintosh (later known as Inside Macintosh, Volume I) was a reference book of 25 chapters, each written with the expectation that you had read and fully understood the other 24 chapters it built on.

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • You realize of course, that your focus on refactoring is nothing more than a reflection of your bloated ego [pbs.org].

    And no, I'm not serious. Cringely was smokin' crack.

  • Funny how the structure of the code requires more adjustment than the algorithms themselves. And if you're like me, after you take something apart and put it back together again, you have a few dozen screws left over. And sometimes it is easier to fix something than to document it broken - but usually not. And I won't dredge another buzz-phrase into it, but it's nice if something has already been documented and you can refer to the documentation for another piece of code (even if that thing being documented