Javascript Checkout -- Pausing for breath
Please help me by answering a question about these articles
This article is part of a series in which I’m doing a well-known code kata in the “TDD as if you meant it” style. I’m also strictly following the 4 rules of simple design and looking for opportunities to use implicit coupling to drive refactoring under the Once And Only Once rule. (If you missed the start of this series you can catch up with part 1 here.)
I’m going to take a break for the next couple of weeks.
And before I do that, I want to ask you a question: Is this kata series useful enough to continue, or would you prefer me to revert to the more varied content I created previously?
On the one hand, these articles give us a chance to dive deep into writing code via TDD and refactoring. By taking the time to unpick even the tiniest moments, I’m finding a surprising amount of design thinking to discuss. Admittedly the code isn’t changing particularly quickly across these articles — but that’s because each week I’m expanding a few seconds’ thought into a thousand words of analysis and exploration. And in the course of that expansion I’m discovering heuristics that even I didn’t realise were in play. You can find a list of many of them at the end of this article, as a kind of recap of what I’ve learned from the 7 articles so far.
But on the other hand, this one very simple example is taking a loooooong time to go anywhere, and it shows no signs of finishing any time soon. So by focusing so deeply on such a simple example we’re losing the opportunity to explore more widely. I have ideas for other katas too — for example following the lead of Kent Beck’s book Test-driven Development by Example by TDD-ing a unit testing tool, or doing something in a functional language, or trying the auction sniper kata from Freeman and Pryce’s Growing Object-Orient Software Guided by Tests. There are also more general discussions to be tackled, such as continuing to explore specific cases of implicit coupling in more of a “solution catalogue” style.
There is a lot to explore, yet I only have 2 hours per week for writing. So where should I focus?
To provide a little more context for your decision, I’ve collected together below all of the “Things to try” sections from this series of articles so far. This list represents a whole bunch of things I tend to do instinctively, without thought, but which have occurred to me consciously because I’m writing these articles. I hope you find them useful!
Take half an hour to do a (different) kata using the TDDAIYMI style. What did you learn about your usual programming style? Or about how much “design” you do without consciously calling it out?
Make a list of problems you can see in your own code, and prioritise them according to the 4 Rules.
Make sure the names you use in the code reflect the vocabulary you use when talking about that code.
Find a place where your code doesn’t tell the story you and your Customer intend; refactor until it does.
When you’re assessing whether your code tells its story, start at the outside and work inwards only when the outer layers of abstraction communicate extremely well.
Next time you have to refactor, consciously cycle around the 4 Rules. In particular each time you change anything, start again with a new review of the names and the story they tell.
Take a break after any period of concentrated effort. When you return you’re likely to see things with fresh eyes.
Next time you’re getting from RED to GREEN jot down as many alternative code changes as you can think of. Which one do you choose to move forward with, and why?
Look for opportunities to increase the symmetry and self-similarity in your code. Does this always help with readability?
Next time you have a choice between depth-first and breadth-first tree walking, try breadth-first and look out for symmetries appearing sooner.
Explore property-based testing: is it appropriate for the code you’re currently writing?
Find a function in your own code that has two parameters of the same type. Try following Fowler’s mechanical steps for Introduce Parameter Object. How did that feel, compared to using an IDE to accomplish the same thing?
Look for places in your own code where you could increase the symmetry. What happens to understandability when you do?
Do the names used inside your functions reflect the function’s internal context, or are they coupled to the names used by the callers?
Before you add the next test, make an explicit list of the implicit coupling you can see in the area of code you’re working on. What should you fix before proceeding?
Think about how you decide whether to prioritise new functionality or refactoring. What kinds of coupling do you defer, and why?
I hadn’t realised there were so many!
I'm voting in favor of continuing with this series and this kata. Starting something else would be a distraction at this point. There is a lot of value in the previous articles you shared.
I do get your concern of "it shows no sign of finishing soon" with the current speed. Therefore, my suggestion would be to NOT try out all of the things we listed. Only try a few, to "speed up" the progression. It's like when we are ensemble programming and many ideas are suggested, then we are paralyzed because we don't know which direction to take: pick one, go with that and we'll see later if it wasn't a good direction.
Another suggestion would be to reduce the scope, aim for a closer goal. When will you consider this kata to be done? Maybe you could lower the bar and only aim for supporting N scenarios. So it won't take forever to be "done" and then you can close this series and start another on another kata.
Well, at the end of the day, you are the writer and the one spending 2h / week writing these blog posts. It should feel relevant and useful for you. So take my suggestions with a grain of salt and do what you feel like doing 😉
All the best Kevin!
Please continue with these articles! They are hugely informative, even if the code itself is slow to evolve. The real value here is the exploration of thoughts and ideas you have that guide each small code change, and I believe that there's not nearly enough writing, either online or in books, on such topics.