Since I put “Legacy” in the post title to begin with, I would like to share some quotes from the often quoted Michael Feathers author of Working Effectively with Legacy Code. If you haven’t read it, you should – it comes highly recommended by many developers including Scott Hanselman on this Hanselminutes episode. But full disclosure I myself have only read a few random sections of it here and there.
What do you think about when you hear the term legacy code? If you are at all like me, you think of tangled, unintelligible structure, code that you have to change but don’t really understand. You think of sleepless nights trying to add in features that should be easy to add, and you think of demoralization, the sense that everyone on the team is so sick of a code base that it seems beyond care, the sort of code that you just wish would die.
This I strongly agree with, not to say that legacy code is always “unintelligible” or you want the code “to die”, but very often it requires a much larger unit of time to change when compared to more desirable (maintainable) code, which leads to this quote:
In the industry, legacy code is often used as a slang term for difficult-to-change code that we don’t understand.
This can be remedied in part by unit-tests…
Code without tests is bad code. It doesn’t matter how well written it is; it doesn’t matter how pretty or object-oriented or well-encapsulated it is. With tests, we can change the behavior of our code quickly and verifiably. Without them, we really don’t know if our code is getting better or worse.
That last quote from Feathers helps to outline my motives…
At my current place of employment we have a flagship application that was originally built using ASP.NET 1.1. Then slowly migrated to .NET framework 2.0 and then immediately converted for .NET framework 3.5. That task itself was not trivial, and now there is a new challenge to make the code more maintainable.
The legacy system was written in … but it worked, and it worked great … It was legacy because it wasn’t done with new and shiny…
Hanselman makes a good point even though I paraphrased so it’s a more general statement. This applies to the application I’m working on improving. The application was in fact working “fine” in its .NET 1.1 form, but making changes/improvements was difficult. When I say difficult in this case I, in particular mean for new developers not familiar with the code base and application. Being the newest developer to work on this, I wanted the code base to improve so we could all make changes and improvements with confidence going forward.
This is the first in yet another series of posts from me. This series will focus on how we’ve gone about undertaking this migration. I’ll attempt to make each post stand reasonably alone to demonstrate migrating a specific application component from Web Forms to the Model-View-Presenter (MVP) pattern and in particular the Web Forms MVP framework.
Some of the objectives that we’re trying to achieve from this framework migration include:
- Separation of concerns – through the use of the Model View Presenter pattern.
- This takes us in a direction of improved Testability.
- Refactor and consolidate program logic into re-usable components.
- Re-structure the application into a more understandable pattern, hence the desire for MVP and in particular Web Forms MVP.
This also leads down the path of improved development practices for the team:
- Test Driven Development (TDD) and Test Driven Design.
- Clean and maintainable code.
- Improved task estimation.
So then what…
Web Forms by design does not lend itself to achieving all the objectives listed above and it is hoped that the use of the Web Forms MVP framework will take us down a better path. I say this with full understanding that there is no such thing as a Silver Bullet in software development, and that the adoption of a pattern and a supporting framework are just steps we are taking.
We’ve come this far in the post and I haven’t exactly outlined what Web Forms MVP is and why it’s our choice. So first, how about the obligatory pasting of the front page quote from the official project site:
The ASP.NET Web Forms MVP project is about bringing the love back to Web Forms through a renewed approach to using it – an approach that facilitates separation of concerns and testability whilst maintaining the rapid development that Web Forms was built to deliver.
The choice to use Web Forms MVP as the framework to help us achieve the MVP pattern in our application, comes from the knowledge of successful implementations by Readify on large scale sites such as Grays Online. Along with an active community of developers working on the framework and its acceptance into the CodePlex Foundation.
Examples coming up…
Now that we’ve got the background and I’ve publicly committed to “better code” and “testable code”, the next post in this series will be about moving your OnLoad & Page_Load methods out of your code-behind files and some of the challenges.