Давайте узнаем основные приемы о том, как правильно спроектировать вашу систему с помощью пакетов Go.

Держите свои пакеты небольшими

Я решил, что лучше, чтобы мои пакеты были небольшими. Это позволяет вам лучше изменять или повторно использовать ваши пакеты.

Позвольте им решать конкретные проблемы и не заставляйте их решать сразу несколько вещей.

При создании пакетов следуйте той же философии Unix. Маленькие вещи для создания больших.

Поместите связанные пакеты в подкаталоги

Стандартная библиотека Go использует этот стиль. Взгляните, например, на пакет http. Он находится в чистом пакете. Http-вещи относятся к сетевым вещам, поэтому они помещают их в сетевой пакет. Однако это не означает, что пакет http может использовать внутренние компоненты пакета net, это не может.

Каждый пакет go - отдельный зверь сам по себе, поэтому нет никакой связи между пакетом net и http в stdlib, кроме целей организации.

Создавайте свои пакеты как связанные кластеры

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

Постарайтесь сгруппировать ваши пакеты в более мелкие блоки связанных групп.

Скрыть почти все

Предоставьте только то, что вы хотите повторно использовать внешними пакетами, и попытайтесь скрыть все, что является внутренним по отношению к пакету.

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

Положитесь на вещи, которые не часто меняются

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

При импорте пакетов используйте свой собственный код в качестве библиотеки внутри исполняемых команд.

Предположите, что ваш код представляет собой библиотеку, и разработайте ее API как можно надежнее.

Go не имеет подпакетов

Если вы хотите разделить свои пакеты, чтобы организовать свой БОЛЬШОЙ пакет, вы можете сделать некоторые внутренние компоненты вашего пакета видимыми для внешнего мира, и поэтому любой может их импортировать. Вы можете этого не хотеть.

Внутреннее соглашение о пакете предотвращает импорт ваших пакетов с посторонних лиц. Я объясняю внутренние пакеты здесь, в этом посте.

Поместите тесты в тот же каталог

Не помещайте свой тестовый код в отдельные тестовые каталоги.

Держите их вместе, например: miner.go и miner_test.go в одном каталоге, они счастливо живут там вместе.

Поместите данные, необходимые для тестирования, в каталоги testdata в качестве подкаталога. Инструменты Go будут соблюдать это соглашение.

miner/
    miner.go
    miner_test.go
    testdata/
        hashes.data
        .

Не помещайте свой код в папки ./src

Новые суслики, которые начинают идти, создавать папки src /, вам не нужно этого делать.

Просто поместите исходные файлы в корень вашего проекта. Так лучше.

Не используйте папки src внутри своих внутренних каталогов пакетов.

Поместите внешние пакеты в папку поставщика

Я использую папки vendor в своих проектах, чтобы заблокировать зависимости, и не сохраняю их в $ GOPATH, чтобы привязать определенные версии к конкретным проектам.

В Go нет управления версиями и блокировкой пакетов.

go get всегда извлекает последнюю версию HEAD репозитория из репозитория git. Однако есть некоторые обходные пути.

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

Также вы можете использовать такие инструменты, как dep, glide, gpm, gopkg.in или другие инструменты. Эти инструменты в основном используют семантическое управление версиями для получения и блокировки версий пакетов.

Больше советов здесь.

Не экспортировать из основного

Основные пакеты не импортируются, и вам не нужно экспортировать вещи из основного пакета. Если вы не хотите использовать что-то вроде cgo.

Меньшим программам может не понадобиться много пакетов

Для небольших программ вам, вероятно, не нужно определять другой пакет, кроме специального пакета: main.

Для более крупных программ вам может потребоваться определить свои собственные пакеты для организации вашего кода.

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

Именование пакетов

Используйте простые имена

Например: http, zip и время. Вы и другие люди собираетесь использовать и вспоминать их под этим именем. Название должно быть коротким, простым, лаконичным и по существу.

Не используйте двойные или более слов в именах

Не так: net_http. Сделайте это так: net / http. Различные пакеты, но поскольку пакет http находится внутри каталога net, если был другой пакет, который также был назван как http, не будет проблема, потому что они живут в разных каталогах.

Пусть путь к пакету говорит о том, что делает пакет

net / http. Понятно, не правда ли? Пакет http - это пакет, который каким-то образом связан с сетью. Если бы он находился внутри пакета security / http, это означало бы другое значение.

Не повторяйте названия пакетов

Вместо: miner.MinerInfo используйте: miner.Info. Или вместо: weather.WeatherTemperature используйте: weather.Temperature.

Используйте общепринятые сокращения

Только если они знакомы программистам (или программистам в области создания приложения). Например: вместо formattedIO stdlib использует fmt.

Избегайте общих имен пакетов

Не так: api, models, common, utils, helper и т. Д.

Например: вместо пакета модели определите пакет, который выполняет пользовательские действия, с именем user. Или определите другой пакет для заказа клиента как заказ.

Не помещайте все в папку моделей, разбивайте их на более мелкие пакеты.

Однако до некоторой степени это идет. Если ваши отдельные пакеты нуждаются в некоторой взаимосвязи между ними, вы можете сгруппировать их вместе в зависимости от вашей цели.

Не используйте подчеркивание или верблюжий регистр.

Просто используйте строчные буквы.

Примечание. Имена могут содержать символы Юникода.

Однако я не рекомендую это использовать.

Подробнее о нейминге: посмотрите здесь и здесь.

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

Хорошо, на этом пока все. Спасибо, что дочитали до сих пор.

Давайте оставаться на связи: