<p>Hey there,</p>
<p>I am aware that this is probably not the 100 percent correct subreddit for this question but since I am currently working mostly with go and also since my current goal is to improve my design of Go programs I wanted to start here.</p>
<p>So I was watching this wonderful talk <a href="https://www.youtube.com/watch?v=zzAdEt3xZ1M" rel="nofollow">Solid GO Design</a> by Dave Cheney and I recently did some of the <a href="http://codekata.com/" rel="nofollow">Code Kata Practices</a> and it made me wonder, is there a way to actively practice good design apart from just spending years in the software development industry?</p>
<p>As a bit of background, I am not new to software development, I spent 10 years doing Java, almost got my CS degree finished, I do know what SOLID and GRASP are and I have a feel for when Code and design is bad. But and this is the key thing for me, at the moment this is mostly a feeling and I have a really hard time to assess designs and more importantly pro-actively make (high quality) design choices before I start coding. </p>
<p>So what I am asking basically is for your experiences, how you work when you design packages or start projects. Do you use checklists, guides or is it more a process that you do multiple iterations of a design? Maybe you have some good resources with practice material to dive deeper into this topic as well?</p>
<p>Thanks and all the best</p>
<hr/>**评论：**<br/><br/>phillydogg28: <pre><p>I have only been writing golang for a year now, so I am fairly new. I have created 10+ go apps, 6 are taking production workloads. In the last four or five months, I think my go code has improved dramatically and I attribute it to one key questions I keep in mind while writing go code, "How would the standard library do this?". </p>
<p>To put the thought this questions invokes in other terms, when another golang developer looks at this code, will they know what is happening <strong>without</strong> me explaining it to them. </p></pre>CreativeCoconut: <pre><p>This is a good thought, the only problem I see here that the quality of your result is always limited by your own horizon in terms of design capabilities. </p>
<p>What I mean is, that if there is something you do not know how to do right or worse do not even recognize it might be bad design you will not discover it either.</p></pre>phillydogg28: <pre><p>That is a good point. I think I do not have this issue because I assume any code I write is wrong/antipattern unless I can point to a reason for it to not be. This assumption means I always have something to improve.</p></pre>Sythe2o0: <pre><p>The first step for me is to write what I want the user's code to look like when they use the library, so that it's painless and clear what the code is doing. This has the benefit of being convertible into tests later.</p>
<p>After that, I think its just iteration. A little planning ahead is good, but too much planning ahead and you might find you've written yourself into a corner when an unexpected problem comes up. </p></pre>CreativeCoconut: <pre><p>Aiming for testability is probably one of the key things I learned since I started out with go. In my former company all testing was done by hand and no Unit tests were required which also meant that I was not forced to structure my code clearly and just had a 'code and fix' approach till the end result was ok.
I think that you should always do at least some planning or be really proficient at refactoring. Would you agree?</p></pre>Sythe2o0: <pre><p>Yes, it's important to try to structure your code in a way that uses structs and interfaces (and etc) well, and some planning should guarantee that. When I say don't overplan I mean don't plan for what the library will look like next year before you've written any functionality-- it might turn out that because of a strict plan or lofty goals you give yourself you'll resist taking a smarter approach when a functionality problem comes up with the design.</p></pre>0xjnml: <pre><blockquote>
<p>How do you practice good design?</p>
</blockquote>
<p>Sweat, blood and tears. Is there any other way?</p></pre>CreativeCoconut: <pre><p>Well, the only guaranteed end result there is a huge loss of body fluids :D</p></pre>crookc: <pre><p>Have you checked out Robert Martin's 'Clean Code' <a href="https://www.amazon.com/Clean-Code-Handbook-Software-Craftsmanship/dp/0132350882/ref=sr_1_1?ie=UTF8&qid=1502160024&sr=8-1&keywords=clean+code" rel="nofollow">book</a> and/or <a href="https://cleancoders.com/videos" rel="nofollow">videos</a>? </p>
<p>I've found Martin's material to be very helpful in actually identifying the attributes of clean code (and conversely, code smells). His examples are all in Java, which would be good for you, given your Java background. Despite his focus on Java and OOP more broadly, I think the fundamentals of clean code are language agnostic and there is plenty of carry-over to Go. He starts with rules around naming things and moves all the way through higher level design principles.</p>
<p>Fair warning though -- Martin goes totally overboard with props, green screens, theatrics, and astronomy history lessons in his videos. The book is more concise, but I'm a better visual learner, so after reading the book I started going through the videos.</p></pre>CreativeCoconut: <pre><p>Yeah I've read Clean Code though maybe not slow enough. It was actually the book which got me started to try to formalize the way I think about design. Maybe I should just revisit the book and try to get one of my old projects and try to re-do it.</p>
<p>It is a pity that the videos are rather expensive for students but it's understandable, everyone's gotta make a buck somehow<sup>^</sup></p></pre>CreativeCoconut: <pre><p>I just watched a video of him on youtube and man can he get side-tracked</p></pre>tv64738: <pre><p>Beware, most of the Design Pattern Cult is best left in Java-land.</p></pre>tv64738: <pre><p>Spending years in the software development industry is not very strongly correlated with practicing good design :-(</p></pre>
