New refactoring

I was pairing with Ron Jeffries yesterday, making a medium-small change (it affected 32 call sites scattered through a couple dozen units, but it was basically just changing those call sites to use a different constructor).

As we worked, we became vaguely aware that we often wound up passing two parameters that always varied together. They seemed to belong together on a parameter object. (The canonical example being that you always find yourself passing an X and a Y, so you create a Point type.)

So we briefly coded up that parameter object, amidst a good deal of spirited discussion on how this should work and how that should work. (That should’ve been a clue. Ron may have seen it, but I didn’t, yet.)

Then we went to use our nifty new class, and realized, for complicated reasons, that we couldn’t actually use it just yet. It was, in fact, a YAGNI — we didn’t have an actual call site using it yet, which is why we (me in particular) had such a hard time figuring out some of the details of how callers would use it. It’s hard to figure out what the code does when it doesn’t do it.

As soon as we figured out that it was a YAGNI, Ron said we should rip it back out. He had a point: it was just cluttering the code, and adding complexity we didn’t need. But I expected to need it within a day or so. It was simple code, but it wasn’t quite so simple a concept, and we had to wrestle with naming a few things. I wanted to hang onto what we’d done (particularly the type name and method names), for possible future reference, but we didn’t want to keep it in the code.

So I invented a new refactoring: Extract YAGNI to Notepad.

Leave a Reply

Your email address will not be published. Required fields are marked *