Beefy Boxes and Bandwidth Generously Provided by pair Networks
Come for the quick hacks, stay for the epiphanies.
 
PerlMonks  

Re: So I'm in a bit of a quandary

by John M. Dlugosz (Monsignor)
on Jul 08, 2002 at 16:29 UTC ( [id://180216]=note: print w/replies, xml ) Need Help??


in reply to So I'm in a bit of a quandary

Years ago, I did an article for Ed Yourdon's "American Programmer" in the code-reuse issue. I always took the contrary point of view, so I did "the case for starting over". Talking to managers not engineers, I tried to describe the aging process of software and say what to look for that makes maintanence difficult and likely to introduce errors.

"If it ain't broke don't fix it" Well, why are you working on it at all? Adding new features, presumably. A messy program will be hard to extend and this may introduce problems. So if the code is OK (it works), it's still not extensible and doesn't take into account new requirements (or maintainability as a meta-requirement).

So explain that you'll change the overall architecture to accomidate new features, but you'll copy the individual functions (or the algorithm part, if you're adding arguments and making them members, but the keep it simple for the boss) over from the original work, and reviewing each as you go.

—John

Replies are listed 'Best First'.
Re(2): So I'm in a bit of a quandary
by FoxtrotUniform (Prior) on Jul 08, 2002 at 16:42 UTC

    I seem to be "Pedantic About Good Programming Practices Man" this morning, yet another super(?)hero that nobody really wants to see:

      So explain that you'll change the overall architecture to accomidate new features, but you'll copy the individual functions (or the algorithm part, if you're adding arguments and making them members, but the keep it simple for the boss) over from the original work, and reviewing each as you go.

    Don't forget the regression tests. There's little more embarassing than refactoring a program "to improve its robustness", then breaking the code in various subtle ways that slip into production. Properly written regression tests let you say to your manager: "So it works the way it did before, and also does foo, and I can add new features in half the time" with some actual data to back you up.

    See also How You (Yes You!) Can Get Involved and The Joy of Test, among others.

    --
    The hell with paco, vote for Erudil!
    :wq

      I'm big on unit testing. The unit test becomes the regression test after a change is made. If someone reports a problem and it gets down to a small code sample, I add that to the unit test before fixing it.

      Somehow I doubt that his existing code has unit test code with it. So just what is it supposed to do? Mudding the difference between what it's defined to do vs what it just happens to do is one of my pet issues, too.

          Somehow I doubt that his existing code has unit test code with it. So just what is it supposed to do? Mudding the difference between what it's defined to do vs what it just happens to do is one of my pet issues, too.

        In this case, I'd probably try to test against what the old code actually does, especially if it's been in production for a while (with people depending on its quirks). Exercise each feature of the old code (and any combinations that seem to be interdependent), capture the output, and diff. (Not nearly as easily done as said, I know. :-( )

        --
        The hell with paco, vote for Erudil!
        :wq

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: note [id://180216]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others examining the Monastery: (4)
As of 2024-03-29 09:40 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found