Как я понял из беглого знакомства со статьями по применению 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 используете, а что-то другое, про это тоже было бы полезно услышать.
Простой
Простой
