https://www.commandercoriander.net/blog/2017/12/31/writing-go/
blog-post-what-i-learned-writing-go#rust-package-manager1Spending some time with Rust has reminded me how sorely Go needs an officially supported dependency management tool as part of the Go toolchain blog-post-what-i-learned-writing-go#rust-package-manager1
blog-post-what-i-learned-writing-go#package-driven-developmentIn particular, I have discovered the value of Package Driven Development, i.e., writing code that looks good when running godoc some-package, a practice which shares a history with conventions in the Python community. The documentation for a package should be easy to understand, it should be intention revealing, and it should be meaningful. blog-post-what-i-learned-writing-go#package-driven-development
blog-post-what-i-learned-writing-go#ubiquitous-language1There seems to be a consensus that writing well-tested code is important. What is lacking, though, is a clear understanding of the differences between test-doubles, mocks, spies, stubs, and fakes. Uncle Bob has explained what each of these terms mean in his blog-post-the-little-mocker. On Loggregator, we had a mix of all these terms and they were rarely used correctly. It may seem pedantic to insist on using these terms correctly, but then again, software engineering leaves little room for ambiguity, so why would we not use the same standards for our choice of words? In my view, a shared nomenclature – what has elsewhere been called a "ubiquitous language" – is the first and most important thing for a team of engineers. blog-post-what-i-learned-writing-go#ubiquitous-language1
Referred to
video-writing-great-documentation