Rec'd reading after the official docs?

<p>Hello all,</p> <p>I&#39;ve identified that the strengths and weaknesses in Go align with the goals I have for writing a new set of services in an upcoming project. Can you recommend any tutorials you may have used, tools, and common pitfalls? </p> <p>I&#39;m most interested in laying out my projects in a sensible manner, so I&#39;d really like to zero in on strategies for building readable code in a readable project tree. Most tutorials write the structs, interfaces, handlers, routes, middleware, and server Initialization in the same file..which seems weird. </p> <p>A sample project you can share in GitHub would be even better (teach a man to fish and all that)! </p> <p>Apologies for the breadth of questions, it&#39;s a good bit to wrap your head around with so many Node conventions buried in your head. </p> <p>Edit: I&#39;d like to stay away from frameworks, it seems to be for the best to use as many built in libraries as possible. Feels safer that way!</p> <hr/>**评论：**<br/><br/>_ak: <pre><p>Start out by putting everything in one file, if that grows too large, split things into files in a way it feels natural to you. Don&#39;t split out things into separate packages until you specifically <em>need</em> to have something in a different package.</p></pre>RickAndMorty_forever: <pre><p>The <code>package</code> keyword is actually tripping me up a bit here. I took the day to write some actual code and asked a follow-up question <a href="https://www.reddit.com/r/golang/comments/47gu61/question_packages_are_not_namespaces/" rel="nofollow">here</a> now that I&#39;m wanting to go the separate files route. </p></pre>thepciet: <pre><p>The golang talks on YouTube were what hooked me.</p> <p>Project layout takes practice, just put everything in main, then go overboard with packages, then you&#39;ll go back to center with a good way to split. Understanding the value of interface types goes along with this, which is maybe a ways down the road.</p> <p>You are going to have a tough time delivering something if your entire team is not very experienced with software projects. Go makes many things better, but there&#39;s a lot to know before knowing what better is.</p></pre>mostlywaiting: <pre><p>If you&#39;re done with the official docs, start reading the official lib directly. It is very well put together. Copying its style would be a great place to start (or even stay!) and you&#39;ll be even more familiar with the standard tools.</p> <p>Don&#39;t neglect the tests, either.</p></pre>