The Motto: Red, Green, Refactor

There’s a mantra that is commonly said while developing an application. It goes “Red, Green, Refactor”. The idea is that each of these are keyframes within the development of an application feature or enhancement.

When you’re “Red”, you have a feature that either doesn’t exist, or doesn’t function the way you want it to (yet). You’ve picked up a new ticket and are getting ready to implement it. You write some initial tests that are “red” before making them green, or passing.

When you’re “Green”, the feature / enhancement works as expected. Typically to get to green you take the path of least resistance or the “happy path”. The tests you’ve written have gone from failing to passing. If you can, don’t consider something “green” unless you have a good acceptance test proving it so.

Then comes “Refactor”. This is the point of development where you take a moment to clean up some of the code / decisions you made to make the feature work. This step is critical in making sure your application is maintainable in the future. You should always be refactoring.

Rules of Refactoring

Your refactors should be quick wins. If you spend hours on refactoring something, you risk the potential of yak shaving. It can be easy to go from “oh look this is an easy change” to “wow who put this database table here, lets get rid of it”.

Another good rule of thumb when refactoring is that you should avoid changing specs / tests. Your code design should be decoupled enough from your tests that you can improve legibility, performance, etc, without touching a single tests and they still pass. Of course, if you go to do a refactor and theres a glaring thing that could be refactored that would require a change to a test, you shouldn’t throw your hands in the air and skip it. If there’s any test you really should not change, it’s your acceptance tests.

Tracking potential change

When working with a deadline, refactoring sometimes just isn’t in the priorities. A client needs something, and they need it now. This is an unavoidable reality, but it doesn’t mean you should put off a refactor forever.

When you know a piece of code you just wrote could be better but you just don’t have the time right now to implement it that way, leave a simple comment. Lets use a Ruby method to demonstrate this:

# FIXME(bobbytables): This method should really be split into its
# own object
def some_super_bad_method
 # some sins live in here
end

The format FIXME(name) is easy to search for with a tool like grep in your codebase. The name portion of the TODO is a nice way of finding just your comments, while still allowing anyone to search for any “FIXME” in the codebase.

The Rails framework also provides a way to find notes that you’ve left in your code base easily as well. In the directory that contains a Rails project, you can run:

$ rails notes
* [ 533] [TODO] This method needs some love

In Rails projects using < 5.1, this is rake notes. You can also do rails notes:fixme to only display FIXME notes in your codebase.

In general, you should be spending some time in your development cycles to clean up cut corners, apply something new you learned that you didn’t know at the time, and improve your existing application through refactoring. It leads to a healthy codebase that other developers don’t fear when they open it.

Want to learn where this fits into an actual development cycle? How another engineer goes about refactoring? Then you might be interested in the Let’s Build: FireHydrant.io series.