This article is part of Proyek Perangkat Lunak (PPL) or Software Engineering Project Course. Any information written here may or may not be true. Please use it wisely and let me know if there is any wrong information in it.
What is Refactoring?
Refactoring is the process of restructuring code, while not changing its original functionality. The goal of refactoring is to improve internal code by making many small changes without altering the code’s external behavior.
Refactoring is the process of changing a software system in such a way that it does not alter the external behavior of the code, yet improves its internal structure. It is a disciplined way to clean up code that minimizes the chances of introducing bugs. In essence when you refactor you are improving the design of the code after it has been written
— Martin Fowler
TDD is very important when doing a refactoring process. It’s making sure your code behavior doesn’t change after refactoring the code.
When should code be refactored?
Refactoring can be performed after a product has been deployed, before adding updates and new features to existing code, or as a part of day-to-day programming.
When the process is performed after deployment, it is normally done before developers move on to the next project. An organization may be able to refactor more code at this point in the software delivery lifecycle, where the developers have increased availability and more time to work on the source code changes needed.
A better time to perform refactoring, though, is before adding updates or new features to existing code. When performed at this point, refactoring makes it easier for developers to build onto the existing code because they are going back and simplifying the code, making it easier to read and understand.
But in our PPL Project usually, we do a refactor after writing the code and passing the test.
What are the benefits of refactoring?
Refactoring can provide the following benefits:
- Makes the code easier to understand and read because the goal is to simplify code and reduce complexities.
- Improves maintainability and makes it easier to spot bugs or make further changes.
- Encourages a more in-depth understanding of code. Developers have to think further about how their code will mix with code already in the code base.
- Focus remains only on functionality. Not changing the code’s original functionality ensures the original project does not lose scope.
What are the challenges of refactoring?
Challenges do come with the process, however. Some of these include:
- The process will take extra time if a development team is in a rush and refactoring is not planned for.
- Without clear objectives, refactoring can lead to delays and extra work.
- Refactoring cannot address software flaws by itself, as it is made to clean code and make it less complex.
Refactoring in Gin Gonic
Go is a very flexible language with so many libraries we can explore. It’s can be a benefit, but it also can be a drawback to users because it literally has no design pattern when it comes. For example, this is Gin Gonic Project if we don’t refactor the code.
Yes, it's the whole application with all the logic inside it, notice it only contains one endpoint in this application. Imagine you are working with your team and editing one file at once for the entire project. It’s very frustrating, right? That’s why for the maintainability aspect, and team aspect we need to refactor this program to be more modular and better. We need to divide this file into other small files, that have each responsibility.
According to its name, repositories have responsibility to handle any transaction to database. We can make new file called
example_repository.go to handle any transaction related to example table.
Now we have one file to handle any transaction related to database
Services is a layer between controller and repositories. It helps to connect the URL with the repositories, also it can also contain any logic inside it. We can refactor our code to separate code like this.
Like any other framework, controller is used to accept requests from users and then proceed to service layer.
Now after refactoring the code into a few separate files, we can assemble it on our
Any other refactoring??
You can ask your SonarQube, he knows everything 😂
With refactoring your code it help you and your team to maintain the code and make your code more readable. Also in our case, separating our application into some files with each own responsibility, it helps the teams to work more modular and not be afraid of a lot of conflicts in one file.
Thanks for reading and don’t forget to be grateful!
How to build a REST API with Golang using Gin and Gorm - LogRocket Blog
Editor's note: This tutorial was last updated on 1 November 2021 to make the code examples compatible with the latest…
Golang ORM Tutorial
In this tutorial, we are going to look at how we can use the Go-ORM or GORM to interact with a sqlite3 database in a…