Initial design of Golang programs: do you need UML or what do you use to clean up?

Question

go

As I understood from a cursory acquaintance with articles on the use of UML, according to the concept of over-engineering, UML is used at the stage between understanding the technical task and actually writing the code, then further during refactoring.
Those. a kind of UML - a tool used for pre-preparation and pre-development of the project itself. Helps to recognize some problems and solve them before programming, which saves resources. At the same time, UML is not only class diagrams, but also components, compositions, etc. ( see wiki ).
In turn, I’m currently reading the book “Object-Oriented Analysis and Design” by the gang of four, and the approach “measure 7 times - cut 1” is propagated there, with which I agree. They measure just with the help of UML class diagrams, and write the code in Java.
At the same time, talking about Go and OOP is a slippery slope, as I understood it again from quick readings of articles and selected pages on the Go documentation. But at the same time, I want to somehow write in Go in the style of "measure 7 times - cut 1" and still use UML, or DDF or something else to take a systematic look at what you want to write in advance. For example, to answer the questions: is an interface needed here? What if I do an embed here? etc.
Other sources advocate writing in the under-engineering style when: they made a sketch in a notebook, wrote the code, looked at it, removed the feces, updated the sketch, went on writing - a minimum of docks, a maximum of code. To be honest, it looks kind of scary to me.
Perhaps the true go way is just under-engineering, and not "measure 7 times - cut 1". Therefore, I want to decide for myself how to approach writing code in Go, and for this it is interesting to know what UML diagrams do you use at the very initial stage of designing in Go? It doesn't matter how you write: in haste or by making a fairly complete picture of the project beforehand. If there are both those and those answers, then it will be possible to compare and come to some kind of decision.
P.S. Perhaps you are not using UML, but something else, it would also be useful to hear about this.

Answer 1

You are trying to cross a hedgehog with a snake.
UML diagrams are really useful when you can’t immediately fit a complex system of interaction in your head. For example, you have 5 separate external systems with their own states and you need to design an api between each of them. UML will help you a lot in this situation. If you mainly use sequence diagrams, I recommend looking towards PlantUML. In any VisualParadigm, you will spend a lot of time on alterations (and they will), and with text in PlantUML it is much easier.
UML and things like that are needed when you don't have a complete understanding of what needs to be done. When this understanding is there, you will simply waste your time. If UML is used as a means of documentation - use it to your health.
As for Go - define interfaces, and then write under their implementation. Since the interfaces are duck - nothing prevents you from writing the required interfaces for your services in the packages of these services, it also defines interfaces for external use.