go - 什么是布局 Go 项目的明智方法

Question

关闭。这个问题是 opinion-based .它目前不接受答案。

---

想要改进这个问题吗？ 更新问题，以便 editing this post 提供事实和引用来回答它.

关闭 3 年前。

Improve this question

我有一个开始变得更加复杂的 go 项目，并希望以这样的方式布置文件系统以减少痛苦。

有没有一些很好的例子来说明什么是有意义的？

Answer 1

2013 年 5 月更新:官方文档位于“Code organization”部分中

Go code must be kept inside a workspace.
A workspace is a directory hierarchy with three directories at its root:

• src包含组织成包的 Go 源文件(每个目录一个包)，
• pkg包含包对象，并且
• bin包含可执行命令。

The go tool builds source packages and installs the resulting binaries to the pkg and bin directories.

The src subdirectory typically contains multiple version control repositories (such as for Git or Mercurial) that track the development of one or more source packages.

bin/
    streak                         # command executable
    todo                           # command executable
pkg/
    linux_amd64/
        code.google.com/p/goauth2/
            oauth.a                # package object
        github.com/nf/todo/
            task.a                 # package object
src/
    code.google.com/p/goauth2/
        .hg/                       # mercurial repository metadata
        oauth/
            oauth.go               # package source
            oauth_test.go          # test source

---

2014 年 7 月更新:参见 Structuring Applications in Go 中的“Ben Johnson”

那篇文章包括以下提示:

将二进制文件与应用程序分开

combining the main.go file and my application logic in the same package has two consequences:

• It makes my application unusable as a library.
• I can only have one application binary.

The best way I’ve found to fix this is to simply use a “cmd” directory in my project where each of its subdirectories is an application binary.

camlistore/
  cmd/
    camget/
      main.go
    cammount/
      main.go
    camput/
      main.go
    camtool/
      main.go

库驱动开发

Moving the main.go file out of your root allows you to build your application from the perspective of a library. Your application binary is simply a client of your application’s library.

Sometimes you might want users to interact in multiple ways so you create multiple binaries.
For example, if you had an “adder” package that that let users add numbers together, you may want to release a command line version as well as a web version.
You can easily do this by organizing your project like this:

adder/
  adder.go
  cmd/
    adder/
      main.go
    adder-server/
      main.go

Users can install your “adder” application binaries with “go get” using an ellipsis:

$ go get github.com/benbjohnson/adder/...

And voila, your user has “adder” and “adder-server” installed!

不要对子包发疯

Usually my project’s types are all very related so it fits better from a usability and API standpoint.
These types can also take advantage of calling unexported between them which keeps the API small and clear.

1. Group related types and code together in each file. If your types and functions are well organized then I find that files tend to be between 200 and 500 SLOC. This might sound like a lot but I find it easy to navigate. 1000 SLOC is usually my upper limit for a single file.
2. Organize the most important type at the top of the file and add types in decreasing importance towards the bottom of the file.
3. Once your application starts getting above 10,000 SLOC you should seriously evaluate whether it can be broken into smaller projects.

注意:最后的做法并不总是好的:

Sorry I just cant agree with this practice.
Separating type to files helps code management, readability, maintenancability, testability.
It may also ensure single responsibility and the follow of open/closed principle…
The rule for not allowing circular dependency is to force we have a clear structure of the packages.

---

(2013 年 2 月的替代方案，仅关于 src)
您可以在“GitHub Code Layout”中找到经典布局:

The app and both libraries live on Github, each in its own repository.
$GOPATH is the root of the project - each of your Github repos will be checked out several folders below $GOPATH.

Your code layout would look like this:

$GOPATH/
    src/
        github.com/
            jmcvetta/
                useless/
                    .git/
                    useless.go
                    useless_test.go
                    README.md
                uselessd/
                    .git/
                    uselessd.go
                    uselessd_test.go
                    README.md

Each folder under src/github.com/jmcvetta/ is the root of a separate git checkout.

这引起了一些批评，在 reddit page :

I highly recommend not structuring the repo the way you have, it'll break "go get", which is one of the most useful things about Go.
It's far better to write your code for people who do know Go, since they're most likely to be the ones compiling it.
And for people who don't, they'll at least get a feel for the language.

Put the main package in the root of the repo.
Have the assets in a subdirectory (to keep things neat).
Keep the meat of the code in a subpackage (in case anyone wants to reuse it outside your binary).
Include a setup script in the root of the repo so it's easy to find.

It's still only a two step process to download, build, install, and setup.:

• "go get <your repo path>": downloads and installs the go code, with a subdir for the assets
• $GOPATH/<your repo path>/setup.sh: distributes the assets to the right place and installs the service