Refactoring in Ruby

You’ve done it! You’ve completed your Ruby project, everything is working, no more “errors”, and your output is just as you’ve planned. You jump for joy after all the hours and late nights of work…but what now? Where does one go from here? Time to refactor.

Why refactor?

Refactoring is a critical component of the programming process. As one of the final steps before publishing your code, it provides you the chance to ensure that 1) Your code is readable for others (AND your future self), 2) Your code is efficient, and 3) Your code is easy to maintain.

Where to start?

Visual Flow

A great place to start is with the visual flow of the code itself. Some questions to ask are:

Is my code readable? Will my code induce headaches and confusion from just looking at it?

Is my code readable? Is there any sense of organization or flow?

Is everything spaced correctly? Adding space between text allows code to be easier read and understood.

Spaces should be inserted on either side of the == operators

Did I indent correctly and consistently? Though indentation is usually stylistic convention, it assists in understanding the start and end of methods and tasks accordingly.

Without indentation it’s hard to see the start and end of this method

Did I group related blocks of code together?

Each line of code builds off the other in this method; Use of line breaks is not needed

Can I delete any unused or commented out lines of code?

“# puts “State: #{find.state}” “ is unused code and may be deleted

Should I add comments? While not needed for each and every method or line of code, providing context can help distinguish one section of code from another.

Are my comments clear and descriptive?

Separation of Responsibilities

With everything visually looking the part, we can start diving into the logic and components of our code. In Ruby, Separation of Responsibilities is an important concept that ensures efficiency and scalability of one’s code, by isolating responsibility of one action from another action, or section of code. Doing so allows us to quickly make updates to our program overall, while reducing risk of creating errors, or at the very least, make it easier to debug errors through isolation.

A good strategy to employ when refactoring is to analyze your code first at the Class level: Are all of my class methods related to this class? Are my class methods the responsibility of this particular class, or should they be moved to another?

Does it make sense to initialize a new class instance within our CLI file?

On a method level: Does my method do too much? Would it be better to build this section of my method into another if so? Does this method duplicate efforts (ie: Is another method already accomplishing the same result or output)? Is there any repetitive code that can be simplified? Can I create a module to encompass repeated methods across different classes through inheritance?

#print_data method calls the #list_data method instead of doing all the work inside a single method

User Experience

In case of building an application, such as a Ruby based CLI, we also want to ensure that the user experience is taken into account. In this stage, we need to consider all information that will be displayed for the user and format output in visually sensible form. The following can be used to clearly and concisely display information to your user:

Line breaks to section off text (Ex: puts “”, or puts “ — — — — — -”):

Line breaks provide clear delineation of data sets in terminal output

Sleep commands can be used to slow down output to the terminal, replicating visual cues such as “Loading” screens to support the user experience:

sleep(0.4) inserted to evoke a Loading screen

system “clear” can be regularly utilized to effectively clear excess text in the terminal, as an overabundance of text may lead to visual confusion. This also helps build a user experience by replicating a “new screen”:

system “clear” used when beginning the CLI sequence

Final Step: Make sure it still works!

Finally, after all of our edits and cleaning up, do be sure to run your code to ensure it still works. Deleting and reorganizing code can lead to unanticipated errors or failures and we’ll want to be sure all are cleared before publishing.

In conclusion…

While the above concepts are not the end all be all of refactoring one’s code, it is my hope that some of these strategies can be used as a springboard to help make your code clearer, easier to read, and easier to maintain in the future. Congratulations! You’ve completed your project, and made it even stronger through refactoring.