Go-Entwicklungsmuster

Was macht Go-Entwicklungsmuster?

Idiomatische Go-Muster und Best Practices für den Bau robuster, effizienter und wartbarer Anwendungen.

Wann aktivieren

• Beim Schreiben von neuem Go-Code
• Beim Überprüfen von Go-Code
• Beim Refaktorieren bestehenden Go-Codes
• Beim Entwerfen von Go-Paketen/Modulen

Kernprinzipien

1. Einfachheit und Klarheit

Go bevorzugt Einfachheit gegenüber Klugheit. Code sollte offensichtlich und leicht lesbar sein.

// Gut: Klar und direkt
func GetUser(id string) (*User, error) {
    user, err := db.FindUser(id)
    if err != nil {
        return nil, fmt.Errorf("get user %s: %w", id, err)
    }
    return user, nil
}

// Schlecht: Übermäßig klug
func GetUser(id string) (*User, error) {
    return func() (*User, error) {
        if u, e := db.FindUser(id); e == nil {
            return u, nil
        } else {
            return nil, e
        }
    }()
}

2. Den Nullwert nutzbar machen

Entwerfen Sie Typen so, dass ihr Nullwert ohne Initialisierung sofort nutzbar ist.

// Gut: Nullwert ist nutzbar
type Counter struct {
    mu    sync.Mutex
    count int // Nullwert ist 0, bereit zur Verwendung
}

func (c *Counter) Inc() {
    c.mu.Lock()
    c.count++
    c.mu.Unlock()
}

// Gut: bytes.Buffer funktioniert mit Nullwert
var buf bytes.Buffer
buf.WriteString("hello")

// Schlecht: Erfordert Initialisierung
type BadCounter struct {
    counts map[string]int // nil-Map führt zu Panik
}

3. Interfaces akzeptieren, Strukturen zurückgeben

Funktionen sollten Interface-Parameter akzeptieren und konkrete Typen zurückgeben.

// Gut: Akzeptiert Interface, gibt konkreten Typ zurück
func ProcessData(r io.Reader) (*Result, error) {
    data, err := io.ReadAll(r)
    if err != nil {
        return nil, err
    }
    return &Result{Data: data}, nil
}

// Schlecht: Gibt Interface zurück (verbirgt Implementierungsdetails unnötig)
func ProcessData(r io.Reader) (io.Reader, error) {
    // ...
}

Fehlerbehandlungsmuster

Fehler mit Kontext umschließen

// Gut: Fehler mit Kontext umschließen
func LoadConfig(path string) (*Config, error) {
    data, err := os.ReadFile(path)
    if err != nil {
        return nil, fmt.Errorf("load config %s: %w", path, err)
    }

    var cfg Config
    if err := json.Unmarshal(data, &cfg); err != nil {
        return nil, fmt.Errorf("parse config %s: %w", path, err)
    }

    return &cfg, nil
}

Benutzerdefinierte Fehlertypen

// Domänenspezifische Fehler definieren
type ValidationError struct {
    Field   string
    Message string
}

func (e *ValidationError) Error() string {
    return fmt.Sprintf("validation failed on %s: %s", e.Field, e.Message)
}

// Sentinel-Fehler für häufige Fälle
var (
    ErrNotFound     = errors.New("resource not found")
    ErrUnauthorized = errors.New("unauthorized")
    ErrInvalidInput = errors.New("invalid input")
)

Fehlerprüfung mit errors.Is und errors.As

func HandleError(err error) {
    // Auf spezifischen Fehler prüfen
    if errors.Is(err, sql.ErrNoRows) {
        log.Println("No records found")
        return
    }

    // Auf Fehlertyp prüfen
    var validationErr *ValidationError
    if errors.As(err, &validationErr) {
        log.Printf("Validation error on field %s: %s",
            validationErr.Field, validationErr.Message)
        return
    }

    // Unbekannter Fehler
    log.Printf("Unexpected error: %v", err)
}

Fehler niemals ignorieren

// Schlecht: Fehler mit Blank-Identifier ignorieren
result, _ := doSomething()

// Gut: Fehler behandeln oder explizit dokumentieren, warum das Ignorieren sicher ist
result, err := doSomething()
if err != nil {
    return err
}

// Akzeptabel: Wenn der Fehler wirklich keine Rolle spielt (selten)
_ = writer.Close() // Best-Effort-Bereinigung, Fehler wird anderswo protokolliert

Nebenläufigkeitsmuster

Worker-Pool

func WorkerPool(jobs <-chan Job, results chan<- Result, numWorkers int) {
    var wg sync.WaitGroup

    for i := 0; i < numWorkers; i++ {
        wg.Add(1)
        go func() {
            defer wg.Done()
            for job := range jobs {
                results <- process(job)
            }
        }()
    }

    wg.Wait()
    close(results)
}

Context für Abbruch und Timeouts

func FetchWithTimeout(ctx context.Context, url string) ([]byte, error) {
    ctx, cancel := context.WithTimeout(ctx, 5*time.Second)
    defer cancel()

    req, err := http.NewRequestWithContext(ctx, "GET", url, nil)
    if err != nil {
        return nil, fmt.Errorf("create request: %w", err)
    }

    resp, err := http.DefaultClient.Do(req)
    if err != nil {
        return nil, fmt.Errorf("fetch %s: %w", url, err)
    }
    defer resp.Body.Close()

    return io.ReadAll(resp.Body)
}

Graces Shutdown

func GracefulShutdown(server *http.Server) {
    quit := make(chan os.Signal, 1)
    signal.Notify(quit, syscall.SIGINT, syscall.SIGTERM)

    <-quit
    log.Println("Shutting down server...")

    ctx, cancel := context.WithTimeout(context.Background(), 30*time.Second)
    defer cancel()

    if err := server.Shutdown(ctx); err != nil {
        log.Fatalf("Server forced to shutdown: %v", err)
    }

    log.Println("Server exited")
}

errgroup für koordinierte Goroutinen

import "golang.org/x/sync/errgroup"

func FetchAll(ctx context.Context, urls []string) ([][]byte, error) {
    g, ctx := errgroup.WithContext(ctx)
    results := make([][]byte, len(urls))

    for i, url := range urls {
        i, url := i, url // Schleifenvariablen einfangen
        g.Go(func() error {
            data, err := FetchWithTimeout(ctx, url)
            if err != nil {
                return err
            }
            results[i] = data
            return nil
        })
    }

    if err := g.Wait(); err != nil {
        return nil, err
    }
    return results, nil
}

Goroutine-Leaks vermeiden

// Schlecht: Goroutine-Leak, wenn Context abgebrochen wird
func leakyFetch(ctx context.Context, url string) <-chan []byte {
    ch := make(chan []byte)
    go func() {
        data, _ := fetch(url)
        ch <- data // Blockiert für immer, wenn kein Empfänger
    }()
    return ch
}

// Gut: Behandelt Abbruch korrekt
func safeFetch(ctx context.Context, url string) <-chan []byte {
    ch := make(chan []byte, 1) // Gepufferter Kanal
    go func() {
        data, err := fetch(url)
        if err != nil {
            return
        }
        select {
        case ch <- data:
        case <-ctx.Done():
        }
    }()
    return ch
}

Interface-Design

Kleine, fokussierte Interfaces

// Gut: Ein-Methoden-Interfaces
type Reader interface {
    Read(p []byte) (n int, err error)
}

type Writer interface {
    Write(p []byte) (n int, err error)
}

type Closer interface {
    Close() error
}

// Interfaces nach Bedarf zusammensetzen
type ReadWriteCloser interface {
    Reader
    Writer
    Closer
}

Interfaces dort definieren, wo sie verwendet werden

// Im Consumer-Paket, nicht im Provider
package service

// UserStore definiert, was dieser Service benötigt
type UserStore interface {
    GetUser(id string) (*User, error)
    SaveUser(user *User) error
}

type Service struct {
    store UserStore
}

// Konkrete Implementierung kann in einem anderen Paket sein
// Sie muss nichts über dieses Interface wissen

Optionales Verhalten mit Typ-Assertionen

type Flusher interface {
    Flush() error
}

func WriteAndFlush(w io.Writer, data []byte) error {
    if _, err := w.Write(data); err != nil {
        return err
    }

    // Flush, falls unterstützt
    if f, ok := w.(Flusher); ok {
        return f.Flush()
    }
    return nil
}

Paketorganisation

Standard-Projektstruktur

myproject/
├── cmd/
│   └── myapp/
│       └── main.go           # Einstiegspunkt
├── internal/
│   ├── handler/              # HTTP-Handler
│   ├── service/              # Geschäftslogik
│   ├── repository/           # Datenzugriff
│   └── config/               # Konfiguration
├── pkg/
│   └── client/               # Öffentlicher API-Client
├── api/
│   └── v1/                   # API-Definitionen (Proto, OpenAPI)
├── testdata/                 # Test-Fixtures
├── go.mod
├── go.sum
└── Makefile

Paketbenennung

// Gut: Kurz, Kleinbuchstaben, keine Unterstriche
package http
package json
package user

// Schlecht: Ausführlich, gemischte Groß-/Kleinschreibung oder redundant
package httpHandler
package json_parser
package userService // Redundantes 'Service'-Suffix

Paketweiten Zustand vermeiden

// Schlecht: Globaler veränderlicher Zustand
var db *sql.DB

func init() {
    db, _ = sql.Open("postgres", os.Getenv("DATABASE_URL"))
}

// Gut: Dependency Injection
type Server struct {
    db *sql.DB
}

func NewServer(db *sql.DB) *Server {
    return &Server{db: db}
}

Strukturdesign

Functional Options Pattern

type Server struct {
    addr    string
    timeout time.Duration
    logger  *log.Logger
}

type Option func(*Server)

func WithTimeout(d time.Duration) Option {
    return func(s *Server) {
        s.timeout = d
    }
}

func WithLogger(l *log.Logger) Option {
    return func(s *Server) {
        s.logger = l
    }
}

func NewServer(addr string, opts ...Option) *Server {
    s := &Server{
        addr:    addr,
        timeout: 30 * time.Second, // Standard
        logger:  log.Default(),    // Standard
    }
    for _, opt := range opts {
        opt(s)
    }
    return s
}

// Verwendung
server := NewServer(":8080",
    WithTimeout(60*time.Second),
    WithLogger(customLogger),
)

Einbettung für Komposition

type Logger struct {
    prefix string
}

func (l *Logger) Log(msg string) {
    fmt.Printf("[%s] %s\n", l.prefix, msg)
}

type Server struct {
    *Logger // Einbettung - Server bekommt Log-Methode
    addr    string
}

func NewServer(addr string) *Server {
    return &Server{
        Logger: &Logger{prefix: "SERVER"},
        addr:   addr,
    }
}

// Verwendung
s := NewServer(":8080")
s.Log("Starting...") // Ruft eingebettetes Logger.Log auf

Speicher und Leistung

Slices vorab allozieren, wenn die Größe bekannt ist

// Schlecht: Wächst mehrfach
func processItems(items []Item) []Result {
    var results []Result
    for _, item := range items {
        results = append(results, process(item))
    }
    return results
}

// Gut: Einmalige Allokation
func processItems(items []Item) []Result {
    results := make([]Result, 0, len(items))
    for _, item := range items {
        results = append(results, process(item))
    }
    return results
}

sync.Pool für häufige Allokationen verwenden

var bufferPool = sync.Pool{
    New: func() interface{} {
        return new(bytes.Buffer)
    },
}

func ProcessRequest(data []byte) []byte {
    buf := bufferPool.Get().(*bytes.Buffer)
    defer func() {
        buf.Reset()
        bufferPool.Put(buf)
    }()

    buf.Write(data)
    // Verarbeiten...
    return buf.Bytes()
}

String-Verkettung in Schleifen vermeiden

// Schlecht: Erzeugt viele String-Allokationen
func join(parts []string) string {
    var result string
    for _, p := range parts {
        result += p + ","
    }
    return result
}

// Gut: Einmalige Allokation mit strings.Builder
func join(parts []string) string {
    var sb strings.Builder
    for i, p := range parts {
        if i > 0 {
            sb.WriteString(",")
        }
        sb.WriteString(p)
    }
    return sb.String()
}

// Am besten: Standardbibliothek verwenden
func join(parts []string) string {
    return strings.Join(parts, ",")
}

Go-Tooling-Integration

Wesentliche Befehle

# Build und Ausführung
gehen Sie ./... bauen
gehen Sie ./cmd/myapp ausführen

# Tests
gehen Sie ./... testen
gehen Sie -race ./... testen
gehen Sie -cover ./... testen

# Statische Analyse
gehen Sie ./... überprüfen
statische Überprüfung ./...
golangci-lint ausführen

# Modulverwaltung
gehen Sie mod tidy
gehen Sie mod verify

# Formatierung
gofmt -w .
goimports -w .

Empfohlene Linter-Konfiguration (.golangci.yml)

linters:
  enable:
    - errcheck
    - gosimple
    - govet
    - ineffassign
    - staticcheck
    - unused
    - gofmt
    - goimports
    - misspell
    - unconvert
    - unparam

linters-settings:
  errcheck:
    check-type-assertions: true
  govet:
    enable:
      - shadow

issues:
  exclude-use-default: false

Kurzreferenz: Go-Idiome

Idiom	Beschreibung
Interfaces akzeptieren, Strukturen zurückgeben	Funktionen akzeptieren Interface-Parameter, geben konkrete Typen zurück
Fehler sind Werte	Behandeln Sie Fehler als erstklassige Werte, nicht als Ausnahmen
Nicht durch gemeinsamen Speicher kommunizieren	Verwenden Sie Kanäle zur Koordination zwischen Goroutinen
Den Nullwert nutzbar machen	Typen sollten ohne explizite Initialisierung funktionieren
Ein bisschen Kopieren ist besser als ein bisschen Abhängigkeit	Vermeiden Sie unnötige externe Abhängigkeiten
Klarheit ist besser als Klugheit	Priorisieren Sie Lesbarkeit vor Klugheit
gofmt ist niemandes Liebling, aber jedermanns Freund	Formatieren Sie immer mit gofmt/goimports
Früh zurückkehren	Behandeln Sie Fehler zuerst, halten Sie den Happy Path ohne Einrückung

Anti-Patterns, die vermieden werden sollten

// Schlecht: Nackte Returns in langen Funktionen
func process() (result int, err error) {
    // ... 50 Zeilen ...
    return // Was wird zurückgegeben?
}

// Schlecht: Panic für Kontrollfluss verwenden
func GetUser(id string) *User {
    user, err := db.Find(id)
    if err != nil {
        panic(err) // Tun Sie das nicht
    }
    return user
}

// Schlecht: Context in einer Struktur übergeben
type Request struct {
    ctx context.Context // Context sollte erster Parameter sein
    ID  string
}

// Gut: Context als erster Parameter
func ProcessRequest(ctx context.Context, id string) error {
    // ...
}

// Schlecht: Wert- und Zeigerempfänger mischen
type Counter struct{ n int }
func (c Counter) Value() int { return c.n }    // Wertempfänger
func (c *Counter) Increment() { c.n++ }        // Zeigerempfänger
// Wählen Sie einen Stil und bleiben Sie konsistent

Denken Sie daran: Go-Code sollte im besten Sinne langweilig sein – vorhersagbar, konsistent und leicht verständlich. Wenn Sie unsicher sind, halten Sie es einfach.