I’ve inherited a project where the class diagrams closely resemble a spider web on a plate of spaghetti. I’ve written about 300 unit tests in the past two months to give myself a safety net covering the main executable.
I have my library of agile development books within reach at any given moment:
- Working Effectively with Legacy Code
- Refactoring
- Code Complete
- Agile Principles Patterns and Practices in C#
- etc.
The problem is everything I touch seems to break something else. The UI classes have business logic and database code mixed in. There are mutual dependencies between a number of classes. There’s a couple of god classes that break every time I change any of the other classes. There’s also a mutant singleton/utility class with about half instance methods and half static methods (though ironically the static methods rely on the instance and the instance methods don’t).
My predecessors even thought it would be clever to use all the datasets backwards. Every database update is sent directly to the db server as parameters in a stored procedure, then the datasets are manually refreshed so the UI will display the most recent changes.
I’m sometimes tempted to think they used some form of weak obfuscation for either job security or as a last farewell before handing the code over.
Is there any good resources for detangling this mess? The books I have are helpful but only seem to cover half the scenarios I’m running into.
It sounds like you’re tackling it in the right way.
Unfortunately, this can be a slow and tedious process. There’s really no substitute for digging in and understanding what the code is trying to accomplish.
One book that I can recommend (if you don’t already have it filed under ‘etc.’) is Refactoring to Patterns. It’s geared towards people who are in your exact situation.