Removing tightly coupled code.

Question

Forgive me if this is a dupe but I couldn't find anything that hit this exact question.

I'm working with a legacy application that is very tightly coupled. We are pulling out some of the major functionality because we will be getting that functionality from an external service.

What is the best way to begin removing the now unused code? Should I just start at the extreme base, remove, and refactor my way up the stack? During lunch I'm going to go take a look at Working Effectively with Legacy Code.

Answer 1

I think the most important thing you can do is to refactor/remove/test in very small chunks. It's tedious and time consuming but it will help limit risks and errors later on.

I would also start with code that is "low risk" to change.

Answer 2

If you can, and it makes sense in your problem domain, I would try to, during development, try and keep the legacy code functioning in parallel with the new API. And use the results from the legacy API to cross check that the new API is working as expected.

Answer 3

Use the primary disadvantage of tightly coupled code to... your advantage! Step 1: Identify the area which provides the redundant functionality which you want to replace. Break it...do a quick smoke test of some of the critical parts of the application. Get the feel.

Step 2: Depending on what language it is find the relevant static-code analysis tools and get the needed refactoring info.

Step 3: Repeat Step 1 in incremental levels of narrowing down to the exact pattern.

All this of course, in a sandbox environment. This may seem a bit haphazard but if you limit yourself to critical functionality testing ... you may get many leads in the process. You will definitely identify the pattern of the legacy code, if nothing else.

Answer 4

My advice is to use findbugs and PMD/CPD (copy-paste-detector) to remove dead code (code that can not or will not be called) unused variables and duplicated code. Getting rid of this junk will make re-factoring easier.

Then learn the key mappings for the common re-factoring in your IDE. Extract method and introduce variable should be committed to muscle memory after an hour.

Answer 5

You absolutely cannot do with with a live development version [new features being added]. You must start with a feature freeze.

I tend to look at all of the components of the system in an overview and see the biggest places of reuse. From there I would implement the appropriate design pattern to solve it, and make the new component reusable. Write test cases to ensure the new code works as expected, then refactor your code around the new change. Then repeat [overview, etc] till you are satisfied.

I would suggest this for many reasons:

1. Everyone working with you on refactoring will learn something
2. People learn how to avoid design mistakes down the road
3. Everyone working on it will get a better understanding of the code base