Code strukturieren, testen und versionieren

Worum es geht: Der Unterschied zwischen einem Versuch und einer Auswertung, die jeden Monat läuft, liegt nicht im Verfahren – sondern darin, ob jemand sie in einem halben Jahr noch nachvollziehen kann. Diese Lektion behandelt die vier Gewohnheiten, die das ausmachen.

1. Vom Notebook zum Skript 📄

Notebooks sind zum Erkunden hervorragend und als dauerhafte Lösung untauglich. Der Grund ist ihre größte Stärke: Man kann Zellen in beliebiger Reihenfolge ausführen. Nach zwei Stunden Arbeit weiß niemand mehr, welcher Stand tatsächlich zum Ergebnis geführt hat.

Sobald etwas wiederholt laufen soll, wandert es in ein Skript mit klarer Reihenfolge:

import pandas as pd

def laden(pfad):
    """Liest die Rohdaten ein und prüft, dass sie plausibel sind."""
    daten = pd.read_csv(pfad, sep=";")
    if daten.empty:
        raise ValueError(f"Keine Zeilen in {pfad}")
    return daten

def aufbereiten(daten):
    """Entfernt Dubletten und füllt fehlende Flächen."""
    daten = daten.drop_duplicates()
    daten["flaeche"] = daten["flaeche"].fillna(daten["flaeche"].median())
    return daten

def auswerten(daten):
    """Gesamtfläche je Kunde."""
    return daten.groupby("kunde")["flaeche"].sum()

if __name__ == "__main__":
    roh = laden("anfragen.csv")
    sauber = aufbereiten(roh)
    print(auswerten(sauber))

Drei Funktionen, jede mit einer Aufgabe und einem Satz Beschreibung. Die letzte Zeile sorgt dafür, dass das Skript direkt ausführbar bleibt, seine Funktionen aber auch anderswo verwendbar sind.

2. Tests für Datenarbeit 🧪

Tests gelten in der Datenanalyse als Luxus und sind es nicht. Zwei Arten lohnen sich fast immer.

Funktionstests prüfen, ob eine Berechnung stimmt – am besten an einem Fall, den Sie im Kopf nachrechnen können:

from auswertung import aufbereiten
import pandas as pd
import numpy as np

def test_fehlende_flaeche_wird_gefuellt():
    roh = pd.DataFrame({"kunde": ["A", "B"], "flaeche": [100, np.nan]})
    ergebnis = aufbereiten(roh)
    assert ergebnis["flaeche"].isna().sum() == 0
    assert ergebnis["flaeche"].iloc[1] == 100

Datenprüfungen laufen bei jedem Durchgang mit und schlagen an, wenn die Daten selbst nicht stimmen: Ist die Zeilenzahl plausibel? Liegen Werte im erwarteten Bereich? Sind Pflichtfelder gefüllt? Solche Prüfungen fangen Fehler ab, die kein Funktionstest findet – etwa wenn ein Vorsystem seit gestern Kommas statt Punkte liefert.

3. Versionsverwaltung für Datenprojekte 📦

Git gehört auch hier dazu, mit drei Besonderheiten. Erstens: Daten gehören nicht ins Repository – weder Rohdaten noch Ergebnisse. In die .gitignore kommen *.csv, data/ und .venv/. Zweitens: Die requirements.txt gehört unbedingt hinein, sonst ist das Projekt später nicht lauffähig. Drittens: Notebooks erzeugen bei jedem Ausführen Änderungen, auch wenn sich der Code nicht verändert hat – hier hilft ein Werkzeug, das die Ausgaben vor dem Commit entfernt.

Für die Daten selbst braucht es einen anderen Ort: einen Ordner auf dem Server, einen Objektspeicher oder eine Datenbank – mit Angabe, woher sie stammen und wann sie gezogen wurden.

4. Was nachvollziehbar machen heißt 🔁

Eine Auswertung ist nachvollziehbar, wenn jemand anderes mit denselben Eingangsdaten dasselbe Ergebnis erhält. Dafür braucht es vier Angaben, die in den Code gehören:

• Woher stammen die Daten und von welchem Datum?
• Welche Paketfassungen wurden verwendet?
• Welcher Zufallsstartwert wurde gesetzt (random_state)?
• Welche Entscheidungen wurden bei der Aufbereitung getroffen?

Der letzte Punkt ist der wichtigste und steht nirgends automatisch. Warum wurden Bestellungen unter 10 Euro ausgeschlossen? Warum fehlende Werte mit dem Median gefüllt und nicht mit dem Mittelwert? Ein Kommentar von zwei Zeilen beantwortet das – und erspart in sechs Monaten eine Stunde Rekonstruktion.

5. Mit KI-Agenten arbeiten 🤖

Für Datenarbeit mit Agenten gelten dieselben Grundsätze wie in der Softwareentwicklung, mit einer Verschärfung: Fehler in Auswertungen fallen nicht auf. Ein Programm, das abstürzt, meldet sich. Eine Auswertung, die falsch rechnet, liefert eine plausible Zahl.

Deshalb drei Regeln. Lassen Sie jede Berechnung an einem Fall prüfen, den Sie selbst nachrechnen können. Geben Sie dem Agenten die Datenstruktur mit – Spaltennamen und Typen –, nicht nur die Aufgabe. Und sehen Sie sich Zwischenergebnisse an, statt nur das Endergebnis zu betrachten.

6. Was Sie mitnehmen sollten

• Erkunden im Notebook, Wiederkehrendes im Skript.
• Eine Funktion, eine Aufgabe, ein beschreibender Name.
• Datenprüfungen fangen ab, was Funktionstests nicht sehen.
• Daten gehören nicht in Git, die requirements.txt schon.
• Entscheidungen bei der Aufbereitung kommentieren – sie sind später unsichtbar.