One week in…

It’s been a whirlwind of a few weeks already but we’ll limit ourselves to the part that’s related to SSI instead of the grand adventure of helping my previous job move locations along with other major tasks immediately before starting a new job.

The week started out with me cramming books, of which Clean Code and Test Driven Development are the most interesting thus far. Over the years I’ve participated in a variety of projects with often at most a team of two, so between that and just the difference of our environment, by the standards of these books I’ve spent most of my professional life Doing It Wrong. Let’s jump right into some reflections based on the specific books

I had intended to read Test Driven Development after Clean Code, the thinking being I knew I was looking forward to TDD because I’d heard about it for years and never been in a position where I had enough time to implement it (or was working on a LAMP environment that wasn’t object oriented enough to make testing as clear cut). However by about ten pages in, after the 5th reference in Clean Code to TDD, I reversed their order. I won’t copy & paste stuff but it was as interesting of a read as I expected, the first section the examples flowed fairly clearly, each basic decision making sense in the context. The second half I had to work a little harder, in my reading I had missed a block explaining why he started down a different path than the obvious one to me which caused me great confusion until I went back and found the section and reread it. As I’ve been working on the Tic-Tac-Toe project I’ve been struggling with a bit of it along the way. A couple times I’ve found myself trying to code tests at too high of a level, I’m also still struggling with writing the test before the code on some of the more complex implementations where I’m struggling to visualize the test without adding some additional elements to the objects. Aaron suggested I dig into the Moq documentation before I get too much further along and I can see the usefulness of mock objects. Honestly I’m struggling with the nuts and bolts conceptually; how do I secretly replace the objects with their testing counterparts without exposing a vital private objects (representing the board and players) to the public unnecessarily? I find myself wondering if my paralysis on the next test is a result of newness to testing or that the object I’m trying to test is doing too complex a thing and needs to be broken up.

Confession time, I could have continued to ramble on about the testing probably for quite a while, but as I’m watching my word count to make sure this doesn’t get long, I think that’s a good stopping point because my internal monologue on that last bit has easily broken 800 words by itself. So on to the other book I found interesting, Clean Code.

Clean Code actually went into a lot more than I thought from the title, glancing at it I found myself wondering how a book that thick could come out of a discussion what I defined as “clean” code (my definition of which revolved mostly around consistent formatting for readability, so it was pretty lacking). I confess, my last project in C#, though a lot of fun due to unusual challenges, was still somewhat thrown together, having grown from a weird proof of concept into something that was intended for deployment. As it was fresh on my mind, I spent a lot of time going “yep I didn’t do this right either” as I read through Clean Code. My original idea for this blog post was actually going to revolve around that with the title “Thing’s Aaron’s done wrong”. The worst of which would probably be my violations of the Single Responsibility Principle. Iterating an entire hard drive via Windows API calls already isn’t the prettiest thing, but I failed to isolate it and as a result 70% of the logic of the entire system was in one class. I ended up at one point actually dumping most of the code and rewriting at one point after I started expanding it past the test case, but I largely repeated the same errors when I did it. I expect this one will be one I come back to regularly when I hit questions like I’m hitting on the Tic-Tac-Toe one at the moment.

This brings us neatly to where I am right this minute, so it’s as good of place to stop as any. Next post? Hopefully about how the solution to what I am grappling with was actually super easy, I was just overthinking it or hadn’t applied some design pattern fully.