I have inherited a 10+ year old project that has been handed down through many developers. Needless to say, there are many instances where there is some class or object property that no one knows what it is for or why it exists. The code base and DB scema are in desperate need of pruning.
Obviously I search all code, database tables, views, and stored procedures before even considering removing something. But after I've exhausted all checks, I need to move forward somehow. I don't want to follow the path of previous developers who have created many '_datestamp' table and DB copies just in case the data is needed later.
Is there common practice for this?
My initial thought is to create a DeprecatedObjects table where I would have a structure that has: ObjectName, ObjectProperty, ObjectPropertyType, ObjectPropertyValue, DeprecatedDate
The idea is that I have a single place I can use in case I find out 6 months later that some property was being read directly from one of my tables and is now needed again. It also gives me an easy way to remove objects and data that have been deprecated for many years.
This project is in .NET so it would be great if there was some library that already does this in a standard way.
When I talk about "deprecating" I mean I want to remove classes and properties from the object definitions and from the backing database. I have some objects with multiple properties that no one knows what they're for. To make things worse, some of the names are downright wrong (and misleading).
So my goal is to find a clean way to start to clean up my object graph but still back up the data in case I need it sometime in the future.