← Назад
Основные приложения для этого проекта. Имя каталога для каждого приложения должно соответствовать имени исполняемого файла, который вы хотите иметь (например, /cmd/myapp). Не помещайте много кода в каталог приложения. Если вы считаете, что код можно импортировать и использовать в других проектах, он должен находиться в /pkg каталоге. Если код нельзя использовать повторно или вы не хотите, чтобы другие использовали его повторно, поместите этот код в /internal каталог. Вы будете удивлены тем, что будут делать другие, поэтому будьте откровенны в своих намерениях! Это общепринятая иметь небольшую main функцию, которая импортирует и вызывает код из /internal и /pkg каталогов, и ничего другого.
Частное приложение и код библиотеки. Это код, который вы не хотите, чтобы другие импортировали в свои приложения или библиотеки. Обратите внимание, что этот шаблон макета применяется самим компилятором Go. Смотрите Go 1.4 release notes для более подробной информации. Обратите внимание, что вы не ограничены internal каталогом верхнего уровня. Вы можете иметь более одного internal каталога на любом уровне дерева проекта. При желании вы можете добавить немного дополнительной структуры к своим внутренним пакетам для разделения вашего общего и не общего внутреннего кода. Это не требуется (особенно для небольших проектов), но приятно иметь визуальные подсказки, показывающие предполагаемое использование пакета. Фактический код вашего приложения может находиться в /internal/app каталоге (например, /internal/app/myapp) и код, используемый этими приложениями в /internal/pkg каталоге (например, /internal/pkg/myprivlib) .
Код библиотеки, который можно использовать во внешних приложениях (например, /pkg/mypubliclib). Другие проекты будут импортировать эти библиотеки, ожидая, что они будут работать, поэтому подумайте дважды, прежде чем что-то здесь поместить. Обратите внимание, что internal каталог - это лучший способ убедиться, что ваши частные пакеты не импортируются, поскольку он поддерживается Go. /pkg Каталог еще хороший способ явно сообщить, что код в этом каталоге является безопасным для использования других лиц. Это также способ сгруппировать код Go в одном месте, когда ваш корневой каталог содержит множество компонентов и каталогов, не относящихся к Go, что упрощает запуск различных инструментов Go (как упоминалось в этих выступлениях: Best Practices for Industrial Programming из GopherCon EU 2018, GopherCon 2018: Kat Zien - Как вы структурируете свои приложения Go и GoLab 2018 - Массимилиано Пиппи - Шаблоны макетов проекта в Go). Посмотрите /pkg каталог, если вы хотите увидеть, какие популярные репозитории Go используют этот шаблон макета проекта. Это обычный шаблон макета, но он не является общепринятым, и некоторые в сообществе Go не рекомендуют его. Хорошо, не используйте его, если ваш проект приложения очень мал и где дополнительный уровень вложенности не добавляет особой ценности (если вы действительно не хотите). Подумайте об этом, когда он становится достаточно большим, а ваш корневой каталог становится довольно загруженным (особенно если у вас много компонентов не-Go приложения).
Зависимости приложений (управляются вручную или вашим любимым инструментом управления зависимостями, например, новой встроенной Go Modules функцией). Команда go mod vendor создаст /vendor каталог для вас. Обратите внимание, что вам может понадобиться добавить -mod=vendor флаг к вашей go build команде, если вы не используете Go 1.14, где он включен по умолчанию. Не фиксируйте зависимости приложения, если вы создаете библиотеку. Обратите внимание, что поскольку 1.13 Go также включил функцию прокси-модуля модуля (https://proxy.golang.org по умолчанию используется в качестве прокси-сервера модуля). Узнайте больше об этом, здесь, чтобы увидеть, соответствует ли он всем вашим требованиям и ограничениям. Если это так, то vendor каталог вам вообще не понадобится.
Спецификации OpenAPI / Swagger, файлы схемы JSON, файлы определения протокола.
Специфические компоненты веб-приложений: статические веб-ресурсы, шаблоны на стороне сервера и SPA.
Шаблоны конфигурационных файлов или конфигурации по умолчанию. Разместите ваши файлы confd или consul-template шаблоны здесь.
Конфигурации системного init (systemd, upstart, sysv) и диспетчера процессов/супервизора (runit, supervisord).
Скрипты для выполнения различных операций сборки, установки, анализа и т.д. Эти скрипты делают корневой файл Makefile небольшим и простым (например, https://github.com/hashicorp/terraform/blob/master/Makefile).
Упаковка и непрерывная интеграция. Поместите в /build/package каталог конфигурации и скрипты вашего облака (AMI), контейнера (Docker), ОС (deb, rpm, pkg) и сценарии. Поместите свои конфигурации CI (travis, circle, drone) и сценарии в /build/ci каталог. Обратите внимание, что некоторые инструменты CI (например, Travis CI) очень разборчивы в расположении своих файлов конфигурации. Попробуйте поместить файлы конфигурации в /build/ci каталог, связывая их с местом, где их ожидают инструменты CI (когда это возможно).
IaaS, PaaS, конфигурации и шаблоны развертывания системной и контейнерной оркестрации (docker-compose, kubernetes/helm, mesos, terraform, bosh). Обратите внимание, что в некоторых репозиториях (особенно в приложениях, развернутых с помощью kubernetes) этот каталог называется /deploy.
Дополнительные внешние тестовые приложения и тестовые данные. Не стесняйтесь структурировать /test каталог так, как вы хотите. Для больших проектов имеет смысл иметь подкаталог данных. Например, вы можете иметь /test/data или /test/testdata, если вам нужно, Go игнорировать то, что находится в этом каталоге. Обратите внимание, что Go также будет игнорировать каталоги или файлы, начинающиеся с “.” или “_”, так что у вас больше гибкости в том, как вы называете свой каталог тестовых данных.
Дизайн и пользовательские документы (в дополнение к вашей документации, сгенерированной Godoc). Смотрите /docs каталог для примеров.
Вспомогательные инструменты для этого проекта. Обратите внимание, что эти инструменты могут импортировать код из /pkg и /internal каталогов.
Примеры для ваших приложений и / или публичных библиотек.
Внешние вспомогательные инструменты, разветвленный код и другие сторонние утилиты (например, Swagger UI).
Git крючки.
Другие ресурсы, которые можно использовать вместе с вашим хранилищем (изображения, логотипы и т. Д.).
Это место для размещения данных сайта вашего проекта, если вы не используете страницы Github.
В некоторых проектах Go есть src папка, но обычно это происходит, когда разработчики пришли из мира Java, где это обычная модель. Если вы можете помочь себе, постарайтесь не принимать этот шаблон Java. Вы действительно не хотите, чтобы ваш код Go или проекты Go выглядели как Java :-) Не путайте /src каталог уровня проекта с /src каталогом, который Go использует для своих рабочих пространств, как описано в How to Write Go Code. В $GOPATH точки переменной окружения вашего (текущей) рабочей области (по умолчанию он указывает $HOME/go на не-Windows систем). Это рабочее пространство включает в себя уровень верхнего /pkg, /bin и /src каталоги. Ваш фактический проект заканчивается время подкаталога под /src, так что если у вас есть /src каталог в проекте путь проекта будет выглядеть следующим образом: /some/path/to/workspace/src/your_project/src/your_code.go. Обратите внимание, что в Go 1.11 ваш проект может быть за пределами вашего проекта GOPATH, но это еще не значит, что стоит использовать этот шаблон макета.
| go-project
--| cmd // for binaries
-----| cli
-------> main.go
--| docs // for documentation and READMEs
--| pkg // for libs, services, interfaces
-----| api
-------> api.go
-------> api_test.go
-----| storage
-------> storage.go
-------> storage_test.go
--| vendor // for imported pacakges
-- Dockerfile
-- Makefile
-- go.mod
-- go.sum
-- // everything else
← Назад