After the time vortex known as Code Kata 4, it’s sad that it is almost gone. Alas this is the last part, this is Code Kata 4 Part 4. Let’s look at the questions.
To what extent did the design decisions you made when writing the original programs make it easier or harder to factor out common code?
In the easy path, I used the same base to build both programs so it was easy to divide them up. They were doing the same kind of thing and the original weather code was just sitting there ready for the copy, paste functions.
In the hard path, I went crazy. I assumed that I was going to have more text files with different headers and lengths of spaces to deal. I built a machine that could handle the beast.
Really, I should have taken that machine and factored out more from the process weather and soccer functions. In my original plan, I would have tackled that major refactor in the next file, my assumed part 3. I don’t tend to get too crazy about refactoring until I have to touch the code again and I give it an iteration. Since so much of my hard path part 2 was new code, it never got through a refactoring. I could have just done part 3 on my part 2 but that is water under the bridge. Everything works and that is what is important.
Was the way you wrote the second program influenced by writing the first?
In the hard way, yes but to a much smaller degree. I knew I had to follow the basic steps so yes it is a skeleton of my original solution. No, in the sense that I added a bunch of new bones and organs.
The easy way, yes. Because it was the same function with just a small touch done differently, the scripting hat went on and I wrote a script based off another scripts organization. I do view solving programming problems in two hats. One is scripting where you get the one off, won and done. The other way, a more focused approach that centers around code re-usability, encapsulation and flexibility. It is a much more complex and expensive task.
Is factoring out as much common code as possible always a good thing? Did the readability of the programs suffer because of this requirement? How about the maintainability?
I don’t deal with absolutes. That is the central idea of the Scripting/Programming dichotomy. If you ask a customer, do you want flexibility at scripting task 1 in exchange for 2 or 3 time the cost? They say no. Most people would like to save the resources expended by flexibility. For business programmers, the central tenet of coding should be ROI and not comp-sci perfection. It’s a controversial stance but one forged by my business degree and 6 years as a programming centric consultant.
This was a fun and educational week as we played with Code Kata 4. It took 4 Parts and multiple timelines to get here but I think the trek was worth it.