0

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.

Clarification

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.

Origin
  • 111

1 Answers1

1

I assume you're referring to checking this DeprecatedObjects table whenever a particular table/column is used and if it isn't present, you add it so you have a clear idea of what is used and what isn't. Am I right?

There may be libraries which could tell you which methods and classes are used, but I think the database is a far more complicated issue as it depends heavily on your interface. So the second approach would be to add some sort of logging system that makes it clear which tables and columns are used, and I wouldn't personally trust any library to do that for me.

This is probably something you could do on your own that wouldn't even have a strong impact on your program (with one small caveat that I'll explain in a second). Everytime a table/column is used, check this DeprecatedObjects table and if it doesn't exist, add it. In 6 months time of heavy client usage, you have a list that likely going to describe every column and table used in your database.

This would be horribly inefficient checking each time, so the caveat is to preload the list in memory on program start. In this way, it would only consume memory and wouldn't slow the program down to any serious extent. Just remember to update your list in memory when new items are added. Might be a good idea to perform a memory check before and after the change to see if the memory impact is significant (jumping from 100 Mb memory usage to 5 GB might be a bit too much).

Also, do be sure to document this completely. Should you abandon the project or get fired, you wouldn't want this system to be amongst the clutter that it attempts to resolve.

Neil
  • 22,848