Starting a coherent architecture in a legacy application

Question

I have responsibility for a large Asp.Net based website. It is currently a website (not web application), some windows services and a number of class libraries.

The data layer uses a mixture of LLBLGEN and Linq To LLBGen, as well as a number of instances of legacy inline SQL which have not been refactored.

There are some manager type implementations, but in many cases the application exhibits the Smart UI anti-pattern (i.e. too much business logic in code behind classes)

The site is reasonably high traffic, and performance is fine, but we are growing our development capability to a team of around 10, and increasingly it is clear we need an overarching layered design on top of the existing middleware.

My question is where to start? We have 10 years of code (some of it still really just migrated ASP Classic stuff), many different approaches, and styles.

Refactoring the entire code base is not realistic and, probably not desirable

I know this is not a novel situation, are there any useful ideas or concepts as to how to approach this problem?

Answer 1

I also have been working in similar situations and I can give you the following advice.

1. You need to reduce technical debt. Now. Why? Because technical debt is like financial debt. You will pay interest on it.
2. Since refactoring the whole code base is not feasible, ask yourself: what is preventing it? Is it simply too much work? Why?
3. Create a plan to reduce technical debt in time. For example, by setting up rules as "every bit of code that is touched by the team must be fixed/refactored to the new standard". Typically: unit tests must be written, code must be moved in the correct layers, etc. This allows you to fix a lot of code without resorting to ridiculously expensive and low value "refactoring" projects.
4. Wrap the crap. Decoupling is key to refactoring and good architecture. If you can partition the code base somehow, you can maybe refactor smaller bits.
5. Do not increase tech debt further. Do not increase tech debt further. Do not increase tech debt further. Do not...

Answer 2

You're right that refactoring the entire codebase is not desirable. Refactoring is something you do in advance of new development to make that development go smoother. If you're not planning to modify all the code in your codebase, refactoring is going to prove an inefficient use of time.

Some advice in addition to what Sklivvz says:

1. Separate the code into frequently and infrequently modified sections. Only the frequently modified sections need to be brought fully into the new architecture. Integrate the infrequently modified code with the new architecture using as few changes as possible (or no changes if you can get away with it). Resist the temptation of the full rewrite, it'll cost more than you gain from it. Appreciate that the existing code works, even if it is ugly.

2. Find out what your refactoring goal is. Do you want to make it easier to get content into the site? Do you have a lot of bugs and want to improve user-perceived quality? Do you instead want to reduce feature development time? Or do you mainly want a better UX? Your architecture should make it easy to refactor code to meet the goals you set. Never forget that the primary beneficiary of your refactoring should be your user/customer/business. Cleaner code is not a goal in and of itself, it's a method to an end, and the end involves a user.

3. Try to find as many reference architectures as possible and don't be afraid to copy them. Don't reinvent the wheel. If someone else has an architecture that works well for sites like yours, learn from them.

4. Think about the people management side of things. In my own migration projects the hardest part was making people learn the new ways and stick to them. You'll need reference implementations, and a way of teaching the architecture to everyone on the team (both old and new). To reduce resistance to change, ask for input from everyone on the team before making decisions. Make sure that the new design actually improves things from the developers' personal perspective, and isn't such a big leap that they feel out of their depth.

Answer 3

The MOST important thing I saw when trying to deal with an old codebase is to NOT keep changing what you are shooting for. That is, figure out your desired architecture, then STICK WITH THAT PLAN! One of the big problems my last position had was that the codebase had several different ideas of what it should look like over time. Each time a new idea was tried, some of the code got converted, some didn't, and then someone else had a 'better' idea. It became increasingly incoherent over time and eventually was scrapped.

Answer 4

There is a really nice free book/pdf on reengineering legacy software: http://scg.unibe.ch/download/oorp/

It says OO in the title but most of the ideas apply to any software. It discusses where to start, how to deal with different parts of a system during the restructuring and a lot more of those topics.

Answer 5

If it doesn't have a coherent architecture, it is because management doesn't understand/care about the problem. Just code away. You should introduce new good architecture as you write new code.

You should re-architect things only if they start having really serious bugs, you need to extend it and just can't, or it just doesn't match its requirements.

I'm basically saying only care about issues that your managers actually care about, not issues they would care about if they had your knowledge.

If you can sell re-architecture to management, start with testing. If they don't want to invest in testing, your efforts will only get you trouble.