Am I writing good Go? — Part 1
I’m going to share my experience along the way as I learn to write better Go with each passing day. The articles in this series discuss the previous design that I implemented and its shortcomings. Finally, I discuss the newer design that I chose and why did I choose it.
Answering the WHY is super important.
Disclaimer: The post is not about the “Hello World.” It is about “Oh my God! Go Code.”
“Writing code is an art.” I’ve come to believe this after numerous instances where I learned that the approach I followed had some improvement scope. It’s been 3 years, and I still believe I have to learn more.
I restructured the code 2 times, YES! 2 times, in 1 month, diving deeper and moving code around in every iteration, making it structured and modular. Although it was just a college project, I took it as an opportunity to learn to write better Go code.
I started with a simple Go code structure, all the functionalities in a few files. I didn’t start with the monolithic!
Phew!
But here is the structure I started with. If you notice, it looks as if it is well structured.
But, it isn’t!
Okay! I’ll be honest; I tried to follow the structure to the best of my convenience without thinking about the future development effort.
I faced problems when I had to edit/update the implementations of the connection objects, transaction outputs, file reading/writing.
The design is partially domain-driven as the logic that concerns each transaction is contained in its own directory. I’ve already abstracted the connection pooling to the database. The logs are stored in a separate directory. The scripts that concern the setup of the repository’s commands have their own folder, with SQL scripts' segregation. However,
It might look cleaner at first glance!
But does it FEEL CLEANER too?
I asked that questions multiple times to convince myself to say: Yes! But I knew that the code required restructuring.
So, I noted down the issues with the previous design:
- File naming and package naming issues
- A lot of moving parts
- Most of the variables were accessible by components that don’t need it.
- Code duplication
I knew the OOPS concepts but never applied those to Go. So, I was determined this time to correct what I built wrong and learn in the process. College projects are the best way to learn to write better code.
I asked one of my teammates who was working on the other half of the codebase. It was evident that her code was
Clean, Understandable, Modular, Reusable, Movable…
After 100 hours of my decision to learn and refactor, I was writing code like water. It was clean, and I knew exactly where the next piece of my code was going to go.
The newer structure as above was even cleaner. It sits somewhere in between the Domain-Driven Design and Controller-Model-Services-Dao design paradigms. It primarily uses the latter but allowed me to move the files to a single domain-specific directory if I needed to without much change—hopefully, only the package name. Because I moved each feature related implementation to its own file, I know where to navigate to resolve a bug.
The new structure is:
- Feels CLEANER!
- Modular, reusable, and extensible
- Defines clear responsibilities
- Abstracts away the complexity
It took me about 7 days to refactor the code. I worked for about 4 hours a day, which amounts to 28–30 hours. But I feel
SUPER CONFIDENT
about introducing a new package or a module or a feature in this design and not break anything else.
I wrote the documentation to allow anyone to download the project and run it. The project is open-source and available for anyone to look through history to see how I made progress:
One file at a time, One function at a time.
Feedbacks are super duper welcomed and appreciated because I’d learn from your constructive critics.
Thank You for reading it! Be Happy GOing!
Final Repo URL: https://github.com/mychewcents/tpcc-benchmarks
Old Structure Commit: e7b1ef489e1c81f5589f6bbb2617699f4db55dea
