|
Legacy code is software written some time ago that you are required to maintain because your users/customers require it. Legacy code is often maintained with an older generation of tools (Visual C++ 6, for example) or even programming language (C rather than C++). It's the type of code that you might want to rewrite using current techniques or tools, if you had the time or resources.
BTW: I think your question was an honest one; whoever down-rated your post needs to remember that our field is overrun with jargon, and not all of us know all of it.
Software Zen: delete this;
|
|
|
|
|
|
|
I don't. For me it is an external library that ships with the IDE that I use...
Behind every great black man...
... is the police. - Conspiracy brother
Blog[^]
|
|
|
|
|
No. Our current development uses MFC throughout. Given that the majority of our application is doing multithreaded process control, we've had our doubts about using .NET. This is a decision we will probably re-evaluate once Visual Studio 2005 is released, given that Microsoft is deprecating use of MFC in its entirety.
Software Zen: delete this;
|
|
|
|
|
I am working on a rather small developmentteam at the moment 
This has brought me one big advantage, we don't need to support legacy systems, since there isn't one for the solution we are building...
Normally I would spend les than 20% of my time on legacy code. The main reason is that we are a young company and we only have like 5 big solutions to work on. All in .NET
I really hope I can keep up the 20% rating, since any higher rating would mean we are degrading our thought that we should alway innovate.
WM.
What about weapons of mass-construction?
|
|
|
|
|
The need to support legacy code varies with your market.
One of our current products still supports hardware developed in the early 90's. Since some of our customers are still using it, we are required to support it. Even though that hardware is 'end-of-life'd as the parts that go into it become unavailable, newer generations of the hardware support the older data formats.
If we were to abandon support for one of these older formats, our customers would be inclined to replace our equipment with someone else's, someone more inclined to long-term support.
Software Zen: delete this;
|
|
|
|
|
But it doesn't feel like legacy: we introduce so many features, and often change so much our code (e.g., we ported, erm, rewrote, everything in C# back in 2002) that the ammount of legacy code is less than 10%.
I see dead pixels
Yes, even I am blogging now!
|
|
|
|
|
|
That depends on when it is written. People still use VC6 to write code these days...
Behind every great black man...
... is the police. - Conspiracy brother
Blog[^]
|
|
|
|
|
Bob Stanneveld wrote:
People still use VC6 to write code these days...
People still use COBOL, Fortran, BASIC etc., don't they?
|
|
|
|
|
For maintenance some have to, but I don't think that people use it to write complete new apps these days.
Behind every great black man...
... is the police. - Conspiracy brother
Blog[^]
|
|
|
|
|
Bob Stanneveld wrote:
For maintenance some have to, but I don't think that people use it to write complete new apps these days.
I have to use/support VC++ 6 as it's the lowest version we intend to support for our products. There're too many devs out there that continue to use VC++ 6.
|
|
|
|
|
Nishant Sivakumar wrote:
I have to use/support VC++ 6 as it's the lowest version we intend to support for our products. There're too many devs out there that continue to use VC++ 6.
Here at the company where I do my internship, they still use VC6 to develop embedded systems. I wouldn't call the code that they write legacy code from the beginning.
A definition of legacy code could be:
Legacy code is code that is used in a project, but was first developed in (originally written) in a previous project.
Behind every great black man...
... is the police. - Conspiracy brother
Blog[^]
|
|
|
|
|
Bob Stanneveld wrote:
A definition of legacy code could be:
Legacy code is code that is used in a project, but was first developed in (originally written) in a previous project.
Sounds clear enough.
|
|
|
|
|
I was using VC++ 1.52 just over a year ago!
Kevin
|
|
|
|
|
I was using it two weeks ago to check that the project I'm porting still rebuilt correctly for the original platform.
The project is porting a customer's software from Symbol's Series 3000 DOS terminals to new Windows CE-based Symbol MC3000 hardware. We still support Series 3000 hardware with our thin client software (for which I'm primary maintainer); new hardware is still being manufactured in some ranges (by which I mean new devices, not new designs).
It's a bit weird to be learning how to program for DOS in 2005!
The server side of that system is mostly VB6 with a bit of C++ here and there. We're still using VC6 too, at least partly so we're only shipping one version of the C runtime and MFC.
Stability. What an interesting concept. -- Chris Maunder
|
|
|
|
|
I was actually doing 16-bit MFC. This was part of a contract assignment. At the same site I also used VC++ 6 and 7.0, plus ASP and VB .NET/ASP.NET. So, quite a bit of variety!
I actually used the VC6 IDE to edit my VC 1.5 code, so I could get all the IntelliSense and other features of the IDE. Then I'd switch to VC 1.5 for the compile.
Kevin
|
|
|
|
|
You would be wrong. I still use VC6 every day. A large portion of what I do is building back-end systems to produce web-enabled presentations for reports, analysis, raw data, etc. I am still building new applications with VC6. I have a huge investment in C++ libraries (written by me and others) and some will not compile under VC.NET. I am slowly moving to VC.NET, but I will still be using C++ for the bulk of my work. I can't even imagine using C# or VB.NET for some of the stuff I have to build. I love ASP.NET for web front-ends, but for back end systems, C++ still is the best IMHO. As far as I know, for programming win32, non-mfc, non-gui C++, there are relatively few benefits to VC.NET.
However, I am not building shrink-wrapped applications which may be what you mean.
|
|
|
|
|
I wasn't talking there about C++ and VC6, but about building new apps with COBOL, Fortran, etc.. I write all my code in C++ using the beta of VC2005 and I can't imagine me moving to C# or whatever .NET language anytime soon...
Behind every great black man...
... is the police. - Conspiracy brother
Blog[^]
|
|
|
|
|
Same here... I use VS .NET to develop C++ applications using frameworks other then those developed by Microsoft. The truth is I am not taking full advantage of the .NET capibilities in any way.
|
|
|
|
|
If I'm not mistaken, VC++ 6 is a compiler not a language... So technically if you wrote something in C and compiled it with VC++ 6, what are the chances that it will compile with VC++ 18? As long as you don't have some #pragma in the code specific to VC++ 6 and perhaps unless the command line options change, you probably don't even have to change a makefile to get it to work!
Of course, there may be some incompatibilities which need to be ported here and there (especially when using a poorly portable langauge, I won't mention any names) but in general it should just work... So I don't see how you would judge legacy by the compiler used to build a binary but rather the coding methods, algorithms and implementation of the design (what APIs are being used, etc.).
As an example, using a single threaded implementation to get around an issue that a specific OS that doesn't support threading; however the OS does now support threading in the latest releases.
The other definition would simply be "code that was written before the current project" even if it was last month. Last month was a seperate project and it's already been released. Since it pre-exists your current code, it could technically be referred to as legacy.
8bc7c0ec02c0e404c0cc0680f7018827ebee
|
|
|
|
|
Despite my pleas, we still end up creating solutions using legacy code. Why we start a new project in ASP 3 is beyond me, but it still happens from time to time. It's partly because not everyone on the team is C# and ASP.NET ready. I was a fairly early adopter and I'm cringing as I see them begin to dabble in ASP.NET for the first time right as Whidbey is about to be released. 
|
|
|
|
|
I'm in the same boat but I actually prefer projects in the legacy code to the new stuff. It was better thought out, planned and written. Some of the code hasn't been changed since 1995 and it still works. It has been structured in a way that is easy to modify and easy to maintain.
State machines - they're really simple compared to the complex algorithms that needn't be complex. The 'kids' nowadays aren't taught state machines so the coding is unduly complex. One of them couldn't believe how simple the coding became when I showed him how to do it with a state machine. Legacy methods are great if someone bothers teaching them to the youngsters.
A lot of the C# stuff is coded on screen with very little planning. It is a nightmare to maintain even though it is less than 2 years old. There are no programming standards and you spend a quarter of the time battling with Visual Studio.
Legacy stuff loads up in 15 seconds. Non legacy stuff takes almost 5 minutes! For minor mods, it takes 30s to rebuild legacy stuff and almost 10-15 minutes to rebuild non-legacy. I'm sticking to legacy for now.
|
|
|
|
|
I have to admit that I'm one of those 'kids' you speak of. I'm working hard to more about the design principles that will help me write more maintainable code.
For us youngsters, have you got any favorite URLs that will help us with, for instance, state machines?
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
