Learning how to write clean code and refactoring, via a Tic Tac Toe game in Ruby.
Published (updated: ) in code.
As part of the Launch School curriculum’s first course, RB101, I built a Tic Tac Toe game in Ruby. You can click here to view the repo on GitHub, including the detailed readme file with a deeper explanation of the project.
One of the most important things I learned building this project is how to refactor my own code. Before this course, my biggest goal as a programmer-in-progress was simply getting the program to run correctly. The problem with this is, while my code technically worked, it was often a massive jumbled mess of spaghetti code that was impossible to quickly understand what’s happening.
Upon looking at any program I had written previously, it would take me a while to remember what exactly all of the code did at each step. As an example, in addition to having extremely long methods, my methods were also very poorly named, not being clear at what the method actually did. I would need to have a lot of comments explaining what each method did.
A better way to write code
As I started learning more through the Launch School program, I learned that each method should do only one thing. If you need to do a second thing, that requires a second method.
I also learned that naming methods clearly and concisely makes it easier for anyone else reading my code to understand what’s going on. It also helps me remember what I had written just a few days previously, sometimes even the day before.
Clean, simple code with very good names for methods and variables reduces the need for comments within the code. The code should speak for itself as much as possible!
When your code is written cleanly, it improves the quality and clarity of your program. It also improves maintainability, whether by yourself in the future or someone else should they decide to pick up and carry the torch of your previous work. Instead of a project dying when the original developer moves on, someone else can maintain the project.
Returning to the scene of the crime: Refactoring
As a newbie developer, it’s a little painful to go back and look at the mess I made previously. I mean, my code works dang it! Why should I attempt to fix it to make it easier to understand? Shouldn’t I just back away slowly and never touch it again?
As I mentioned in the previous section, refactoring, while initially painful as an inexperienced programmer, is very important to make the code easier to maintain in the future. Once I learned the art of refactoring it also ended up being very fulfilling in the long run.
Learning how to take my jumbled mess of super long methods and break them down into smaller pieces was initially hard, but doing it helped make be a better developer. And now that I know how to refactor, it has the added benefit of forcing me to think how to write clean code from the start. Also, it forces me to keep the idea of refactoring my code in mind at all times, which helps guide my code as it’s being written.
The art of writing clean code and refactoring previously written code is not a skill I’ll be able to be an expert at immediately. It’s a skill I’m going to constantly need to work at and improve.
My project at the beginning at this article is by no means perfect and I know I can further perfect it through refactoring in the future. But I’m proud of the project because it represents a clear improvement from where my programming ability was only a few weeks ago.