Look Ma: My Project in Go is Professional Now

Not too long ago, I started a new project on GitHub with an experimentation project that I thought could be interesting to share. The idea of this project was to share how to handle the most common operations with OpenSearch using the Go programming language. Why? Well, because most of the internet was flooded with content using Java and Python. Then I thought—how about rewarding my fellow Go devs with a treat while I give myself a chance to learn more about Go? This was the plot for the creation of the following repository:

This idea was well received by the community, and soon enough, I started to receive accolades for the initiative. Yay. However, I also noticed that most of the questions that I also received were not even about the Go programming language per se, but about the project structure. Questions like:

This is where I realized that I should do something about, if I wanted to continue to share this project with other developers. After all, I had started that project from an idea, and it would never be my intention to evolve the codebase into something bigger. I knew that if I wanted more people to contribute to that project, the structure of the project had to comply with the standards used by Go developers. And truth to be told, I knew few back then about how to organize a Go project given a set of specifications.

The project I had created used the following structure:

My rationale was holding the main logic of the code in a package called logic, and my types in a package called types. Everything else not related to the core code, like local based development with Docker and Terraform, would be stored in the root folder of the project. Fairly simple, right?

Well, I thought so in the beginning. But it didn't take me long enough to realize that this structure is not common out there. Just like with other programming languages, projects in Go also follow an opinionated structure about how to organize the code.

One way to get to this desirable project structure is working with someone of your team that has deep knowledge of the programming language. Another, likely faster, is using artificial intelligence to get things done for you. I will share how to do this using the latter strategy, in case you don't have someone to count on for this type of task.

Asking the AI to give you a recommendation about best practices related to project structure in Go can sometimes be a very disappointing experience. This is because best practices are subjective, and they are not common sense. It depends on each application that you want to build. For this reason, the best approach is to start with a type of AI prompting called Q&A. This is when you ask the AI to do something for you—but instruct the engine to tailor the recommendation based on your own answers.

Here is an example using Amazon Q. I had that project open, and I used the chat window from Amazon Q to ask:

I couldn't keep myself from making that pun joke about Go. Sorry about that. Anyway, as you can see, its response was a set of questions designed strategically to make its next recommendation more effective. At this point, Amazon Q session is still waiting for my response, and completely aware of the question that was originally asked.

Because of this characteristic, I can simply copy the questions provided and paste them with my own answers. Here are the answers that I provided:

...and this is what the AI responded:

As a friendly good citizen, Amazon Q is, it also provided me with the rationale about each folder decision:

With this information at your disposal, you can start developing a new feature for your project, using the feature development capability from Amazon Q.

Once you know which project structure, you are going to apply to your project, either consulting with a friend or consulting with AI, you can use the feature development capability from Amazon Q to create everything you need. Here is the prompt for this:

Eventually, you will receive a suggestion like this:

After accepting the changes, here is the surprisingly new version of the project:

Not too bad, right? Imagine how many tons of hours you can save with a project refactoring like this. Here is a complete demo of what I did:

Interestingly, Amazon Q, during the refactoring, periodically flushes its thinking process in the screen so you can follow up with what is going to be the last suggestion. This is the equivalent of you asking your friend who has expertise in this type of thing, and they say out loud their rationale before sharing their recommendation.