Refactoring 101

Posted by NaKia Whitby on April 2, 2019

The Beginning

Over the last few weeks, I’ve gotten a super hands-on introduction to refactoring. I completed and passed my CLI Data Gem Portfolio Project, RandomFacts, which returns over 100 random facts to the user. During the technical assessment, I got an in-depth overview at OO Ruby as I refactored my code to make it more dynamic and efficient. I originally had a different idea in mind, a CLI that scrapes live data from Merriam Webster’s word of the day website. Now, that my RandomFacts project was complete, I thought it would be helpful to return to my 1st project for more refactoring practice.

The Features

The WordOfTheDay CLI displays a welcome message to the user, the current date, and the current word of the day. In menu-style choices, the user is able to enter a number to request/view more detailed information such as the words part of speech, pronunciation, definition, did you know? (fun facts about the word), examples of word usage, and redisplay the word. It also has an option for redisplaying the menu and a message that prompts the user when an invalid selection occurs. Upon exiting, a message is displayed, welcoming the user to return for tomorrow’s word of the day.

The Refactor

Like all programming languages, object-oriented Ruby has a set of standards/best practices and anti-patterns that should be avoided. I began the refactoring process by first researching what makes for good OO code and what elements should be present in displaying object focused relationships. After researching, I felt as if I knew what was expected of my program and I had a more realistic approach to make the necessary changes.

After about 5 hours and much debugging using the console and Pry (which are probably my new best friends), I had a program that was explicit in showing object-oriented principles. I was satisfied, which due to an unrealistic desire to reach perfection, is something that doesn’t come easily to me. Not only did my code do a much better job at separating concerns, make better use of methods, become more dry/readable, it also loaded and displayed the data a lot faster.

While I didn’t anticipate using two domains in different projects, I can honestly say that returning to complete project 1 solidified the “why” in refactoring already functioning code and gives me a little boost of confidence as I move on to other Learn sections.