I was watching a video with Kent Beck speaking somewhere, I’m not sure which one because there were like 3 different videos. But he was categorizing coders into “lumpers” and “splitters”. I apparently am a “splitter” because I’m splitting up my functions like crazy. If I were a “lumper” I would write larger functions. Honestly, I’m not sure which he is or if he prefers people to be one or the other, but there it is. My name is Jon and I’m a “splitter”.
Hence why I don’t like this big code block full of If/ElseIf combos:
Ok, so today I’m moving on to refactor this. I’m about to create a new function I think. Yeah, started to create a second new function then stopped, it wasn’t needed. Here’s what I got now for the whole set of null/not null checks for whether the field changed:
At this point I’ve reduced it down to 1 If/Else and I feel at least a little better about it even if it’s not perfect. Ok, and the tests all still pass. So what’s next? As I’ve been gleaning info from various sources on Test Driven Development, I’ve discovered that Kent Beck, a long time TDD proponent who in his own terms “re-discovered” it for my generation, makes lists of changes and then writes tests according to those lists.
So far, I’ve just sort of gone of the cuff and tried to make the tests as I go along, like, what do I want to do next? I told you guys I’m just a beginner at this and trying to learn it, right? So how about a list of the tests I might want for this auditor as we move forward? I’ll revisit my initial design thoughts and then see if I can make a list of things I want this Form Auditor to do.
Ah, my tomato timer just went off, so that will be the next writing assignment for me.