Redesign Your Code
The past can be hurtful, or in this case, unreadable (which might also be a form of hurt).
So you’ve completed your project. It took some time, but it’s finally running, everyone’s happy, and you finally can take a break from it. Some time later, you are called to work back on the project for some reason, maybe there’s an unchecked bug, maybe an update. Whatever the reason is, you just jump back right into it, and oh god.
Most people that revisit their old codes might have experienced this moment. It doesn’t even need to be your own code, sometimes you have to refactor someone else’s code and that is even worse, because you have even less idea on what the code’s about in the first glance. This is where refactoring comes to play.
Refactoring?
If you’ve experienced working with TDD before, you’ll already know what refactoring is. It is usually the third step of the TDD cycle, after everything has worked out.
In this step, you usually will take a look at your code and see if there’s improvements you can make. Whether it’s linter warnings, code smells, and any other stuffs that can make your code less readable. There are some methods you can try to implement refactoring. The usual one is doing clean code. Clean code generally covers most of the reasons why you need refactoring, but there are other methods that you can do as well, such as simplifying your method or breaking large chunks of code (classes, functions, etc.) into smaller ones.
Refactoring can definitely be beneficial, not just for you, but also for other people that might read your code. A good code can: make your team work better, finding bugs more easier, and making your code readable. Overall, it’s very nice to do, although it can be tedious.
It is also worth pointing out however, that you need to know your limits when refactoring. Make sure you don’t refactor too much, to the point of changing codes that might not need refactoring in the first place. If the code is unsalvageable, it might be wise to actually start over, rather than trying to refactor it and potentially consuming way more time than restarting.
Design Patterns?
Design patterns are solutions to a common problem in software design. They are somewhat of a blueprint that you can implement in your code in order to complete a certain problem. There are around 22 commonly accepted design patterns out there, which can be grouped into three categories:
- Creational: dealing with object creation
- Structural: assembling structure of objects
- Behavioral: responsibilities of objects
The good thing about having design patterns is that these patterns are tried and tested, which means that if you know about them and you find a problem that fits a pattern, you can solve that problem a tad easier than usual.
The bad thing? Well, you might have to learn about it, so if you’re in the middle of a project, taking time to learn over actually coding might not be a great idea. You might also get the wrong idea and thought this patterns are the best solution, even though sometimes you can write simpler code that also works. In the end, context really matters when you’re implementing design pattern, and it’s up to you whether using it is better or not.
Refactoring and Design Pattern in Our Project
Let’s start with design pattern first. I personally didn’t use them for this project. I have learned about design pattern 2 semesters ago, but there are reasons why I didn’t implement design patterns, to name a few:
- I learned it in Java, which was a language oriented towards OOP, which I feel would benefit more by using design patterns.
- I wasn’t really good at implementing it back when I was learning, so to implement it in a whole another language can make it more confusing.
- The workflow of the project does not really fit, in my opinion. The project we are working on is closer to subjects like Web Design and Databases, so I ended up writing codes just like when I learned those subjects.
As for refactoring, this part of the TDD cycle is where I feel like I’ve spent the most time, especially now that all that’s left are just refactoring and user testing. We’ve definitely implemented refactoring in our project, and thanks to tools like SonarQube and Linter, we have a general idea on where we should start refactoring.
For example, when I tried to refactor a form to become sequential, I’ve used a dirty solution in which I’ve basically write the same css and js file in two different html files. Of course, the duplication warning was immediate, and in the next commit I’ve moved the scripting and styling to their own files, and imported them in the html file.
As you can see (or maybe not see because it’s a bit small), refactoring very much makes sense here, as html should be about the template as much as possible, while the css and js files can be imported, so if I want to change the insides of the template, I can do so without scrolling through 100+ lines of things that can be imported in 2 lines.
There’s also another refactor where I’ve changed an html form into a Django form, as it is essentially the same thing. Using Django forms means that all the form can be condensed into one line.
Conclusion
Design patterns are just one set of many tools available to be used. Just like another tool, it’s as useful as its wielder, and it is up to you whether to implement them or not.
Refactoring on the other hand, is a must in all development cycles, as they can be a time-saver in the long run. And while you’re at it, maybe you can also refactor some codes into using design patterns, so you don’t have an excuse to at least not knowing about design patterns.
I hope you learned something from this article, and I hope you don’t feel like tearing your eyes out the next time you’re refactoring a code.
References
BONUS ROUND: Redesign Your… Logo?
This part is basically me shilling this amazing document and has nothing to do with coding.
Redesigns are good. Sometimes things are outdated, and needs to change. But I feel sometimes you could maybe overthink too much and ended up making a mess, or you ended up overkilling it.
I wrote this part just to give you readers an example of what I would call an ‘overkill’ in redesign:
This, dear readers, is a 27-page of Pepsi’s attempt at redesigning their logo. It is absolutely amazing, as it touches on things like gravitational field, the Mona Lisa, and the Pepsi Ratio, which is basically Pepsi’s version of the Golden Ratio. If you have the time, please take a look and take a look on how complicated a redesign can be (pretty sure this is an outlier though, as far as I know).
I sincerely hope you don’t have to think this much when you refactor your code.