Larry Morales on July 20, 2015

Code review: Refactoring (part II)

In part one I talked about what refactoring is and all stuff related to that. In this post I want to show you how refactorings are related to frameworks and give you a real example of their use.

Frameworks were design to make your life easier in some way, and they should fit to solve your problems. Nowadays developers rarely build apps from scratch, we use frameworks according to our needs to speed up construction, testing and delivery. You realize that get used to a framework doesn’t mean you are except from live without code smells. You can actually apply refactoring techniques using the components and elements those frameworks provide.

To give you an example, last week we were working in an app which was built using Ember.js framework, while we were in a manual code review activity, we found some duplicated code into three route components.

So, in a nutshell beforeModel hook validates if an user has been logged in, and if not then it redirects to login page. There is obviously a duplicated code smell winking its eye, we need to move that code into “something" that allows us to reduce changes to this logic be replicated three times or many more if new routes are defined and need to be constraint by this logic.

Remember previous post I mentioned code smells can be solved by using refactoring techniques? Move Method refactoring is the one I chose.

Before I dig in it, a question emerges, where do I put that code i’m going to move?, here is where my framework understanding should be highlighted. Ember.js introduces concepts like Mixin and Services, which were my first options to use, but then I notice Ember uses routing hierarchy delegation and it is like implementing inheritance between routes. I took latter approach, the reason was because it was a routing problem and that piece of code should be also managed at the same level, there are not another components in the app that use that kind of logic so I discarded mixing and services. ApplicationRoute is the root parent of all routes so I applied move method refactoring to put my code into it. I started applying move method in one route, tested it and then move on the next one. Here is the result.

The other routes don’t need to define this method anymore and it is also located in just one place.

To conclude, there are a few things I want to highlight about this exercise.

First thing is whatever framework, programming languages, even markup languages you use you are not except from introduce some code smells, this is something natural that happens most of time, the key is to learn to detected them and mitigate them using refactoring techniques.

Second thing is you must have a basic understanding about the framework you use, get knowledge about overall components, what are their roles, many of frameworks were built following some architectural patterns so they can make your life easier, when applying a refactoring take in account framework components first, then see if it can be solved by using low level elements like classes, objects, etc.

Finally, dedicate yourself at least 15 min of your day to learn about refactorings and code smells. For every code smell you learn try to find in your code if it exist, then apply the refactoring to mitigate it, this is the best way for training and put yourself into a different mindset. Practice and practice.

Keep Learning, Keep Applying…


Back to all posts