<p>I experienced the pleasures of golang for building web stuff for relatively small and simple projects. However small and simple projects grow to become unwieldy and unexpectedly complex. There truly is a threshold where my brain fails to visualize/remember the behaviour and structure of the current system as a whole.</p>
<p>That's where I truly believe in the power of diagramming tools not only for documenting the behaviour/structure of the system to communicate with the rest of the team effectively, but also for iterating different changes visually without having to implement it in the code in a way to experiment that a new behaviour/structure is sound to use for the longer term.</p>
<p>Long-term maintenance in my humble opinion screams for behaviour/structure diagramming tool support.</p>
<p>Particularly UML(unified modeling language) class, sequence, collaboration activity diagrams for golang round-trip engineering are sorely missed from my experience with c++ and especially java. Ada also suffers from this same pain point.</p>
<p>I would love to here how other golang programmers overcome the threshold of growing complexity and how they convey that complexity to others both technical and non-technical.</p>
<p>Thank you.</p>
<hr/>**评论：**<br/><br/>TheMerovius: <pre><p>We build very large software, but even when we use java for that, we don't use any UML or anything like that. If we need diagrams, we build them in secondary tools (mostly using graphviz, or sometimes Google Docs).</p>
<p>So… no, go doesn't have any of this. But I find the premise that you <em>need</em> it pretty questionable. But that's my opinion, of course.</p></pre>brokedown: <pre><p>Agreed. It just doesn't make sense as something baked into a language, any more than baking in all the other utility things like editors or repository hosting.</p></pre>RalphCorderoy: <pre><p>I don't see where the OP was suggesting it's something the language needs to "bake in".</p></pre>TheMerovius: <pre><p>FWIW, I believe it to be pretty straightforward to build a thing that makes diagrams of type hierarchies and call graphs and the like from go source code, if you build on guru (or the go/types package itself) and graphviz. I did that myself at some point. And that would probably be the most useful thing in that regard that would add value over diagrams manually maintained in third-party tools.</p></pre>f2f: <pre><p>here's all you ever need: <a href="http://asciiflow.com/" rel="nofollow">http://asciiflow.com/</a></p></pre>daveddev: <pre><p>That is an excellent tool. Thank you for sharing.</p></pre>SeerUD: <pre><p>Or for Mac users, there's this excellent tool: <a href="https://monodraw.helftone.com/" rel="nofollow">https://monodraw.helftone.com/</a></p></pre>RalphCorderoy: <pre><p>I've never liked UML. It various predecessors to cover different aspects were an improvement. The code describes the code. :-) It's often the data that's more in need of commentary and explanation. If it's a significant part then something like Barker's notation for entities is good, see <a href="http://www.entitylogic.org" rel="nofollow">http://www.entitylogic.org</a>. For the goroutines and channels it's more tricky. Something like a dataflow diagram, <a href="http://tentouchapps.com/madewithgrafio/Customers-Data-Flow-Diagram.jpg" rel="nofollow">http://tentouchapps.com/madewithgrafio/Customers-Data-Flow-Diagram.jpg</a>, could be squinted at with the processes as goroutines, and the data flow as a channel, and a store indicating a buffered channel, but doesn't handle passing a channel over a channel.</p></pre>anusswank: <pre><p>You can get detailed information about a Go program using <a href="https://godoc.org/go/ast" rel="nofollow">go/ast</a>. Presumably you just need to loop through that information and put it into an XML document and then you can use an existing tool to convert that into a diagram?</p></pre>materialdesigner: <pre><p>Whiteboard</p></pre>Dorianix: <pre><p>I like drawing and working with flow diagrams.
Drakon editor claims to generate go-code now.
(<a href="http://drakon-editor.sourceforge.net/" rel="nofollow">http://drakon-editor.sourceforge.net/</a>)</p></pre>weberc2: <pre><p>godoc.org has a package dependency graph feature: <a href="https://godoc.org/bitbucket.org/weberc2/fastcsv?import-graph" rel="nofollow">https://godoc.org/bitbucket.org/weberc2/fastcsv?import-graph</a></p>
<p>Not quite the resolution you're looking for, but it helps visualize the package dependencies, and you can click each package to see specifically what its constituents depend on.</p></pre>sw0r6f1sh: <pre><blockquote>
<p>I would love to here how other golang programmers overcome the threshold of growing complexity and how they convey that complexity to others both technical and non-technical.</p>
</blockquote>
<p>Why do you need tools specific for Go ? any UML tool work with Go and UML doesn't depend on a specific programming language. Your diagrams will still work whether you write Java, Ruby or Go, I don't understand the problem here. </p></pre>RalphCorderoy: <pre><p>How is passing a channel across a channel represented in UML?</p></pre>shovelpost: <pre><p>An offline, cross-platform, language agnostic solution: <a href="http://dia-installer.de/" rel="nofollow">Dia</a></p>
<p>If are using Ubuntu it's as simple to install as: <code>sudo apt-get install dia</code></p></pre>unitedcreatures: <pre><p><a href="https://golang.org/x/tools/cmd/callgraph" rel="nofollow">https://golang.org/x/tools/cmd/callgraph</a></p></pre>
