Go provides a lot of tools to help Go developers. They help Go developers to be productive when they are trying to solve their problems with Go. You can see the list of tools at https://godoc.org/golang.org/x/tools
I've seen many developers that moved from other technology stacks (Java Spring, Ruby on Rails, etc.) use the previous project structure from those to Go project. Layer-based is the one example (controller, model, service, common, util, repository, etc.). In Go, mostly, we will not do that. When we design a Go package (structure), we think about what it provides, not what it contains. And how we use them. You can read my blog about Go Package (Structure) Design
As you may know, it is painful when you are trying to refactor legacy Go package. Especially, packages like common, util, base. Because it has been used around the project (other packages use them by importing). If you refactor those packages, you need to put a lot of effort to change the import path in every derived package.
Actually, there is a Go tool for this situation. It is gomvpkg.https://godoc.org/golang.org/x/tools/cmd/gomvpkg
I'm going to show you how to refactor legacy Go package by using
gomvpkg. We have the package
You can see that
github.com/ballweera/play-gomvpkg/common/consumer has been used in only two places (
main.go). But in a large program, it may be used more than 10 or 20 times. So it is a bit difficult to refactor and take time to refactor them.
gomvpkg, we can execute only one command to change from
gomvpkg, you would see the result like this
main.go, the import path is changed to
One thing you need to know about
gomvpkg. It could not be run outside
GOPATH. So you need to move your Go project to
GOPATH before using it. And if you use
Go Module (go.mod), you also need to set
I already created the repo to play the gomvpkg https://github.com/ballweera/play-gomvpkg.
Does front-end development as a we know it still exist; or has the role evolved into something we no longer recognise? As with evolution in nature, the evolution of "front-end" has resulted in several distinct flavours --- and in my opinion --- an identity crisis.