How I learned :code, through: :music_teaching
Part 2- Refactoring through the noise.
As you work with other programmers, you might be quick to notice that everyone writes code differently. Just like a composer thinking about which instruments might go best with the mood they want to create, you might see that you favor certain types of code over others in certain situations. Lucky for us coding is the type of art form that allows you to have your own style but achieve the same result as someone writing in a different way.
As I mentioned in my previous article, I was not too great when it came to the idea of refactoring my code. After spending tons of time on a single function or method, I was pleased just to see that it worked. I didn’t pay attention to how huge my methods became or how uneven my spacing was. But who cares? If my code works, why does it matter what it looks like? Why refactor at all?
Music encapsulates exactly why we need to refactor our code, and what we can hope our end result will look like. Take a look at the below musical example and try and figure out what’s similar or different about the measures.
What’s pretty wonderful about this example, which I used to go over with my beginner instrumentalists when they learned how to read dotted notation, is that they’re all representative of the same exact sound. That’s right, every measure in the above example sounds exactly the same. Which one looks the easiest to play? Which ones would actually show up in my music? The answer is that all of them are acceptable! Just like my ugly code, you could write any of these and they work. Some of these rhythms would be best in certain situations, but for now let’s look at the last example, as it is in its most ‘refactored’ form.
The dotted quarter note represents 1 1/2 beats in common time. If you check out the rhythmic counting underneath the example measures and compare them to each other, you might notice that all of the tied notes also take up 1 1/2 beats. That means that if a composer felt inclined, they could write a dotted quarter note in any of those places and the sound would remain unchanged. Let’s see how this works when it comes to refactoring.
When I refactor, I typically do it when my code is finished and working. This means that things could get a bit hairy in the backend, but that’s okay! At school they always say Red, Green, Refactor! Red means my code doesn’t work. Green means my code does work. Refactor means it’s time to do the thing!
Here are the questions I ask myself about my code as I refactor:
1. Did I do X somewhere already? How was it structured?
2. Is X doing multiple things? Could I refactor a part of it into a separate method? *Single Source of Truth*
3. Do I even need this?
- Did I do X somewhere already? How was it structured?
If you used too many different types of something instead of doing it in a single uniform way, you might want to refactor it. Check out both examples below:
Just like our dotted quarter notes above, we can see two different ways of writing the same thing. This is a simpler example because there’s only 1 line of difference between the two, but you get the idea. If you’re using an enumerable like in the first part of the example, it would be best if you used it that way the whole time. This will give you and anyone looking at your code the sense of “oh okay, they’re using an enumerable there.” Sticking to convention of how you write your code is a good way to refactor.
2. Is X doing multiple things? Could I refactor a part of it into a separate method? *Single Source of Truth*
Let’s take a look at a Rails example for this next one.
In this example, inside of our collection select, we’re calling on Dogs.all. This is violating our single source of truth because this form we’re writing should be just that; a form. Looking for these little things can help you refactor your code because you replace code that works with cleaner code that also works. If we give ourselves access to @dogs inside of our dogs controller by setting a variable to @dogs = Dogs.all, we can call that instead of calling on our class inside of our form. This type of refactor is more for our code end of things. It’s not going to make things look too much neater, but it makes way more sense logically.
3. Do I even need this?
Rails has a lot of things that you don’t necessarily need. When you use a generator like rails g resource or scaffold, you’re going to get a great template to set up your code. However, you might not actually use most of the template you’re given. That’s when Red, Green, Refactor really shines. If your code works and you look back and see a bunch of empty/useless methods inside of your controller page, you should just get rid of them. You’re not using it and it’s not making your code easy to look at.
Unless you’ve built out a full on crud Rails app where every controller needs to do a full CRUD (which if you’re just starting out, you probably won’t), You’re going to have a lot of extra code taking up space. Get rid of it. And then don’t forget to update your routes!
All in all, worry about making your code work first. Then cut the fat by following the three steps I listed above. You’ll find that you might have written some code that doesn’t need to be there, or something that violates our ever so important single source of truth. Try to find new ways to refactor, and if you get any better ideas to add to my list of questions, feel free to reach out!
