2015-09-16 3 views
3

Привет, ребята, я знаю, что это может быть спорным или не очень широким, но я постараюсь быть очень конкретным и относиться к другим вопросам.Каков правильный способ организации/структуры пакетов папок и файлов?

Хорошо, когда я делаю программу Go, что я должен думать о том, как я должен организовать свой проект? (Например, должен ли я думать, что у меня будут какие-то контроллеры, поэтому у меня должен быть подкаталог контроллера, который будет делать это, поэтому я должен это сделать)

Как мне создать пакет?

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

Но пока я пишу это, я не знаю, если я должен экспортировать определенные методы в свои собственные собственные файлы, например Я бы что-то вроде

func (t *tradeBot) acceptTrade() {} 
func (t *tradeBot) declineTrade() {} 
func (t *tradeBot) monitorTrade() {} 
func (t *tradeBot) sendTrade() {} 

каждый метод будет иметь совсем немного кода, так что я должен экспортировать каждый метод в свой собственный файл или просто 1 файл с 3000 строк кода в нем?

Также используя глобальные переменные, чтобы я мог установить одну переменную, а затем оставить ее и использовать ее в нескольких функциях, или это плохо, и я должен передать переменные в качестве аргументов?

Также я должен заказать мои файлы, такие как:

package 
imports 
constants 
variables 
functions 
methods 

Или я просто положить вещи, где мне нужно их

Надеюсь, я ясно и его не страшный вопрос. Благодаря!

ответ

4

Первое место, где можно найти вдохновение, - Go standard library. Стандартная библиотека Go - довольно хороший справочник о том, какой должен выглядеть «хороший» код Go. Библиотека не совсем такая же, как приложение, но это, безусловно, хорошее введение.

В общем, вы не разложите каждый метод в свой собственный файл. Go имеет тенденцию отдавать предпочтение более крупным файлам, которые охватывают тему. Однако 3000 строк кажутся довольно большими. Даже сеть/http server.go составляет всего 2200 строк, и она довольно большая.

Глобальные переменные переменные столь же плохие, как и на любом языке. Поскольку Go полагается так сильно на параллельное программирование, глобальные изменяемые переменные довольно ужасны. Не делай этого. Одним из распространенных исключений является sync структур, таких как sync.Pool или sync.Once, которые иногда являются глобальными пакетами, но также предназначены для одновременного доступа. Существуют также иногда «по умолчанию» версии структур, такие как http.DefaultClient, но вы все равно можете передавать явные функции функциям. Опять же, просмотрите стандартную библиотеку Go и посмотрите, что является общим и что редко.

1

Просто несколько советов, которые вы, надеемся оказаться полезными:

  • Организовывать код на несколько файлов и пакетов особенностями, а не слоями. Это становится более важным, чем больше становится ваше приложение. пакет controllers с одним или двумя контроллерами, вероятно, в порядке, но установка сотен не связанных контроллеров в одном пакете не имеет никакого смысла.В следующей статье это очень хорошо объясняется: http://www.javapractices.com/topic/TopicAction.do?Id=205

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

+1

Обратите внимание, что Go имеет тенденцию использовать совершенно другую структуру пакетов, чем Java. В частности, Go стремится к более крупным пакетам, которые охватывают всю систему многократного использования, а не разделяют ее на функцию. Например, 'net' охватывает DNS, IP, создает сетевые подключения, сетевое оборудование и т. Д. В Java вы хотели бы разделить эти функции. Также обратите внимание, что пакеты Go не являются иерархическими. 'net/http' не имеет отношения к' net'. Каждый пакет стоит полностью в Go. Я согласен, что «контроллеры» - очень плохая упаковка, хотя в любой системе. И регистраторы часто являются глобальными, как вы заметили. –

+1

(Я обнаружил, что создание журналов глобально, в то время как общее, также делает тестирование в Go немного более сложным, и делает некоторые виды повторного использования кода намного сложнее. То же самое касается флагов отладки. Тем не менее, это очень распространенное решение.) –

Смежные вопросы