Modul 3: Nach Go portieren — C++/Java-Legacy sicher migrieren

Das Portierungs-Versprechen und seine Falle

Millionen Zeilen C++ und Java laufen in Produktion. Go ist der häufigste Weg, solche Systeme modern zu machen: schnelle Builds, ein Binary, eingebaute Concurrency. Aber wörtliches Portieren — Zeile für Zeile — konserviert die Architektur des Alt-Codes samt seiner Design-Fehler (dasselbe Phänomen, das die C→Rust-Forschung als „Fallacy" nachgewiesen hat). Du bekommst schnelleren, einfacheren Code — aber keine Garantie, dass er besser ist.

Die ehrliche Entscheidungsfrage für jedes Modul:

1. Ändert sich das Verhalten? → Neu schreiben, klar designen.
2. Ist das Verhalten stabil und komplex? → Portieren mit Round-Trip-Tests.
3. Ist die Komponente klein und isoliert? → Beliebig — Tests entscheiden.

Ist das Verhalten 1:1 nötig (Protokolle, Dateiformate)?
    ja → portieren + Round-Trip-Tests gegen das Original
    nein → neu schreiben und die Alt-API als Vertrag nehmen

// Die Grenze, die jedes subtituierte Modul braucht:
type OpStore interface {
	Load(id string) ([]Op, error)
	Save(id string, ops []Op) error
}

// Das Go-Modul implementiert das Interface; der Rest spricht nur noch
// das Interface an. Die C++/Java-Seite kann jederzeit abgeschaltet werden.

Jedes Alt-Idiom hat ein Go-Pendant

Der schnellste Weg durch jede Portierung — die Tabelle, auf die du immer zurückkommst:

// Typisierte Konstanten statt enum class:
type Status int

const (
	StatusOpen Status = iota // 0
	StatusDone               // 1
	StatusClosed             // 2
)

// Java: interface Writer { void write(String s); }
// Go:
type Writer interface {
	Write(s string) error
}

// Jeder Typ mit Write(string) error ist ein Writer. Fertig.

Vom try-catch zum if err != nil

Der größte kulturelle Umbruch beim Portieren: Exceptions verschwinden. Fehler sind Werte, die jede Funktion explizit zurückgibt. Das klingt nach Boilerplate und ist tatsächlich Fokus: Du siehst an jeder Stelle, wo etwas schiefgehen kann.

// Java: throw new IOException(...) irgendwo tief unten, catch oben.
// Go:
func readConfig(path string) (*Config, error) {
	data, err := os.ReadFile(path)
	if err != nil {
		return nil, err // der Aufrufer entscheidet
	}
	cfg, err := parse(data)
	if err != nil {
		return nil, fmt.Errorf("config %s: %w", path, err)
	}
	return cfg, nil
}

import "errors"

var ErrNotFound = errors.New("nicht gefunden")

// Irgendwo tief in der Kette:
if !exists {
	return ErrNotFound
}

// Oben:
if errors.Is(err, ErrNotFound) {
	fmt.Println("Datei oder Datensatz fehlt")
}

Panik ist nicht try/catch

panic/recover existiert in Go — aber für Programmierfehler und Invariantenbrüche, nicht für erwartbare Fehler (Eingaben, Dateien, Netz). Faustregel beim Portieren: Jedes throw wird ein return …error; nur worst-Entscheidungen (nil-deref, invariant verletzt) dürfen panic.

// SO NICHT — erwartbare Fehler gehören in Rückgabewerte:
func parseAge(s string) int {
	n, err := strconv.Atoi(s)
	if err != nil {
		panic(err) // ✗ keine Exception-Ersatz!
	}
	return n
}

Vom Thread-Pool zum Goroutine-Idiom

C++/Java-Nebenläufigkeit bedeutet meist: Threads, Locks, Thread-Pools, Futures. In Go ist die Einheit die Goroutine — leichtgewichtig (ein paar KB), millionenfach erzeugbar, und Kommunikation läuft über Channels statt über geteilten Zustand.

// Java: ExecutorService + Callable + Future.get()
// Go: Goroutine + Channel

func main() {
	type Result struct {
		name string
		err  error
	}

	results := make(chan Result)

	for _, file := range files {
		file := file // Schleifenvariable lokal binden
		go func() {
			out, err := process(file)
			results <- Result{name: file, err: err}
		}()
	}

	for range files {
		r := <-results
		if r.err != nil {
			fmt.Println("Fehler:", r.name)
		}
	}
}

// Werte über einen Channel liefern (Stream-Ersatz):
out := make(chan int)
go func() {
	defer close(out)
	for i := 0; i < 5; i++ {
		out <- i * i
	}
}()
for v := range out {
	fmt.Println(v) // 0 1 4 9 16 — close beendet die range-Schleife
}

Der Race Detector: dein Sicherheitsnetz

go test -race kompiliert dein Programm mit Instrumentierung und meldet jeden Daten-Race zur Laufzeit. Beim Portieren von Lock-Code in Channel-Code ist das die wichtigste Prüfung überhaupt.

go test -race ./...
# WARNING: DATA RACE → Zeile, beide Zugriffe, Stacktraces

// Klassischer Portierungs-Fehler — geteilte Variable ohne Schutz:
total := 0
for i := 0; i < 100; i++ {
	go func() { total++ }() // ✗ Daten-Race!
}
// richtig: atombesetzte Zähler (sync/atomic) oder Channel

Verifiziere, was du portiert hast

„Es kompiliert und läuft" ist kein Nachweis. Für jede portierte Einheit brauchst du:

1. Round-Trip-Tests — dieselbe Eingabe, gleiches Ergebnis wie das Original.
2. Fehlerpfade — ungültige Eingaben erzeugen error, keine Panik.
3. Table-driven Tests — der ganze Verhaltensraum, nicht nur der Happy Path.
4. go test -race ./... — keine Daten-Races in portierter Nebenläufigkeit.
5. Benchmarks — der Port darf nichts dramatisch langsamer machen.

// Fuzz-Tests: Zufallseingaben in den Port — findet Randfälle der Übersetzung.
func FuzzParses(f *testing.F) {
	f.Add("hallo")
	f.Add("42")
	f.Fuzz(func(t *testing.T, s string) {
		// Der Parser darf NIE panicken — egal welcher Eingabe.
		_ = parse(s)
	})
}

Wochen-Check Modul 3