I have seen this theme present itself more than once now. I am hoping that people here who are currently in similar situations or have been in the past can offer some insightful advice. It might be useful if you share your past experiences as well.

So there is this fairly large windows forms application that has been developed over the years. Though the development team has tried to separate business logic from the UI, it hasn’t quite happened and there are numerous areas of the code where the business logic is hard-wired to the UI. In fact remnants of previous attempts to adopt MVP architecture can be seen at a lot of places. There are unit-tests too but with a relatively low degree of code coverage. There are some hot spots however – areas which everyone knows have gotten more complicated that they necessarily need to be.

A lot of times bugs which could have possibly been caught earlier are only found once Testers grab their torch lights and really start looking for bugs which is unfortunately too late, expensive, and risky. Engineering, testers and PMs - all realize that something needs to be done.

What would be the most practical way to address the situation altogether, or improve the situation? Since it is going to be a long task, what would be the best way to measure the progress towards the goal? How would the goal be defined in objective terms to begin with?

5 Answers
5

You need to rearchitect the Business Layer and then wire the UI back into this rearchitectured layer.
You keep the existing UI and hardwired business logic going while this is done and switch it over to the new ones one form at a time.

This has the benfits of allowiing you to add all the unit tests and automated testing tools you need while the effects are small. You can also make sure that your components are doing what they need to do properly.

Basically, it is a long haul with limited Return on Investment in the short term but with potential big benefits in the medium to long (really just long) term.

These questions will be your starting point for a solution. The more profitable and larger the team the faster you will be able to refactor code to a newer form.

But with large projects there is typically a lot at risk with changes to the code. There must be areas that "just work" that haven't been looked at in years. Getting bugs in these areas will be a big challenge. It will take awhile to get your gears spinning to even debug these areas.

My though is to study the code in detail. When you are really sure you know it cold, give a presentation to others that are knowledgable in the code base. This will point out the next batch of code that you thought you knew but didn't. As the code starts to get into your head a clearer and clearer picture of what is needed will just emerge in your mind. Then you are ready to work out a plan for the first step. Make it something reasonable and don't bite off too much.

Above all, learn and have fun. Re-working a large project can be quite fun as long as you have the right attitude.

Of course, a tricky part will be unit testing the UI. You might have to first Extract Method in the UI itself in order to unit test the bits of logic floating around in there, and then follow the steps above.