Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                
Scribd Logo
Upload

Welcome to Scribd!

  • 18 views

    The Boring Programmer

    Uploaded by

    snakeza
    The document discusses best practices for structuring Go projects and packages. It recommends organizing packages by functionality and placing internal packages under an internal directory. It also covers topics like concurrency, dependencies, CI setup, CGO, errors and clear code.

    Copyright:

    © All Rights Reserved
    Download as PDF, TXT or read online from Scribd

    The Boring Programmer

    Uploaded by

    snakeza
    18 views25 pages
    The document discusses best practices for structuring Go projects and packages. It recommends organizing packages by functionality and placing internal packages under an internal directory. It also covers topics like concurrency, dependencies, CI setup, CGO, errors and clear code.

    Original Title

    The_Boring_Programmer

    Copyright

    © © All Rights Reserved

    Available Formats

    PDF, TXT or read online from Scribd

    Did you find this document useful?

    Is this content inappropriate?

    The document discusses best practices for structuring Go projects and packages. It recommends organizing packages by functionality and placing internal packages under an internal directory. It also covers topics like concurrency, dependencies, CI setup, CGO, errors and clear code.

    Copyright:

    © All Rights Reserved
    Download as PDF, TXT or read online from Scribd
    Download as pdf or txt
    18 views25 pages

    The Boring Programmer

    Uploaded by

    snakeza
    The document discusses best practices for structuring Go projects and packages. It recommends organizing packages by functionality and placing internal packages under an internal directory. It also covers topics like concurrency, dependencies, CI setup, CGO, errors and clear code.

    Copyright:

    © All Rights Reserved
    Download as PDF, TXT or read online from Scribd
    Download as pdf or txt
    of 25

    The Boring

    Programmer
    Best Practices in Go
    Project Structure
    Packages
    Packages should contain code that has a single purpose.

    Group of packages that provide the same set of functionalities should be


    organized under the same parent.

    The choices of your package have a huge impact on the testability.


    github.com/simplaex/lighthouse All programs go under cmd.
    ├── cmd/
    │ └──lighthouse/
    │ ├── subcmd/
    Each subdirectory has a matching source
    │ └── lighthouse.go code file containing the main package
    ├── internal/
    │ ├── api/
    │ ├── datastore/
    Packages under internal can be imported
    │ ├── model/ within the project, but not from outside
    │ ├── registrations/
    │ └── platform/
    |
    Model packages for your domain entities.
    └── vendor/
    ├── github.com/ Datastore package to implement your
    │ ├── golang/
    database queries.
    │ ├── go-kit/
    └── golang.org/
    Dependencies go under vendor.
    Concurrency
    Channels orchestrate
    Mutexes serialize
    Dependencies
    Dep
    dep is a prototype dependency management tool for Go.

    dep is safe for production use.

    dep is the official experiment, but not yet the official tool.

    $ dep ensure

    $ dep ensure -add github.com/foo/bar

    $ ls
    Gopkg.toml Gopkg.lock
    CI Setup
    Use gometalinter github.com/alecthomas/gometalinter.

    Over 30 tools for statically checking Go source for errors and warnings.

    Not only about nit-picking, actually points towards potential sources of bugs.

    Always test with -race.

    Especially with you integration tests, try to perform your actions concurrently
    to uncover data races.

    Data races crash your program.


    CGO
    CGO IS NOT GO
    CGO
    - Cgo must always be guarded with build tags
    // +build linux,386 darwin,!cgo

    - Context switches are very expensive


    - You assume Cgo will be fast
    - But calls to C are actually atrocious expensive
    - Treat it like a microservice
    Interface{} says Nothing
    Gofmt’s style is no one’s
    favorite, yet gofmt is
    everyone’s favorite
    Errors are values, too
    Clear is better than Clever
    Clear is better than Clever
    - Go code should be straight up boring
    - If you look at it, you should understand what it’s doing
    - You don’t put explanations into the comment
    - Being overly clever will hurt you in the long-run

    - The boring programmer writes strict and rigid code


    - That’s why Go is great for production-grade code
    Thank you
    Join Gophers Slack
    https://invite.slack.golangbridge.org/

    You might also like