Lectures

We break down a practical quality gate for a Go project: the order gofmt/ goimports → go test → go vet → linters ( staticcheck, golangci-lint). Why it reduces “noise,” how to read tool output, what to treat as a blocker, and what common mistakes beginners make most often.

We break down what coverage in Go actually measures (and what it does not), and how to use coverage reports as a “terrain map” to find untested branches and error handling. Using the task and report packages as examples, we show: tests for invariants and errors ( errors.Is), table-driven tests, fighting “fake” tests, and deterministic output (sorting map keys).

We break down what exactly counts as a public API in a Go package: exported names and types, signatures, errors as a contract (including %w-wrapping), observable behavior, and the order in which data is produced. Using a mini-core todo as an example, we lock down the Task model, enforce invariants via a constructor, choose an error strategy ( ErrNotFound, ValidationError), decide up front about context.Context, package boundaries and using internal/, so we can plug in new layers without rewriting the domain.

We break down why a project needs a release checklist and how it differs from a quality gate: how to confirm the build ( go build), run quick smoke tests ( go test ./...), avoid shipping a version with a “lying” README, and how to think about compatibility of exported APIs and error contracts ( errors.Is/ errors.As). At the end, you’ll see an example of a short checklist and common release-prep mistakes.

We break down why a team needs a “dependency policy” in Go: how to keep go.mod/ go.sum under control, why go mod tidy is daily hygiene, how not to break reproducibility with replace, how to pin dev-tool versions via go install pkg @ version, and why deterministic output (for example, key sorting when printing a map) is part of the same quality gate.