Refactoring nasty legacy systems via AOP or other automated means?

Question

I've recently been playing around with PostSharp, and it brought to mind a problem I faced a few years back: A client's developer had produced a web application, but they had not given a lot of thought to how they managed state information - storing it (don't ask me why) statically on the Application instance in IIS. Needless to say the system didn't scale and was deeply flawed and unstable. But it was a big and very complex system and thus the cost of redeveloping it was prohibitive. My brief at the time was to try to refactor the code-base to impose proper decoupling between the components.

At the time I tried to using some kind of abstraction mechanism to allow me to intercept all calls to the static resource and redirect them to a component that would properly manage the state data. The problem was there was about 1000 complex references to be redirected (and I didn't have a lot of time to do it in) Manual coding (even with R#) proved to be just too time consuming - we scrapped the code base and rewrote it properly. it took over a year to rewrite.

What I wonder now is - had I had access to an assembly rewriter and/or Aspect oriented programming system (such as a PostSharp) could I have easily automated the refactoring process of finding the direct references and converted them to interface references that could be redirected automatically and supplied by factories.

Has anyone out there used PostSharp or similar systems to rehabilitate pathological legacy systems? How successful were the projects? Did you find after the fact that the effort was worth it? Would you do it again?

UPDATE: See this blog post for more discussion.

Answer 1

What you want isn't AOP, but a program transformation system, which generalizes AOP. These allow one to define a set of automated modifications to the code base, and carry them out reliably. You don't hand modify 1000 complex references; instead you figure how to define a transformation that will handle all the cases and let the tool apply it reliably for you.

I can't speak for your web application, but I have two specific examples where I have applied this successfully.

1) Boeing needed to radically restructure up to 6,000 components, each coded as set of cooperating C++ classes (often totaling 3-10K SLOC) from a legacy distributed architecure to one in which each communicating element became a function in a CORBA facet. Using my company's DMS Software Reengineering Toolkit, a program transformation system capable of accurately transforming C++, we implemented a tool to carry out those changes. The tool modified one line in three on average but could convert a component in about 5 minutes. The resulting conversion was 98% complete and required some modest touch ups, but was much more effective than the estimated 1 man-month to hand modify each component. This is best thought as tool-implemented massive rearchitecting of the software structure. You can read about this in a technical paper:

Akers, R., Baxter, I., Mehlich, M. , Ellis, B. , Luecke, K., Case Study: Re-engineering C++ Component Models Via Automatic Program Transformation, Information & Software Technology 49(3):275-291 2007. Available from publisher.

2) The USAF has legacy systems that fly. One of these is the B-2 bomber, which is full of the world's best 1975 microprocessors. The code running in these is/was JOVIAL, the Air Force's favored langauge before Ada became the favored language (before everybody wimped out and now only awful languages are contemplated by the military for software engineering). The code runs the airplane. OTOH, they needed to get out of JOVIAL, because the support for the microprocessors (e.g., physical availability of CPUs, of development tools, and even of people willing to learn JOVIAL) was fast diminishing. We built them a JOVIAL-to-C translator using the same DMS, and accomplished 100% conversion, without ever being able to see the original code (black program...) See B-2 bomber conversion for some additional details. The B-2s are being upgraded with the converted software as we speak.

Now, both cases took some manual time to configure the transformations. But the configuration effort was tiny compared to the estimated cost to do the job by hand.

So, yes, such tools work very well if you understand how to use them, and yes we absolutely intend to use them again.