Go Programming Language
Style and Guidelines
format code according to
gofmt, nothing else will be accepted
Books
The Go Programming Language (Addison-Wesley Professional Computing Series) by Alan A. A. Donovan, Brian W. Kernighan
go-internals https://github.com/teh-cmc/go-internals
Best Practices & interesting articles
Create object as interface type under the OOP concept, which will benefit in the test for mocking out different objects later on.
Go Memory Model https://golang.org/ref/mem
Tutorials
For starter: https://tour.golang.org/welcome/1
Cheatsheet https://github.com/a8m/go-lang-cheat-sheet
Package Design
GopherCon 2018: Kat Zien - How Do You Structure Your Go Apps https://youtu.be/oL6JBUk6tj0
Error Handling
JSON
Survival Tips for Beginners
Avoid frameworks, use libraries if you must, but Go encourages you to write it yourself
review comments https://github.com/golang/go/wiki/CodeReviewComments
go tools and linters, static code analysis - gometalinter, golint, errcheck, golangci-lint itp.
dont panic, pro verbs https://go-proverbs.github.io/
handle all errors, dont ignore them (use errcheck linter) https://dave.cheney.net/2016/04/27/dont-just-check-errors-handle-them-gracefully
package design https://kgoralski.gitbook.io/wiki/go-language#package-design
struct injection / constructor https://medium.com/statuscode/how-i-write-go-http-services-after-seven-years-37c208122831
interfaces and mocking them (mockery tool if possible)
avoid global state and init blocks
goroutines and for loops https://github.com/golang/go/wiki/CommonMistakes
go encourage to use channels instead of using synchronization
gofmt goimports
Tests
Go & DDD? Debatable.
"I find DDD with Go adds unnecessary complexity, because it tends more to OOP then Go. Go has its own style and trying to port it to Go may not be Go's idiomatic way. However, by keeping "some" of DDD's and general software design principles in mind will be more" - comment from https://blog.gopheracademy.com/advent-2016/go-and-package-focused-design/
"Just do the minimal and keep things decoupled in your same package for easier testing. Keep a close eye on your exported API to make sure it makes sense to others.
The best packages are those that the API is self explanatory. If you flood it with 50 domain objects, 19 aggregates, 40 value objects, 70 specifications, and 5 modules - it is no longer easy to follow.
DDD, while needed in OOO languages, tends to have an adverse effect in Go where things end up being more complicated with object graphs of several structs and aggregates - when you could have just wrote a single func that took parameters and returned an error." https://www.reddit.com/r/golang/comments/6ugzo2/domain_driven_design_and_go/
"Most if not all concepts found in DDD and similar methodologies, guides, patterns and philosophies (SOLID; separation of concerns, the open-closed principle and so forth) are all based in the thoughts of people who spent years and years doing Java and other inheritance-oriented object-models like C++. It's hard to structure such applications well while at the same time keeping enough wiggle-room around to change things later. In that sense this wisdom is priceless and has saved many programmers countless hours of work.
But Go is not like Java or C++, Go is much smaller (C++ has 85 keywords, Java has 50, Go has 25). Also, there is no inheritance and embedding is something that is only rarely used. Add to that the novel approach to implicit interface implementation and you have a language where every package hosts its own dependencies and contracts and has clearly defined boundaries.
The only conventions/patterns/rules we consider as "good practice" in the Go community is using the basic interfaces that the standard library provides (like io.Reader, io.Writer) whenever possible, instead of inventing new ones that do the same. Some additional common idioms are described in "effective go" (https://golang.org/doc/effective_go.html).
After you've written some Go code you'll realize (or get the impression that) "patternism" as I like to call it has gotten out of hand; people doing design-patterns are more concerned with the form of their programs than actually shipping functional code. Hence stuff like the often mocked "ProviderBuilderFactoryFactory". That's why I called that function the antithesis of Go." https://groups.google.com/forum/m/#!msg/Golang-nuts/0hJuub86zpo/ftx2L523uU8J
Architecture & DDD
go-kit & microservices https://www.youtube.com/watch?v=NX0sHF8ZZgw
clean arch validator https://github.com/roblaszczak/go-cleanarch
HTTP clients configuration
problems with current HTTP Client https://github.com/bradfitz/exp-httpclient/blob/master/problems.md
Performance & monitoring
go-perfbook https://github.com/dgryski/go-perfbook
Command line monitoring for goroutines https://github.com/bcicen/grmon
A tool to list and diagnose Go processes currently running on your system https://github.com/google/gops
Libraries
Go and Rx (Reactive) Extensions
Do we need it for Go? We have channels and goroutines.
Why this is important for Java https://spring.io/blog/2016/06/07/notes-on-reactive-programming-part-i-the-reactive-landscape "What is driving the rise of Reactive in Enterprise Java? Well, it’s not (all) just a technology fad — people jumping on the bandwagon with the shiny new toys. The driver is efficient resource utilization, or in other words, spending less money on servers and data centres. The promise of Reactive is that you can do more with less, specifically you can process higher loads with fewer threads. This is where the intersection of Reactive and non-blocking, asynchronous I/O comes to the foreground. For the right problem, the effects are dramatic. For the wrong problem, the effects might go into reverse (you actually make things worse). Also remember, even if you pick the right problem, there is no such thing as a free lunch, and Reactive doesn’t solve the problems for you, it just gives you a toolbox that you can use to implement solutions."
IDE
Go for Java devs
Last updated