Как улучшить качество декомпозиции в Go?

Question

[Fledme_r]

При проектировании своего кода неприлично долго думаю над тем что нужно вынеси в отдельный пакет, а что достаточно вынести в отдельную структуру. В более ООП языках (C#, да простят меня боги C++) у меня или не возникает такой проблемы, или возникает, но в меньшей степени.
Поэтому вопрос, как можно улучить навык декомпозиции в Go и в целом ? Хотелось бы услышать о курсах, ресурсах, книгах или просто ваши советы по данному вопросу.
Спасибо.

Comments

[Александр Павлюк]

В большинстве случаев в пакет нужно выносить то, что вы в C# вынесли бы в класс.

[Fledme_r]

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

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

[Александр Павлюк]

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

[Fledme_r]

Александр Павлюк, еще раз спасибо за ответ, будем считать что тема с декомпозицией в Го закрыта. А на ваш взгляд можно ли как-то улучшить свой навык декомпозиции, или он приходит только с опытом ?

[Александр Павлюк]

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

Answer 1

[mayton2019]

неприлично долго думаю над тем что нужно вынеси в отдельный пакет, а что достаточно вынести в отдельную структуру

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

Поэтому просто откажись от декомпозиции. Пиши сначала прототип в олимпиадном стиле. Тоесть функция
main - и погнал писать как чукча. Что вижу то и пою.

И после того как ты напишешь 1000 строк например к тебе придет понимание как следует декомпозировать.
И к этому моменту у тебя будут ДОКАЗАТЕЛЬСТВА выгодности твоего дизана. И теоретические споры можно
уже исключить.

Comments

[Fledme_r]

Спасибо большое за твой ответ

Answer 2

[alhaos]

Я думал это только моя проблема, что приходится писать, потом рефакторить, потом писать, потом рефакторить ...

Comments

[calculator212]

приходится писать, потом рефакторить, потом писать, потом рефакторить

Мне кажется это обычный процесс почти для всех