🪴 Сад Знаний

Search

SearchSearch

Организация кода в проекте

Sep 16, 2024, 3 min read

Go не накладывает ограничений на структуру проекта и расположение пакетов. Можно организовывать файлы в проекте как угодно, но есть рекомендации, придерживаясь которых вы сделаете свой проект понятным для других программистов.

Существует подход, который называется Standard Go Project Layout (см. на GitHub). В нём код проекта организуется в виде следующих директорий:

Директории в проекте

cmd

Если в проекте будет несколько бинарных файлов, создайте для них поддиректории в cmd. Имена поддиректорий должны соответствовать именам исполняемых файлов.

- cmd
    - client
        main.go
    - server
        main.go

Если в проекте один исполняемый файл, исходные файлы можно разместить прямо в директории проекта. Старайтесь использовать один-два исходных файла. Остальной код нужно вынести в отдельные пакеты.

internal

Директория internal содержит внутренние пакеты Go-проекта. На уровне компилятора запрещён импорт таких пакетов извне родительской директории internal. Например, пакет .../root/client/internal/a/b можно импортировать только в файле дерева директорий, которые начинаются с .../root/client, и нельзя в .../root/server или другом репозитории.

Рекомендуется размещать в директории internal весь основной исходный код программы, разбитый на поддиректории с соответствующими пакетами. В зависимости от сложности проекта пакеты могут иметь разный уровень вложенности.

pkg

Директорию pkg определите для пакетов, которые можно использовать в других проектах. Предпочтительнее для публичных проектов заводить отдельные репозитории.

vendor

Директория vendor содержит внешние пакеты. C появлением в Go модулей все зависимости хранятся в кеше модуля. Поэтому директорию vendor можно использовать на старых версиях Go или в том случае, если вы хотите быть уверены, что все зависимости находятся внутри директории проекта.

test

Как правило, в каждом пакете есть один или несколько тестовых файлов name_test.go. Директорию test можно использовать для комплексного тестирования с привлечением дополнительных инструментов.

docs

Директория docs предназначена для ведения документации по проекту. Это может быть документация для пользователей или дополнение к документации, которую автоматически генерирует godoc.

testdata

It’s a good practice to put all files required by your tests in a subdirectory called testdata under your project’s directory. The testdata directory has a special meaning in Go tooling that’s ignored by the Go build tool when compiling your program to ensure that testing artifacts don’t end up in your build.

Прочие директории

Вот ещё варианты директорий, которые встречаются в Go-проектах:

  • api — дополнительные файлы для сервисов с API.
  • assets — дополнительные файлы-ресурсы. Например, картинки.
  • build — файлы для упаковки и непрерывной интеграции.
  • configs — файлы конфигураций.
  • deployments/deploy — файлы конфигураций и шаблоны для сервисов, операционных систем и контейнеров.
  • examples — примеры использования приложений и библиотек.
  • sсripts — скрипты для установки, настройки и других действий с проектом.
  • tools — инструменты для поддержки проекта. Могут быть написаны на Go c использованием пакетов проекта.
  • website — директория с файлами для веб-сайта проекта.

Это неполный список. Можно создавать директории с другими именами. Старайтесь давать такие имена, которые раскрывали бы назначение директории.

Дополнительные материалы

Лучшие практики

5. Project Structure

Let’s talk about combining packages together into a project. Commonly this will be a single git repository. In the future Go developers will use the terms module and project interchangeably.

Just like a package, each project should have a clear purpose. If your project is a library, it should provide one thing, say XML parsing, or logging. You should avoid combining multiple purposes into a single project, this will help avoid the dreaded common library.

TipIn my experience, the common repo ends up tightly coupled to its biggest consumer and that makes it hard to back-port fixes without upgrading both common and consumer in lock step, bringing in a lot of unrelated changes and API breakage along the way.

If your project is an application, like your web application, Kubernetes controller, and so on, then you might have one or more main packages inside your project. For example, the Kubernetes controller I work on has a single cmd/contour package which serves as both the server deployed to a Kubernetes cluster, and a client for debugging purposes.

Link to original

📂 Go | Последнее изменение: 28.08.2024 11:37

Graph View

Backlinks