Changing the vinegar

A while ago I likened writing articles about code with pickling it to preserve it… It seems the last few days have been spent changing the vinegar…

I’m moving most of my source to CVS. This was easy for the code that I had that was current; the Socket Server stuff and all of my latest clients. I’ve been working with all of that code a lot recently and it’s all pretty clean and consistent. I have other code though, like the NetMeeting stuff that I’ve just decided to give away. This is older, it used slightly different versions of the “JetByte Tools” common code. I’ve been putting off merging it all and making sure I have only one copy of everything, but this weekend I started to clean it up.

I found it interesting how cleaning up code structure at the library level was so similar to cleaning up at the class level. I was doing all of usual refactoring things; removing duplication, improving coupling and cohesion by hiking things out of one library and into another, etc. The end result is much more structured and much more usable. And it all still seems to work… ;)

With the Socket Server code I’d got into the habit of just having a single Win32Tools lib linked to the main server code. This was fine when my focus was entirely on servers and TCP/IP stuff but less fine when I went back and reintegrated the new bloated library with all of the other apps that use it.

All of the code that I was moving in to the same source tree had similar foibles and they’d all made their way into Win32Tools rather than somewhere more appropriate.

In the newly merged world, I had code that didn’t do sockets linking to a library that had far too much to do with Winsock and far too little to do with general Win32 primitives; and code that did do sockets but not databases or MSMQ pulling in that stuff.

It smelt funny. I changed it.

I created several new libraries. I now have a SocketTools library that contains all of the Socket Server stuff. The Win32Tools lib is much slimmed down and just wraps Win32 primitives; there are several other libs that do Database stuff, MSMQ, etc, etc. Projects pull in what they need at a level of granularity that’s based on the libraries, and there’s only ever one copy of a library’s dsp; everyone uses a library “as is”, no private builds with a couple of files missing…

So far it seems much better. The new libraries are smaller, more cohesive and should be easier to test.