Refactoring and Design Patterns: A Lesson in Looking Back

You might want to forget some things from your past, but you have to remember that they’re what the future will be built upon.

Nadhif A. Prayoga
6 min readMay 22, 2021
Evolution, my dear Watson — https://stapp.space/content/images/2016/02/refactoring_poster-r723da0bee0b0423799654d8a59350032_i5v9b_8byvr_1024.jpg

So, I’ve talked about this in a previous article in the past, but once again, picture that you’re making an app. There’s this one feature that you don’t really know how to implement properly but you somehow made it work albeit being really messy and janky, spanning different files with no clear cohesiveness or anything. You think to yourself it’s a job well done and forget about it, if it works, it works, right?

A few weeks later, in comes your friend who’s working on the same app wanting to implement more feature on top of your work… only a small problem. Your janky fix is so jank that no one, not even you, could figure out what you wrote. The only solution out is to write the feature again from scratch. Now you essentially made the same feature twice, even though it shouldn’t take that long if you had taken some time to make your jank code look at least nice.

Refactoring

Never be too early or too late — https://id.pinterest.com/pin/136374694935793221/

So what is refactoring? Refactoring is the art of bettering your code without changing its external behavior and functionality. Essentially, refactoring improves something in your code whether it’s performance or readability or just making sure that the code won’t produce bugs without making your tests fail or making you have to change other pieces of related code.

Clean code, one of the article I’ve written, is one way to refactor a code to make it more maintainable. There are other ways to refactor, such as using a better algorithm or an easier to understand one. You can also refactor simply by removing unnecessary code or splitting large chunks apart.

But what exactly are its benefits?

  1. Makes a Better Team
    If you work with other people on an app, it is crucial for them to be able to read and understand what you’re working on, of course. If your code is too jank, then no one would want to read it, resulting in not many people that actually knows how the app works and not everyone being able to work on other parts.
  2. Speedy Bugfix and Development
    Find bugs easily and fix them easily. A cleaner more readable code leads to you finding the source of a problem fairly quick. This also leads to faster development time as you can understand a previous code faster and can spend more time building the next feature.
  3. Great Maintainability and Reusability
    A great code can be useful for many-many generations to come. It can also be maintained easily as new people would take less time understanding the code and have more time improving upon it.

Refactoring tells us to take a look back and see what we have created. It tells us to review and remember instead of just charging forward without care. You should and need to always mind that what you did may come back to you in the future if you didn’t reflect on it properly.

Design Patterns

Wait, how did we get here? I’ll tell you later, but first, let’s talk about design patterns.

Make sure you know — https://medium.com/au-ppl/membangun-kode-yang-lebih-baik-dengan-refactoring-dan-design-pattern-b4fec42c7909

Design patterns are ways to solve a problem that typically happens on software design. Believe it or not, there are a lot of similar problems out there when you design an app. These recurring problems have been brought down to a science by people from the past and now you can just use the same solution, or the same “pattern”, that they used.

So how does these pattern help you? Well, they speed up your development time by providing you with answers that you need for your simple problem. No longer do you need to think hard, just implement them, sort of.

Design patterns tells us to also take a look back and see what solution people have come up with that works before. If there’s a solution that works, do you really have to come up with a new one? What is the price of making a proprietary solution as opposed to a third party one? Well, that cannot be answered generally, so think about it in context of your own project

There are three types of pattern, Creational that deals with the creation of objects, Structural that deals with the structures of objects, and Behavioral that deals with the relationship between objects.

But we’re not here to talk about that, we’re here to talk about how it’s related to refactoring.

Refactoring to Patterns

Yes, you read that right. You can refactor into a design pattern. In fact, I would argue that it’s better to refactor into a design pattern rather than adopt one early on in the coding phase.

You see, there’s a phrase called “Overengineering”, making an app unnecessarily robust and complex without it ever needing to be. Early overengineering is a problem, and using too much unnecessary design pattern contributes to it.

Refactoring to patterns is a way for you to balance both. First, you can code as usual, then try to find if some of your code can be improved upon using a pattern. Of course, this may mean that you have to rewrite a bunch of code, so this method definitely have some tradeoffs.

Refactoring in Our Project

I’ll give a few common examples of what’s bad and how I improved upon it

One of the most common problem I have is duplication. This is a big problem that also includes front end. To get rid of this never forget to split up functions to smaller parts and reuse the same function that you have created instead of writing the same one.

Reusing

When you can make longer incomprehensible code into a much smaller one, that is preferred. Here’s an example of how making a list of attributes might just be better than spelling them one by one.

How one by one can be improved

You can also get dirty and complicated views. It’s best to have a separate logic with different level be on a different file. Here the function 1 and 2 should be on a different file, because one is directly related to the view and the other does not. Also it may be better to move the business logic away from the view.

Separating logic levels

And lastly, you can also refactor to improve the user’s experience. For example, on a website, you can redirect them to their previous page instead of the home page.

Better experience

Conclusion

Refactoring is a great way to make sure your code is better for everyone in terms of functionality and readability too. However, refactoring at the right time is crucial to avoid early optimization and still create pristine codes.

While design pattern might help creating a good code, using too many or adopting it too early might cause more complications. Thankfully combining it with refactoring at the right time is a great way to minimize the risk of both overengineering and being too late.

It is imperative that you refactor your code immediately after you’re done implementing the basic functionality. But make sure what you refactor actually needs refactoring in the first place.

Reference:
Refactoring to Patterns — https://industriallogic.com/xp/refactoring

--

--

Nadhif A. Prayoga
Nadhif A. Prayoga

Written by Nadhif A. Prayoga

I am a computer science student at University of Indonesia. Writing certain stuff only

No responses yet