The Terror of Change

Once again I am frozen with fear over the necessity of a change. In this case, it’s quite a change. My purpose in writing this essay, as always, is to work out my dilemma by writing about it.

The basic structure of the Storyteller has been to interact with the main code that is expected to be on the server, with the Storyteller itself on the client. Thus, the Storyteller code bristles with complex material meant to handle the complexities of Internet communications. None of this stuff is necessary for Siboot, since Siboot will not be delivered over the Internet. But it’s a massive amount of software — the storyteller code is about 3,000 lines long, and perhaps half of that is dedicated to Internet communication. There are timers everywhere that are meant to handle the lag between sending a communication and receiving the response. 

It imports 25 files from the main code, many of which are simply short definitions of special-purpose classes, but a few of which are monsters. The complexities of the interactions are truly mind-boggling to me. I don’t begin to understand how it all works. 

My problem is that this stuff is increasingly getting in my way. I am currently trying to fix a bug for which the code dives into the maze of client-server interface software, and I can’t tell where the data goes bad. 

At this point, I have two options:

Continue with ad-hoc corrections
So far, I have left all the client-server stuff intact, making modifications at the client end, and carefully avoiding damaging anything that might be necessary for the client-server interaction. I could continue this process, but the bug I’m now fighting may be impossible to trace without a lot of tedious trial-and-error approaches. And what of other problems? How can I be certain that this strategy will work for all the changes I plan to make?

Wipe out the client-server connection
This is the theoretically ideal solution. Since I’m not using the client-server software, I should wipe out all the middlemen and have the client side stuff communicate directly with the engine.  

A quick check reveals (I think) that all the interaction with the player in the engine routes through a single variable called playerIO; it is an instance of a class that is less than a hundred lines long. Maybe — just maybe — I can rip out those references and make direct calls to a new set of methods that handle the front end.

But this is a very bold step, and I fear that there could be consequences of which I have no idea. I could find myself in a morass of code that I cannot handle.

A toe in the water
OK, here’s my decision: I will save the source code in its current form, then set to work wiping out the client-server connection stuff. Here’s my plan: I shall create a new class called FrontEnd, which will perform the same function as the client-side software (Storyteller and Sentence Display). Then I will re-route what currently goes through playerIO to go through the new front end. Then, and only then, can I destroy the old code. 

This is going to be scary.

That evening
It’s been a difficult day, but I have made some progress. I have gotten the new FrontEnd class slapped together, very incomplete, but its skeleton is in place. The problem now is shutting down the old Storyteller operation; it seems that every time I rip something out of it, it causes a failure somewhere else. This will be slow work