Legacy Code & Code Under Test

[dennis-fedco]

Michael Feathers coined the term Legacy Code as being code without automated tests.

 

Still however Legacy Code evokes a vision in me that it is code that is ugly, old, runs on mainframes, and is probably 3000 lines long, uses globals and questionable code practices.

 

But say we take this ugly nasty code, and put it very nicely under test, but without doing any refactoring, other than that necessary to be able to put it under test in the first place.

Now that code is under test.  But it it still ugly.  How would you call ugly code under test?

 

Would you make a differentiation between old & ugly and modern & pretty code if both are under test?

[davidannis]

Would you make a differentiation between old & ugly and modern & pretty code if both are under test?

No, old ugly code is still legacy code in my opinion.

[maxxd]

I've always considered legacy code to be existing code in a project - class code written for version 1.0 and not updated for 1.2 is legacy code. And, honestly, version 1.2 code is legacy as soon as development on 1.3 starts. Legacy code can be ugly or pretty, as can code under test, code in development, or deployed code. Ugly is ugly regardless of state or stage. That's the way I've always thought about it, anyway.

[Jacques1]

I don't see the point of this thread.

 

I mean, Michael Feathers obviously refers to a certain idea when he talks about “Legacy Code”. It's not about legacy code in the literal sense. However, you don't seem to be interested in the idea at all. You just take the words literally, come up with all kinds of random associations and then try to apply Feathers' definition to your own (mis)interpretation of the words.

 

Well, yes, you can do that. But how is this useful? What's your goal?

 

Of course a fresh project doesn't suddenly become “old and ugly” if I remove the tests. And obsolete code doesn't suddenly become fresh if only I add some tests. That should be obvious. So what are we even talking about?

[.josh]

Still however Legacy Code evokes a vision in me that it is code that is ugly, old, runs on mainframes, and is probably 3000 lines long, uses globals and questionable code practices.

This is a bad way to look at it. You are judging the past by present day standards. By that logic, tomorrow you'll be looking down on the standards of today that you are implicitly endorsing by this statement. You need to put yourself in their shoes, with what they had to work with at the time. "Best Practice" is often subjective and highly dependent on current state of technology, current industry standards, current laws, etc.. These things and many other factors change over time and that affects what is considered "Best Practice". Also, I would point out that most of your "pretty 1-liners" you are almost certainly alluding to are really wrappers for frameworks built upon frameworks that require a lot more coding under the hood to make it possible, so that "3000 lines long" statement is especially laughable.

 

And even if we can all agree that a certain piece of code is bad even by proper standards of the time.. you still have to consider other factors, e.g. what were the internal resources/policies behind it? For example, time and time again I see devs of clients publishing bad code and that was a direct result of their hands being tied because of "office politics." Some people choose to sit on a pedestal and claim they'd never compromise for things like that. Others decide that hey, they gave their 2 cents, that's on the boss, sticking to principles don't pay the bills. And chances are, these sort of factors will never be fully known to the public.

 

I guess my overall point here is, don't be so quick to judge a piece of code unless you are judging it within its context. That doesn't mean "leave it be" or "it's okay, don't fix it". If it's not satisfactory to current standards, do something about it. Just save the pretentiousness and snobbery for something else.

 

I echo maxxd. To me, any versioned code that is not the most recent (production) version is considered legacy. Moving from 1.0 to 2.0 could have involved adding new features and nothing in 1.0 version actually changed, so why should 1.0 be considered ugly or bad code? New versions aren't always about fixing bad, broken or outdated code; it's also about adding new stuff, changes due to "politics" or policies, old or new technology, etc..