A buddy recently informed me that his team was going to be reworking a reasonably large backend using Go. I have a bunch of opinions (strong & loosely held) on this matter. So I finally took the time to write down my thoughts and realized it would make sense to have it out on the internet somewhere.
One thing I was tempted to put in the email, which I did not, is that I feel that Go is getting large enough that there are more and more of these kind of guidance blog posts with bad advice in them. I hope this isn't one of them. In fact, my first advice is going to be: do nothing unless you understand why you are doing it, and if you think you know why you are doing it, be sure that you know why you are doing it in the context of writing Go code.
My quick intro to stuff goes like this:
This is overkill: https://github.com/golang-standards/project-layout and doesn’t actually help with the important thing, which is: You can’t have circular package references in Go, so how do you break things out? Luckily, most of the time the answer is simple: keep everything in a single package until you have a good reason not to. But don’t break things into different packages just because it might make sense in some other language. e.g. MVC - each goes in 1 package, until it makes sense to extract a model to use elsewhere, at which point, rather than a models package, a package describing the functionality of the related models should be extracted.
There is a ton of great stuff here: https://github.com/golang/go/wiki especially https://github.com/golang/go/wiki/CodeReviewComments when working with teams.
Finally, remember that interfaces aren’t like interfaces in other languages, if you go in with the Java mindset of an interface and an implementation for everything, you are going to be creating great pain for yourself and your team.
I could expand on a lot of this, but I will wait for another time.
Good luck, I’m sure you’ll be amazed at your results and your love for such a boring simple language and environment.