Red-Green-Refactor

For as long as I can remember, I’ve been programming. Quite literally as long as I can remember – some of my earliest memories are copying code listings from a tattered old book into an ORIC-1, waiting ten minutes to load and save my code onto a cassette on a recorder with a broken volume control (we eventually taped a pillow to it to block out some of the screeching bits).

Oric 1

However, I’ve never been a *professional* programmer. Aside from my CS degree, I’ve never really learnt how to program in the real world – how to write elegant code that doesn’t trip over itself when you’re not looking. Sure, I could write just about anything I could think of given enough time and Google access, but I’d probably be embarrassed to actually show anyone the actual code. This is one of the key reasons why I want to become a software developer/engineer, and why I’m spending 20+ hours a week outside of a full-time job studying and developing.

One of the most useful practices I’ve learned so far is the Red/Green/Refactor element of Test-Driven Development. Previously, I would look at my To Do list and find the next feature to implement, then hack away until it was just working so I could move onto the next. This would often create unmaintainable spaghetti code and make it all the more difficult to fix or change anything later on.

Red/Green/Refactor mandates writing the tests *before* you write any code for a feature. “But what’s the point?” you may ask, “They’ll fail!” you’d say, and you’d be correct. The point of writing a test before the code is to ensure that the test actually works – if it passes before the code is written, then the test is obviously broken. Once you’re satisfied with the test, you can implement the feature in the most straightforward way possible, purely to get the test to pass (the ‘Green’ phase). Finally, you should Refactor the code into a more elegant solution.

While learning Rails, I’m writing RSpec tests and using Guard and Spork for continuous unit testing as I’m developing – literally any time I save a change to a file I can immediately see if I’ve broken anything. It’s been quite nice coming back to code a few days later and not immediately saying “What the hell was I thinking?”.

Leave a Reply

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

*