Kurt Harriger puts out a call to Classic ASP programmers to share their experiences,techniques and code when refactoring and testing for Classic ASP. Asp Refactoring [1] is a creative commons wiki started by him and invites others to join in on the fun.
Although asp.net has been out for years now, I still run across a surprising number of developers that are still working with "legacy asp" code that is too expensive and/or too time consuming to rewrite. Many developers expect that the code will eventually become obsolete and be replaced by something better. But who is going to replace it: you or your competitor? Not all of us have the luxury of simply waiting for the product to become obsolete; that existing code base can be either an asset or a liability to moving forward.
Microsoft would like all asp users to move to asp.net, but provided minimal backward compatibility to make this migration easy. For small web sites a full rewrite might be an option, but for many larger sites the move has to be incremental. Unfortunately, one cannot always simply start using asp.net for new pages and convert old pages whenever they like. Session state was more widely used in asp than is currently used in asp.net, but if you are using it you can't share it with .net. For some sites that causes an issue running asp and asp.net side by side. Even after removing or synchronizing session state there are many other hurdles that complicate migration. For larger sites, there is often a considerable amount of asp code in include files that cannot be executed by asp.net. ASP code tends to be a mix of presentation and business logic, sometimes its easy to separate but often time it is not. Issues like these can create a huge wall that has forced many developers to continue to use asp even for new development as long as the product continues to be maintained.
During the dot com boom I was happily witting client/server applications using more traditional protocols. I did not even start taking web applications seriously until after asp.net had already been released, but once I started doing more web development I found I couldn't get away from the "legacy asp" sites. I have worked with several companies to migrate existing asp sites to asp.net and have used several different techniques over the years, but never yet on this scale. The company I'm now working with has spent more than 8 years developing this product and has created over a million lines of asp code, hundreds of COM components, and several thousand database objects. The code was largely written by business people who learned asp to solve a problem rather than by experienced software developers. As a result File->Save As and Copy/Paste was widely used and is probably the worst code I have seen in my entire career and yet because they had a excellent understanding of the business needs the product is the best of its kind despite the brute force development approach. Although more developers were added to maintain the product, many developers simply repeated the existing patterns and the quality didn't improve much. Many developers were too concerned about breaking existing code they didn't fully understand that in some cases they would rather copy an include file to change a couple function and redirect the pages to point to the new include file because they found it difficult to identify or test code that may be affected by the change.
Rather than complain about it I decided it was time that someone take some ownership of the mess and clean things up. During the process I found myself injecting new seams1 for testing, and performing similar refactorings throughout the application: wrapping global code blocks in functions, extracting new include files, etc.
ASP has some unique language "features" that one needs to be aware of when performing even some of the most simple refactoring techniques. Compiled languages "test" each function name is unique at compile time and issue an error if the method is already defined, but in asp one can redefine a method later in the code. Most often this is probably a bug, but I have also found that this can provide a very useful testing seam.
I often wonder what techniques others have come up with for testing and refactoring asp code, so I thought I would start a wiki where developers like myself that still have a need to work in asp code can "backport" the current testing and refactoring techniques to asp.
This is a public wiki and anyone should be able to create and edit these pages and I encourage you to do so. However, I believe you do need to create an account however to reduce spam. I only ask that you give credit where credit is due. If you have any problems feel free to contact me.
I am curious how many developers are still working with asp and if there is any interest in this wiki . If you are still working with asp at all I would know that your out there, so please post a comment and/or send me an email.
Kurt Harriger
kurtharriger@comcast.net
Happy Publishing!