Refactoring

Ten I-Statements About Refactoring

TDD, Modern-Synthesis, Refactoring, How I Work / / 6 minutes of reading

HOT TIP: Ted Young’s "Make Your Code More Testable" class is coming up August 23rd. The class is excellent (and covers much of what I talk about below), Ted is a wonderful teacher – and I scored you a discount code. Go to MakeTestable.com and use code GEEPAW when you sign up to get $75 off! In the spirit of my Ten I-Statements about TDD, here’s ten more, this time about refactoring. I’m not covering everything, just hitting some of […]

Ten I-Statements About Refactoring See Full Post

TDD Tests Are First-Class Code

TDD, Programming, Refactoring, How I Work / / 7 minutes of reading

My standards for TDD microtests are the same standards I have for shipping code, and I follow them in microtests for the same reason I follow them in shipping code: they make me faster. This geekery muse is comfort food, for me and maybe for you, but I want to keep stressing: I fully endorse and support my sibs out there on the street protesting this violent police uprising. Stay safe, stay strong, stay kind, stay angry. Black lives matter.

TDD Tests Are First-Class Code See Full Post

Microtest TDD: The Big Picture

How I Work, TDD, Programming, Refactoring, Change Harvesting / / 4 minutes of reading

I think of my style of coding as "microtest TDD". That can be misleading for folks, so let’s take a walk over a few of the ideas, implicit and explicit, that make up the approach. First things first, bear the money premise in mind in all that follows, to wit: "I’m in this for the money." In the software trade, we make money by shipping more value faster. This is why I adopt these practices, because when I do them,

Microtest TDD: The Big Picture See Full Post

Using the Strategy Pattern

Programming, Refactoring, Change Harvesting / / 7 minutes of reading

The strategy pattern lets you make "pluggable algorithms", so clients have different behavior without having different code themselves. We often use it to capture the "consequence in code" of some condition, which we can then let other code use without re-testing the condition. Here’s a little java snippet: dimension = horizontal ? width : height If you’re not familiar with ternary operations, what this says is "if horizontal is true, use the width, otherwise use the height". That snippet occurs

Using the Strategy Pattern See Full Post

Dealing with Nulls

Change Harvesting, Refactoring, Programming / / 7 minutes of reading

Another refactoring topic today: dealing with nulls. There are a bunch of techniques, but they amount to a) don’t, and b) do but only one time ever. The basic idea: a null always occurs in a particular context, and in that context, it has a meaning. When we pass it up or down our call-stack, we are changing contexts, and hence changing meanings. We’re using the same symbol to mean different things at different times. Using the same generic symbol

Dealing with Nulls See Full Post

Refactoring Strategy: Move It Where You Can Test It

TDD, Programming, Refactoring / / 6 minutes of reading

When I can’t test it where it is, I look to move it somewhere else, where I can test it. Today’s notion isn’t so much a single refactoring as it is a strategy that can be achieved in different ways (and different multiple steps). A modern and frequently occurring case: using a cool framework to expose service endpoints, we write a function and then we annotate it and poof, it’s an endpoint. This is how Java+Swing works, or Python+Flask. When

Refactoring Strategy: Move It Where You Can Test It See Full Post

Refactoring: Invert Dependency With Observer

TDD, Programming, Refactoring / / 8 minutes of reading

Another refactoring today: Use the observer pattern to invert an infelicitous dependency. In and of itself, this is a modest refactoring, but its smell often co-presents with others, and unraveling it all can be tricky. (Note: We aren’t remotely done talking about first and second-order refactorings, there are plenty more to go. But I’m not writing a catalog, I’m working a project, so when a hefty one like this comes along, that’s when I’m talking about it. You’re gettin’ em

Refactoring: Invert Dependency With Observer See Full Post

Refactoring: Demeter-Wrapping

TDD, Programming, Refactoring / / 5 minutes of reading

Today, another small 2nd-order refactoring. I call it "wrap a Demeter". As with the others, this is a very modest step, but still quite useful in some situations. Demeter violations are places where a client accesses not just an upstream service, but that service’s upstream services, or even that service’s service’s upstream services. It’s a common problem in evolving code, and left untended, a classic source of unchangeable code. Demeter calls look this: a.getB().getC().doSomething() a is getting a B, but

Refactoring: Demeter-Wrapping See Full Post

Refactoring: Keep It Running

Programming, Refactoring, Change Harvesting / / 5 minutes of reading

A key value for those who take up the change-harvesting approach: "keep it running". This is actually a direct result of human, local, oriented, taken, iterative, and argues against many finish-line efficiency approaches. Think of a change as a point A, with an arrow coming out of it and ending at a point B. At the two points, we have a running system, but along the arrow, we don’t: our change is in flight. The change-harvester seeks to keep those

Refactoring: Keep It Running See Full Post

Chunking and Naming

Programming, Refactoring, Change Harvesting / / 6 minutes of reading

In our continuing conversation about refactoring, I want to go a little abstract today, and talk about chunking and naming. Naturally, a topic thisi important has already been addressed by a stupid joke in the movie Airplane!, so we’ll start there. A passenger is approached by a steward, asking if he might be able to help with a problem in the cockpit. He says, "The cockpit! What is it?". She says, "It’s the little room at the front of the

Chunking and Naming See Full Post

Scroll to Top