Itching to refactor my Sinatra CRUD app
A couple months ago, I saw a tweet that expressed an interesting notion regarding growth and progress as a developer.
“If you’re not embarrassed by code you wrote six months ago, you’re not growing.”
or something along those lines. As a budding developer, I could certainly see this being true, but it was reassuring to see that the same applies to more seasoned vets of the industry.
I remember thinking that I was excited to get to a point where I could look back and see how far I’ve progressed. I imagined it being embarrassing, as the tweet says, but also very rewarding and exciting.
Last week, I submitted my Prayers sinatra CRUD app. In my blog post, I gave a brief overview of my process making the app, and I discussed how I felt after it was done. I was very happy with my project and how it came out. I even went so far as to proclaim “My project looked not hideous, and it was something I was much more proud to demo and show off.” This was said in regards to the user interface, but I felt a similar sense of satisfaction for the app as a whole.
This feeling did not last long.
After submitting the project, I moved onto the Ruby On Rails portion of the Flatiron School program. During one of the very first lessons in the ROR intro section, MVC architecture was discussed. This topic has been discussed in detail throughout the curriculum, although not yet in terms of Ruby on Rails. Still, I expected most of this lesson to be a review for me. I mean, I had just created an entire (simple) CRUD app using MVC architecture!
Flatiron uses an analogy of a restaurant to describe MVC architecture:
In a restaurant kitchen we have three key components:
- A chef that makes the food
- A waiter that takes the order and brings out the food
- A table where the food is served to the customer
The chef is the Model, the waiter is the Controller, and the table is the View.
To elaborate further, let’s look at the entire request flow. First, the user sends an HTTP request via the browser, perhaps by entering the URL of their favorite website. This is akin to a customer placing an order. The waiter, or the controller, receives that order and sends it over the to chef in the kitchen. The chef, or the model, receives the order and then gathers up and prepares everything needed for the customer. Often times, this requires the model to communicate with a database. To keep with the analogy, this might be like a food pantry of some sort that holds all of the ingredients in storage. Once the food is prepared, the waiter then passes it onto the table for the customer to enjoy. This is how the data from the model and database is passed on to the view template which is finally viewed and enjoyed by the customer.
A simple and effective analogy which I generally understood prior to creating my sinatra app. Unfortunately, I did not completely understand the various responsibilities of each component of the MVC architecture. Admittedly, I did catch a whiff or two… or three… of code smell when creating my CRUD app. But, it was not until I moved past and onto Rails that I realized my code’s logic and flow was totally wrong.
My views were too complicated, the controllers involved too much data manipulation, and my models contained barely any logic. My app worked as intended, and the user interface was satisfactory. Unfortunately, beneath the surface my CRUD app was CRAP. (Completely Rong & Atrociously Pungent).
My restaurant was a Hibachi Grill.
The table was the kitchen, the chef was the waiter, everything was mixed up. And like with many ill-fated restaurants, the problem started with the chef. (Sidenote, I enjoy the Hibachi grill experience once every few years. It’s a nice, niche type of restaurant, but that’s beside the point.)
My model classes lacked the logic and data manipulation that a robust model class includes. My models included few, if any, custom methods to prepare data for common requests. As a result, the responsibilities that should have belonged to the models were handled within clumsy code and method strings implemented within the controller. Even worse, the code was very not DRY. It’s like when you go to a Mexican restaurant, and an employee is going around with a cart and making guacamole in front of customers. Except that employee was never meant to make guacamole and is ill-equipped to do so. In the end, you might get your guac, but it won’t be great.
The same issue trickled into the view templates. There was too much embedded ruby logic needed to manipulate and display the required data to the user. Although not directly related, I did include makeshift “interactive” view features that are much more elegantly handled with Javascript, but this only added to the jumbled mess of erb logic. With those two issues, the code for my views is likely very difficult to read and debug.
In the end, I created an app that functioned as intended but was built atop a shaky code foundation. While I can look back and see the many mistakes I’ve made in the simple CRUD app, I’m also very excited to move forward and refactor. I’m excited to clean up the code and see how much more efficient it has become in comparison. And I’m excited to look back on the code another six months later and see how far I’ve progressed.