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?
Starting a coherent architecture in a legacy application
architecture;asp.net;legacy
I also have been working in similar situations and I can give you the following advice.You need to reduce technical debt. Now. Why? Because technical debt is like financial debt. You will pay interest on it.Since refactoring the whole code base is not feasible, ask yourself: what is preventing it? Is it simply too much work? Why?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.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.Do not increase tech debt further. Do not increase tech debt further. Do not increase tech debt further. Do not...