Refactoring Screencasts V

There exist a host of excuses for why it took so long to get these finished. But they boil down to two:

1. There is no quiet place to record at home.
2. There is no quiet place to record at work.

The first one is being remedied as we speak, for I'm in the process of moving to a new house and there will be space to set aside for a make-shift "recording studio" in said house. (Which will basically be a table and chair in the basement with some heavy blankets draped around it for sound dampening. But it's something at least. Note, however, that this "being remedied" is a long and drawn-out process, to be followed by the holidays, so I may be quiet for a while. But I digress...)

The second one hadn't been a problem during the summer, when my work mainly involved travel and hotel rooms are notoriously quiet when one is alone. However, for some time now I've been "between projects" and mainly sitting around in the company's office. (Which is not normally where a consultant spends his time.) Again, normally this isn't a problem. We have a conference room for this sort of thing. But another large project has been much taken over our office's conference room, for reasons I'm not aware of but aren't so uncommon to bear going into.

Yesterday, however, the conference room was inexplicably empty. So I was able to knock out the remaining recordings for the Making Method Calls Simpler series in an afternoon. Hopefully they don't appear hurried as a result. In any event, here they are. Enjoy!

Rename Method

Add Parameter

Remove Parameter

Separate Query From Modifier

Parameterize Method

Replace Parameter With Explicit Methods

Preserve Whole Object

Replace Parameter With Method

Introduce Parameter Object

Remove Setting Method

Hide Method

Replace Constructor With Factory Method

Encapsulate Downcast

Replace Error Code With Exception

Replace Exception With Test

Next I'll move on to the Dealing With Generalization series of patterns.

The Left Turn At Albuquerque

Bugs Bunny is lost. Really lost. And looking at a map of his current location doesn't seem to be helping him.

You see, he should have taken that left turn back at Albuquerque. Unfortunately, he missed that turn and just kept going in the wrong direction. And kept going, and kept going. Where is he now? Is this place even on his map? One thing's for certain... Getting from where he is now to where he wants to be isn't going to be easy. His original intent assumed a left turn at Albuquerque, so by definition everything he's done since then has been wrong.

This happens to programmers a lot. Invariably they find their way to Stack Overflow to ask a question about where they should go next. And very often they get a series of comments similar to this:

"Why are you doing it that way? There's no need for that. You're doing something else wrong."

It seems unhelpful on its face, but it's exactly the problem the programmer is facing. He's trying to solve a problem that he shouldn't have in the first place. And he's getting frustrated by the fact that there isn't a readily available solution to the problem that he just invented.

How should Bugs Bunny get to where he's going? Well, we don't know. We'll never know, because he didn't tell us where he's going. Nor did he tell us where he came from. We don't know the problem domain that he's trying to solve.

The programmer needs to step back for a moment and examine the bigger picture. It's not that we don't want to help him solve his problem, it's that we don't know what the actual problem is. And we need to know that to be of any use. Sure, maybe we can help him with his current roadblock. Then he'll just come back in an hour trying to solve his next roadblock.

If Bugs Bunny's tunnel encounters a massive outcropping of rock, he's going to ask someone how to get around that rock. And maybe they'll show him. Great, now he's on the other side of the rock. But is he any closer to his destination? We don't know, because that's not what he asked us. He only asked us how to get around the rock.

The programmer took a wrong turn somewhere. Perhaps a very wrong turn. Perhaps somewhere a long time ago. We don't know. All we know is that the sequence of steps, with no weights assigned to them to provide any perspective, went something like this:

1. Programmer performed Step 1.
2. Programmer performed Step 2.
3. Programmer messed up on Step 3.
4. Programmer figured out how to perform Step A.
5. Programmer figured out how to perform Step þ.
6. Programmer got stuck on Step ± and asked for help.
7. Programmer became frustrated that the help didn't get him any closer to Step 10.
8. Rinse, repeat.

We want to help this programmer. We really do. But we can't unless we know the actual problem he's trying to solve. Not the immediate roadblock he's facing right now, but the actual problem being solved.

I guess if there's any piece of advice I can give from this little rant, it's this...

• Never assume that everything you've done until now has been correct.
• Never assume that just because you got something to work it means you're any closer to your goal.