Adding new features to an old application

Question

I wrote a .NET Windows application using framework 3.5. At that time, 3.5 was very new and I had knowledge of framework 2.0 only. Due to deadline, I didn't use any new features of version 3.5 and delivered the application. There was no time.

It is now two years and the app. is running fine, but my clients have requested new features. There is a major scaling needed. The new code that I wrote so far uses many new features of .NET 3.5 and I am concentrating on reducing the new code size.

The problem is that the new classes that I want to write are sometimes creating redundant methods for doing the same thing. I am not disturbing the old code.

How to manage? If I replace old classes with new ones, it risks functionality and need thorough testing again. If I don't, the project size is increasing.

Answer 1

We ship a number of windows applications. Some of the parts of each application use .NET2, some 3.5 and one application is still VB6. We have to make annual updates because the tax law changes every year (many of our users are accountants and actuaries). Refactoring code each year is a standard practice for us. When we added .NET 3.5, we were wanting WCF and Linq, and will be adding more stuff as time goes by (and we have time to learn what we want to add).

If I replace old classes with new ones, it risks functionality and need thorough testing again. If I don't, the project size is increasing.

I recommend adding unit testing to your solution. Many developers don't like to do testing, even automated testing. We have some who comment out tests that now fail due to their new code breaking some older edge case.

Three good books are:
Brownfield Application Development in .Net and
Working Effectively with Legacy Code
Growing Object-Oriented Software, Guided by Tests

If you cannot afford the versions of Visual Studio that include unit testing, then I recommend another books on using external tools for testing:
Expert .NET Delivery Using NAnt and CruiseControl.NET
While this book was written for .NET 1.1, it still has some useful information.

One practice I recommend strongly is "continuous integration." The purpose of this is for some process that runs every time code is checked in to compile and test the code. While it is fiddly and annoying to set up in the beginning, it makes things very easy and very repeatable later on. If you are keeping score, continuous integration lets you answer "yes" to questions 2 & 3 on the Joel Test.

Answer 2

If you're worried about extensive testing then it probably means that your testing isn't automated at the code level. No automated testing = lots of pain (and I can speak from experience there). Your first step then should be to put some basic sensing tests around the existing code that you're thinking of modifying using something like NUnit. Now make the changes you want to make replacing the old code with the new code and ensure that everything continues to work.

Don't confuse these sensing tests with unit tests - they are there to verify that the code already in place is actually doing what you want it to do before you start and they don't need to follow the usual rules of testing. Hopefully as you change and update the code you will be introducing meaningful unit tests, at which point the sensing tests can (and should) be deleted.

The book Working Effectively with Legacy Code goes into a lot of detail about the various techniques you can use in your situation. You could also consider getting a lot of quick code coverage by using one of the acceptance testing frameworks such as Cucumber or Robot Framework - or even (if it's a web app) some quick and dirty record-playback selenium tests (again, be prepared to delete these initial tests once you have meaningful test coverage with more maintainable acceptance tests).

Finally don't crucify yourself on reducing the code size - concentrate on solving problems one at a time and refactor bad stuff away as you need to.