Greenshift 024: The Beauty of Refactoring

Today, I'm dedicating this entire post to refactoring. Rather than continue to add stuff or fix stuff, we are simply going to clean up some of the messes that I have made over the past few weeks. We'll also prepare things so we continue to build on top of them. No new functionality today. The goal at the end of the day is to finish the day like we started. Simple interface, no new bugs.

The first change we are making today is to our fourth relationship which retrieved the most recent piece of content from the most recently resteemed author by the account we are currently viewing. In the relationship, we had two parts. In the first part we retrieved the author and in the second part we get the most recent post by that author. However, that second part basically describes the behavior of our first relationship. So we can replace all that code with a single line of code:

And that's the magic of refactoring. Making things more concise, easier to read, and more elegant overall. In the long run, this helps us to avoid bugs and makes the code easier to read. The next thing, we are going to refactor is the code in our controller. Originally, we had five different variables holding the result of each relationship, but here we condense it to one.

We also abstract the account variable out of the individual relationships so that in the future we can change the account with relative ease by changing that one variable rather than having five hard-coded instances of the same thing. This makes things more flexible.

But maybe converting the five relationships into an array of relationships doesn't make a lot of sense immediately just by looking at the code in the controller. You are taking just as much space up. Well, the benefit of this change comes at the View level:

We have reduced the view to four lines of code. Instead of explicitly stating each variable, we can now loop over the array. It may not seem like much, but if we decide to increase the number of relationships, the amount of code doesn't increase where it would in the old implementation. The final result of these changes is seen below:

And we pretty much have the same behavior. I took the "nil" strings out as they were more for debugging rather than to be used for the actual interface. So today we have accomplished a lot and have moved very little. This incremental approach to programming and coding is important in keeping one motivated even though little changes. We may have not moved closer to the goal, but we are now better prepared to work towards it.