Extruding Code from Tests

As you may or may not know, I've been working on a game. I've also been experimenting with writing all my code in test files and extracting it.

I think I'm getting it down.

Recently, I built a lobby for my game. It's an in-memory lobby for letting people start a game on their device but it's the first step.

I started a little bit before the below video but this is where it really started getting good.

Labors of the Fastidious Coder

I spend a lot of energy on the coding equivalent of the mantra "cleanliness is next to godliness".

People sometimes think this is extra work but it's not. In fact, it's anything but that.

Fastidious coding is frontloaded work. That is, I'm taking the thing that I know is hardest - keeping my design natural to my problem - and doing that work as soon as I can.

When you do that, code-cleanliness work doesn't start to stack up into a seemingly insurmountable pile.

That psychological effect, alone, is worth the "effort" but there's a subtler, more potent source of value.

Badness compounds on badness. When you let code be bad, you do bad things to get it to work. That makes the code worse.

So, allowing a quality problem to fester not only accumulates redesign work into large chunks but also accumulates work you would never have had to do if you just kept things clean.

Following is a video wherein I spend about an hour cleaning up a test library, among other things. You can think of it as a waste of time or an expression of my perfectionism if you want to, but I would like to offer a different perspective.

What if you watch the video and try to think about all the things that could go wrong if I didn't do that cleanup, this morning?

Decoupling from Direction: Named-Lines to Numeric Rays

Please excuse the "NPR host" manner of speech and overall low sound-quality in this video but it's a great refactoring session.

The Ring

Yesterday I refactored some hokey index-based logic into a circular linked list. It spans two videos: My evening ride home and a late-night coding session.

The Importance of Deleting

At the end of my ride to my current client's office, I ruthlessly hunted down and destroyed a class I didn't need anymore.

It wasn't doing anything. It wasn't bad. I just wasn't using it anymore.

It was in a category of classes that suggests I might need it, too. So this might seem overly fastidious to some. Maybe they are even right.

My observation is that dead code turns to gangrene remarkably quickly. Removing it costs little and pays off big way more often than the reverse is true.

Cleaning Up Unity gestures library for escape tiles

Today, I cleaned up my little Unity gestures library.

I had already factored the system to recognize the State pattern implicit in the problem but I had left a little bit of the logic tangled together and driven by quasi-implicit state codes.

What I did on my ride back from my current client, today was get rid of the rest of the snarled, procedural logic.

A Continuation of Yesterday's Theme

In continuing to build my Unity gestures library, I am also continuing to experiment with developing all code in the tests and extracting as needed.

Interesting Trick I'm Trying

I saw a tweet titled something like "TDD as if you mean it". I'm sorry to whoever posted it. I can't find the link, now. The gist was that you start with only your tests and extrude a design from passing tests.

I'm experimenting with it and it's kind of interesting.

I think it might seem even less comfortable for someone who hasn't made the TDD mindset shift than "regular" TDD.

I'm digging it, though.

Refactoring to Transfer Functionality Between two MonoBehaviour Implementations

This was a lot of fun. I had one MonoBehaviour class that was hosting behavior which rightly belonged to another. I transferred the method containing the behavior, wrote down the parameters as writes to public fields, and inlined the bit that did the writes to the public fields, leaving the functionality on the other MonoBehaviour class. Then, I configured all the properties on my prefab in the editor.

Once I did that (correctly, it took me two tries), I was able to delete the fields from the old MonoBehaviour class, signifying that I had completely and correctly transferred the behavior.

It was fun.

Procedural and Environmental Approaches

I have a friend, Eran Pe'er, of DevCraft, who likens refactoring to the procedures and preferences of Brazillian Jiu-Jitsu. I don't know much about Brazillian Jie-Jitsu but I know about this way of thinking.

Every situation has a list of situations that are better than it. The transitions between certain situations are well-defined and can be learned, practiced, and shared. It's a good analogy for a style of refactoring. In this style, it is the procedures of transformation which give us our safety. A nice property of this is that it is environment-independent; you can do it with or without a meaningful battery of tests.

A procedure lets you make your situation better in a relatively-predictable way

I have a different approach; this was especially the case before I met Eran. For me, getting to the suite of comprehensive, executable specifications is what it's all about. For new code, that's easy. I just don't write any behavior before I've written a test. For legacy code, it can be more challenging. However, once I've attained the right body of tests for some code, I can refactor with impunity.

I don't care if my changes are proved to be transformative because, with NCrunch, I'm always about three seconds from finding out whether or not they were safe. For me, the focus is on creating an environment where refactoring is always safe regardless of how disciplined an approach I take.

The right conditions make certain problems irrelevant

This difference in emphasis is interesting to me. For one thing, they both have a common ancestor: culture. Neither of these methodologies can be installed without a fertile culture. For another, they both work.

A lot of people would look at two things that work and ask "which one works better?" A seemingly-natural impulse for us is to make two ideas compete so we can choose a winner. My inclination is to find a way to combine them into something new - a third option that keeps the best benefits and leaves behind the worst drawbacks.

I've been experimenting with applying discipline-focused refactoring to my own work. To be clear, I'm not giving up what I already do. I'm just adding his style to the way I already work. I'm not sure it's speeding me up but it's also not slowing me down and I've only just begun to practice it. With a few more weeks, familiarity will develop and it may well be faster.

There's something interesting there. You can combine them (at least in one direction) without any slowdown. There's a compatibility, there, that implies they are complementary techniques.

How Much Time Do You Spend Refactoring?

Software development is really mostly about design, so we should spend most of our time refactoring.

Personally, I spend almost all of my time refactoring. If a feature doesn't "fit" in my current design, it's going to be hard to test, so the test-effort tells me it won't fit.

Code-Continuity

The the Coder's Code tells us that we should never make code worse. One way to support that idea is to make sure that all your design changes do not affect behavior in any way.

I've believed this in some form or other for a while but, recently, I've made a new friend who has taken it to a whole new level. His name is Eran Pe'er and he owns a the consulting company DevCraft.

A Trick for Retraining Yourself

Previously, I suggested that one way to change your mind is to start with a discipline, evolve it into an habit, and let the habit reprogram your thinking.

Getting through the discipline phase can sometimes be challenging. In my experience, old habits try to reassert themselves a lot in this phase and sometimes they succeed.

When this happens, one trick that I used was to always undo whatever I did and redo it using the discipline I'm adopting.