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
  • 2
  • How many developers are working on your project? – Neil Sep 04 '17 at 08:35
  • Depending on what version of which RDBMS you're using, you might be able to run queries against the log or query cache to see what things have been happening in there recently. – Paul Sep 04 '17 at 13:29
  • @Neil - 3-5 at the moment. – Origin Sep 04 '17 at 13:30
  • @Paul - thanks for the suggestion. I've used this as well, but I've been bitten by those annual reports that I don't know about, and the tasks people should be doing daily but aren't. Finally - there are other applications that have full read access to my database. Even if I ask the other application owners, they may not realize that a previous developer put a direct query to my database tables. – Origin Sep 04 '17 at 13:32
  • I think the strategies described in [this SE post](https://softwareengineering.stackexchange.com/questions/155488/ive-inherited-200k-lines-of-spaghetti-code-what-now) will apply to your case as well. – Doc Brown Sep 04 '17 at 14:24
  • @Origin all of those things you said should give you *more* reason to trust the DB logs over whatever application logic you try and insert into your own application. You just have to scope the queries well enough. – Paul Sep 04 '17 at 16:22
  • @Paul - thanks for the advice, but our application is business logic heavy. Thus, part of my code clean-up goal is to move us to an ORM and trim down our objects. For this reason, I don't want to rely on the DB, I want to remove as much direct interaction with it as possible. – Origin Sep 05 '17 at 00:06
  • @Origin I feel like I'm not communicating clearly. I'm not talking at all about what you're doing in application code. Moving to an ORM can make a lot of sense. My point is that the best way to get ground truth about what's actually being done to the data is to check the DB logs. Using that information, you can refactor your application with greater confidence. – Paul Sep 05 '17 at 01:53

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,670
  • 45
  • 76
  • sorry the original question wasn't clear enough. my intention for DeprecatedObjects is so that I have safe place that I store the data I start "pruning". So when I deprecate a class or a property on a class I backup the data in one nice and neat table. I started thinking this could even be automated as part of a data migration, so I was wondering if someone else had already done this. – Origin Sep 04 '17 at 13:22
  • @Origin Ah, I had understood that the problem was about having too many tables. What added benefit would there be to write this information in the database when you can clearly mark the code as deprecated where necessary? – Neil Sep 05 '17 at 07:04
  • an example is I have a property called Foo. I have no business logic, views, or stored procedures that reference it. All new records are defaulted to 0, but for some records a few years old there are other numbers there. I have no idea what they're for. I want to remove the property from my object and the column from my DB. My thought is to back up this data into a table before removing it. This way if in 6 months someone tells me they need it, I have it. – Origin Sep 05 '17 at 09:16