Bookkeeping code redux: light at the end of the tunnel



  • A few months ago, I posted this topic: Bookkeeping code or: how I learned to stop worrying and love data duplication.

    TL;DR of previous topic: we have an application that among other things, manages "stories" (actually they're not stories, don't want to give away too much), which can have many chapters, which can have many paragraphs. These stories can be linked to clients and their licensees. An ex-coworker thought it would be a good idea to interpret "licenses share stories", as "each license gets a deep copy of the story", resulting in lots of bookkeeping code and thousands of database queries.

    I'd already pulled a few tricks out of my top hat and this alleviated the problem, but still, when the client would try to change a chapter title, it would take five minutes. This was basically my fault: I'd written a method that would take one story, delete all the data in the copies, and then repopulate the copied stories. It would get called each time a story got saved. This is the only way I knew how to be sure that the whole bookkeeping code thing didn't cause any bugs. This problem would, of course, only get worse with time unless something was done, and I was just about out of tricks. So I talked to my boss about it, and although he knew a bit about what was causing these screens to be so unresponsive, it turned out that he didn't really realize how bad the problem actually was. So I decided to clue him in, and flat-out recommend that I just yank out the whole godawful mess. And he agreed.

    So last week I spent about a day and a half rewriting this stuff. Now we have an extra database table, and also we have 80,000-100,000 fewer records overall, that no longer need all that bookkeeping code to manage them. Many, many known and unknown bugs got squashed. Screens went from thousands of database queries, to like two or three. Git tells me I took 1,151 LOC out and wrote 333 new ones, not including any whitespace changes.

    I'll be deploying tomorrow. I did a good thing last week.



  • I hope people haven't been "taking advantage" of the deep copies for tweaking stories to suit individual clients...



  • That's just the thing. The stories can't actually directly be edited except by our client. The point of making the deep copies was that all the licensees could see that the story is available to them, as a template to build upon. So none of the users ever actually think of these copies as copies. To them, it looks like a single story. Details are in my original post.

    The storytellers (sorry for the shitty metaphor btw) take these templates and make a separate deep copy that they then edit, or leave as is, or whatever. This is fine and intentional.


Log in to reply