•  20-08-2019
  •  | 
  •  

Question

I have heard many developers refer to code as "legacy". Most of the time it is code that has been written by someone who no longer works on the project. What is it that makes code, legacy code?

Update in response to: "Something handed down from an ancestor or a predecessor or from the past" http://www.thefreedictionary.com/legacy. Clearly you wanted to know something else. Could you clarify or expand your question? S.Lott

I am looking for the symptoms of legacy code that make it unusable or a nightmare to work with. When is it better to throw it away? It is my opinion that code should be thrown away more often and that reinventing the wheel is valuable part of development. The academic ideal of not reinventing the wheel is a nice one but it is not very practical.

On the other hand there is obviously legacy code worth keeping.

Was it helpful?

Solution

By using hardware, software, APIs, languages, technologies or features that are either no longer supported or have been superceded, typically combined with little to no possibility of ever replacing that code, instead using it til it or the system dies.

OTHER TIPS

What is it that makes code, legacy code?

As with plain legacy, when the author is dead or missing, you as a heir get all or some of his code.

You shed some tears and try to figure out what to do with all this rubbish.

Michael Feathers has an interesting definition in his book Working Effectively with Legacy Code. According to him legacy code is code without automated tests.

It is a very general (and oft abused term) but any of the following would be legitimate reasons to call an app legacy:

  1. The code base is based on a language/platform which is entirely unsupported by the manufacturer of the original product (often said manufacturer has gone out of business).

  2. (really 1a) The code base or platform on which it is built is so old that getting qualified or experienced developers for the system is both hard and expensive.

  3. The application supports some aspect of the business which is no longer actively grown and for which alterations are extremely rare, normally to fix it if something entirely unexpected changes around it (the canonical example being the Y2K issue) or if some regulation/external pressure forces it. Since both reasons are pressing and normally unavoidable but no significant development has occurred on the project it is likely that those people assigned to deal with this will be unfamiliar with the system (and it's accumulated behaviours and intricacies). In these cases this would often be reason to increase the perceived and planned for risk associated with the project.

  4. The system has/or is being replaced with another. As such the system may be used for much less than originally intended, or perhaps only as a means of viewing historical data.

Legacy generally refers to code that is no longer being developed - meaning that if you use it, you have to use it on its original terms - you cannot just edit it to support the way the world looks today. For example, legacy code has to run on hardware that may not exist today - or is no longer supported.

According to Michael Feathers, the author of the excellent Working Effectively with Legacy Code, legacy code is a code which has no tests. When there is no way to know what breaks when this code changes.

The main thing that distinguishes legacy code from non-legacy code is tests, or rather a lack of tests. We can get a sense of this with a little thought experiment: how easy would it be to modify your code base if it could bite back, if it could tell you when you made a mistake? It would be pretty easy, wouldn't it? Most of the fear involved in making changes to large code bases is fear of introducing subtle bugs; fear of changing things inadvertently. With tests, you can make things better with impunity. To me, the difference is so critical, it overwhelms any other distinction. With tests, you can make things better. Without them, you just don’t know whether things are getting better or worse.

A colleague once told me that legacy code was any code that you hadn't written yourself.

Arguably, it's just a pejorative term for code that we don't like any more for whatever reason (typically because it's not cool or fashionable but it works).

The TDD brigade might suggest that any code without tests is legacy code.

Legacy code is source code that relates to a no-longer supported or manufactured operating system or other computer technology.

Nobody is gonna read this, but I feel the other answers don't get it quite right:

  1. It has value, if it wasn't useful it would've been thrown away long ago
  2. Its hard to reason about because either of
    1. Lack of documentation,
    2. Original author cannot be found or forgot (yes 2 months later your code can be legacy code too!!),
    3. Lack of tests or typesystem
    4. Doesn't follow modern practices (ie no context to hold on too)
  3. There is a requirement to change or extend it. If there isn't a requirement to change it, it isn't legacy code since nobody cares about it. It does its thing and there is nobody around to call it legacy code.

http://en.wikipedia.org/wiki/Legacy_code

"Legacy code is source code that relates to a no-longer supported or manufactured "

Any code with support (or documentation) missing. Be it:

  • inline comments
  • technical documentation
  • spoken documentation (the person who wrote it)
  • unit tests documenting the workings of the code

For me legacy code is code that was written prior to some paradigm shift. It may still be very much in use but it is in the process of being refactored to bring it into line.
e.g. Old procedural code hanging around in an otherwise OO system.

Code (or anything else, really) becomes "legacy" when it has been replaced by something newer/better, and yet despite this it's still used and kept alive "in the wild".

Preserving legacy code is not so much an academic ideal as it is keeping code that works, no matter how poorly. In many conservative enterprise situations, that would be considered more practical than throwing it away and starting again from scratch. Better the devil you know...

Legacy code is code that is painful/expensive to keep current with changing requirements.

There are two ways that this can happen:

  1. The code is unsuitable for change
  2. The semantics of the code have been swapped out to silicon

1) is the easier of the two to recognize. It is software that has fundamental limits making it unable to keep up with the ecosystem around it. For example, a system built around O(n^2) algorithm won't scale beyond a certain point and must be re-written if requirements move in that direction. Another example is code using libraries that are not supported on the latest OS versions.

2) Is harder to recognize, but all code of this kind shares the characteristic that people are afraid to change it. This could be because it was badly written/documented to begin with, because it is untested, or because it is non-trivial and the original authors who understood it left the team.

The ASCII/Unicode chars that comprise living code have semantic meaning, the "why's", "what's" and to some degree the "how's", in the minds of people associated with it. Legacy code is either un-owned or the owners do not have meaning associated with large portions of it. Once this happens (and it could happen the next day with really poorly-written code), to change this code, someone must learn it and understand it. This process is a significant fraction of the time it takes to write it in the first place.

The day you're afraid to refactor your code is the day when your code has become legacy.

I consider code "legacy" if any or all of the following conditions apply:

  • It was written using a language or methodology that is a generation behind current standards
  • The code is a complete mess with no planning or design behind it
  • It is written in outdated languages and in an outdated, non object-oriented style
  • It is difficult to find developers who know the language because it is so old

Unlike some of the other opinions here, I've seen plenty of modern applications that work decently without unit tests. Unit testing still has not caught on with everyone. Perhaps ten years from now the next generation of programmers will look at our current applications and consider them "legacy" for not containing unit tests, just as I consider non object-oriented applications to be legacy.

If few changes need to be made to a legacy codebase, it's better to simply leave it as-is and go with the flow. If the application needs drastic functionality changes, a GUI overhaul, and/or you can't find anyone who knows the programming language, it's time to throw away and start over. A word of warning, however: rewriting from scratch can be very time-consuming, and it's difficult to know if you've replicated all functionality. You'll probably want to have test cases and unit tests written for the legacy application and the new application.

Quite honestly legacy code is any code, framework, api, of other software construct thta's not "cool" anymore. For example COBOL is unanimously regarded as legacy while APL is not. Now one can also make the case that COBOL is consideed legacy and APL not because it has about 1m times the install base as APL. However, if you say that you need to work on APL code the reply would not be "oh no, that legacy stuff" but rather "oh my god, guess you won't be doing anything for the next century" see the difference?

This is a general term thrown around quite often (and quite generically) in the software ecosystem.

Well, I like to think of legacy code as inherited code. This is simply code that was written in the past. In most cases, legacy code do not follow new/current practices and is often considered archaic.

Legacy code is anything written more than a month ago :-)

It's often any code that isn't written in the trendy scripting language du jour, and I'm only half joking.

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top