Legacy Code

Today, It has been 18 years since Delphi was released.      Some Delphi projects have been around for quite some time now.     I think we all look back on code we wrote a year or two ago that we would write in a completely different way today.   Sometimes is because a new feature of the language or a new library is available, and sometimes it is just that you have learned a better way to do something.

Where I work....

In 1998 there was a mainframe application, that was not going to make it through the year 2000 switch.   A decision was made to rewrite the application and Delphi was chosen.     We have had several other applications that were started after the year 2000 that were written in other technologies.   Many of the these have had to be completely rewritten.     However, our not so little Delphi application not only survives it thrives.  Business is always changing we are constantly updating our application to meet these ever changing needs.   

Much of the original code written in 1998 still exists in some form, with many more lines of code after that.   The team has evolved over that time as well, we only have one developer left who started the project.  I estimate that we have had 40+ unique developers who have worked on this code base.   Each unique,

each had there own coding style and skill sets.    

Some of the past code is very procedural with tons of global variables and is written in a such a way that it's very difficult to test and maintain.   Where new code is written using better practices, and with good unit test coverage.     But it's not uncommon to be asked to change an area of the application that has not been significantly changed since it was first written in 1998.   When faced with such a change, how do I do that in a safe way and not continue to keep the code looking like it was written in 1998.

I have been collecting various snippets of code and how I changed them for the better.   Today I will be starting a series of blog posts on dealing with legacy code.   I suspect this may generate a bit of debate and that conversation is welcome.  I have learned that there is always a better way.     I have also learned that what works from problem X may be the complete wrong solution for problem Y.      

My hope is that what I write will help others to think in new and different ways when dealing with code.