Начальное проектирование программ на Golang: нужен ли вам UML или что вы используете для наведения порядка?

Question

[Gudsaf]

Как я понял из беглого знакомства со статьями по применению UML, согласно концепции over-engineering, UML используется на этапе между осознанием технического задания и собственно написанием кода, потом далее при рефакторинге.

Т.е. своего рода UML - инструмент использующийся для предподготовки и предразработки самого проекта. Помогает осознать некоторые проблемы и решить их до момента программирования, что экономит ресурсы. В то же время UML - это не только диаграммы классов, но еще и компонентов, композиций, пр. (см. вики).

В свою очередь сейчас занимаюсь прочтением книги «Объектно-ориентированный анализ и проектирование» банды четырех и там как раз пропогандируется подход "7 раз отмерь - 1 отрежь", с чем я согласен. Отмеряют они как раз при помощи UML диаграмм классов, а код пишут на Java.

В то же время говорить о Go и ООП - путь скользкий, как я это понял опять же из беглых прочтений статей и избранных старниц по документации Go. Но в то же время, хочется как-то писать на го в стиле "7 раз отмерь - 1 отрежь" и все же использовать UML, или DDF или что-то еще, чтобы заранее взглянуть системно на то, что хочешь написать. Например чтобы ответить на вопросы: а нужен ли здесь интерфейс? а если я вот тут сделаю встраивание? и т.п.

Другие же источники пропогандируют написание в стиле under-engineering, когда: сделали набросок в блокнотике, написали код, посмотрели на него, выгребли фекалии, обновили набросок, пошли писать дальше - минимум доков, максимум кода. Если честно, для меня это выглядит как-то страшно.

Возможно истинный go way это как раз under-engineering, а не "7 раз отмерь - 1 отрежь". По этому хочется для себя решить как подходить к написанию кода на Go, а для этого интересно узнать какие вы UML диаграммы используете на самом начальном этапе проектирования на Go? Без разницы как вы пишете: на скорую руку или же предварительно делая достаточно полную картину проекта. Если будут и те и те ответы, то можно будет как раз посравнивать и прийти к какому-то решению.

П.С. Возможно вы и не UML используете, а что-то другое, про это тоже было бы полезно услышать.

Comments

[Cabac_B]

UML - штука редко когда нужная.
Во многих (если не большинства случаев) проекты прекрасно разрисовываются на бумажке на 3-х листиках.
Или вообще в голове.
UML - имеет смысл когда проект достаточно большой, чтобы над ним требовалось работать человекам 5 и больше.
Если ты один, если вас 2-е - не могу представить, чтобы была необходимость в UML и т.п.

Answer 1

[index0h]

Вы пытаетесь скрестить ежа с ужом.

UML схемы действительно полезны, когда сразу уместить в голове сложную систему взаимодействия не получается. Например у вас есть 5 обособленных внешних систем со своими состояниями и вам необходимо спроектировать api между каждой из них. UML в этой ситуации вас очень выручит. Если в основном будете использовать sequence диаграммы - рекомендую смотреть в сторону PlantUML. Во всяких VisualParadigm на переделки (а они будут) вы потратите кучу времени, а с текстом в PlantUML это на порядки проще.

UML и подобные штуки нужны когда у вас нет полного понимания того, что надо сделать. Когда это понимание есть - вы просто потратите время. Если же UML используется как средство документирования - используйте на здоровье.

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

Comments

[rustler2000]

+1 PlantUML sequence diagram

Answer 2

[Sergey]

1) диаграммы объектов (ответ на вопрос - границы проекта)
2) компаненты (кто учувствует)
3) сиквенс диаграммы (интеграция)