After the naming papers I've written while at Object Mentor, and the chapter I supplied to Bob Martin's Clean Code and the subsequent video episode, I am known as a "naming guy." I'm expected to always have a choice name in mind, in line with my own naming rules, for any circumstance in which I might find myself.
True to form, anyone pairing with me runs the risk of being exasperated at my constant two-step of "What's that for, really?" and "Can we rename it right now?"
My coworkers are often surprised when they see me use a silly or meaningless name early in a test or body of code. Why would I not know exactly what to name a variable, class, method, or test? How is a test fixture not obvious to me from the very beginning?
Roy Osherove, in initial shock at the idea of not proceeding name-first, kindly tweeted a link to our post:
dear god, this is HORRIBLE test naming advice. bit.ly/KqEn4B
— Roy Osherove (@RoyOsherove) May 15, 2012
When pressed, he told us that he felt that we should always understand the work we are going to do before we start it, so the names should be obvious. This was the primary disagreement we had with Roy. I appreciate the tweet and also the starkness of the contrast. Quite often we have a pretty good working title to begin with, and see no need to change it.
What we've provided is a process that doesn't require you to be sure to begin with.
I admit it: I'm not always sure where exactly I'm going next. I sometimes am not sure if the next test will be part of the same fixture or should have a different setup and teardown. Sometimes I know that the next test I write is trivial and will be followed by something more meaningful. Sometimes I'm looking at code and characterizing it, rather than fully understanding everything about it before I start.
Some of us might always have an answer in hand, but I'm not a guy who will sit on my hands until I see it. My feeling is that naming is far to important to settle on a final name before you explore the territory, and that there's a bit of parallel evolution going on.
I think it's important that the test and the code and all the variables and classes have the best names that my partner and I can give them or else our work is not done. I just don't confuse "can't finish without" and "can't start without." I can start with silly names, and improve them.
This mirrors my feelings about design and architecture. You should have something in mind when you start, and you can't call your work finished until you have good architecture and design. That doesn't mean you must delay starting until you have a final answer. You can grow your answer incrementally even if you think you know what it's going to be.
Remember: evolution isn't the damage control done by failed species; it is how the winners keep winning. Given a choice between perfect planning and evolution, I'll bet on evolution every time.
Such a nice post!
ReplyDelete