Eine Funktion in einer bestehenden Web-App ergänzen: Ablauf und Abnahme

Viele Web-Apps kleiner Firmen sind irgendwann „fertig" und laufen. Dann kommt der Wunsch nach einer Kleinigkeit: ein Filter in der Kundenliste, ein Export als CSV, ein Pflichtfeld im Bestellformular. Für ein eigenes Projekt ist das zu klein, aber die App ist zu wichtig, um einfach jemanden darin herumprobieren zu lassen.

Dieser Beitrag beschreibt einen Ablauf, mit dem solche Erweiterungen kontrolliert in eine bestehende Anwendung kommen. Er funktioniert unabhängig davon, ob ein Dienstleister, ein Freelancer oder jemand aus Ihrem Team die Arbeit macht.

1. Die Funktion an einem Beispiel beschreiben

Eine gute Beschreibung beginnt nicht mit der Technik, sondern mit einem konkreten Fall aus Ihrem Alltag:

In der Auftragsliste möchte ich nach Status filtern können. Wenn ich „offen" wähle, sehe ich nur Aufträge mit Status offen. Die Auswahl bleibt erhalten, wenn ich die Seite neu lade.

Daraus lassen sich drei Dinge ableiten, die jeder Entwickler braucht:

• Wo die Änderung sichtbar wird (Auftragsliste).
• Was passiert (Filter nach Status).
• Welche Sonderfälle wichtig sind (Auswahl bleibt nach Neuladen erhalten).

Schreiben Sie dazu, was ausdrücklich nicht gemeint ist. „Keine Mehrfachauswahl" oder „der Export muss den Filter nicht berücksichtigen" spart später Diskussionen.

2. Den Umfang abgrenzen

Eine Funktion ist dann gut abgegrenzt, wenn sie an einer Stelle der Anwendung etwas Neues ermöglicht, ohne bestehende Abläufe umzubauen. Hilfreich ist eine kurze Liste:

Gehört dazu	Gehört nicht dazu
Filter-Auswahl in der Liste	Neue Statuswerte
Speichern der Auswahl in der URL	Änderungen an der Datenbankstruktur
Test für den Filter	Umgestaltung der gesamten Liste

Wird beim Abgrenzen klar, dass doch eine Datenbankänderung oder ein Umbau nötig ist, ist das wertvolle Information. Dann teilt man die Aufgabe in zwei Pakete, statt eine große unklare Aufgabe zu beginnen.

3. Zugang geben, ohne die Kontrolle abzugeben

Für Code in GitHub, GitLab oder Bitbucket ist der übliche Weg eine Einladung in das Repository. Der Entwickler arbeitet auf einem eigenen Branch, also einer Kopie des Codes, die Ihre laufende Version nicht berührt. Zugangsdaten zum Produktivserver braucht er dafür nicht.

Falls die App Konfigurationswerte wie API-Schlüssel benötigt, sollten diese nie im Code landen, sondern in Umgebungsvariablen. Für die Entwicklung genügen in der Regel Test-Schlüssel oder eine Staging-Umgebung. Mehr dazu im Beitrag Zugänge sicher teilen.

4. Umsetzung auf einem eigenen Branch

Technisch sieht der Ablauf so aus:

1. Vom aktuellen Hauptzweig (meist main) wird ein Branch abgezweigt, etwa feature/auftragsfilter.
2. Die Funktion wird dort umgesetzt, in kleinen, nachvollziehbaren Commits.
3. Für das neue Verhalten kommen Tests dazu. Mindestens ein Test sollte genau den Fall aus der Beschreibung abbilden.
4. Der bestehende Build und die vorhandenen Tests müssen weiterhin durchlaufen.

Ein Test für das Beispiel oben könnte in einer Next.js- oder React-App mit Vitest so aussehen:

import { describe, expect, it } from "vitest";
import { filterOrders } from "./filterOrders";

const orders = [
  { id: 1, status: "offen" },
  { id: 2, status: "erledigt" },
  { id: 3, status: "offen" },
];

describe("filterOrders", () => {
  it("zeigt nur Aufträge mit dem gewählten Status", () => {
    expect(filterOrders(orders, "offen").map(o => o.id)).toEqual([1, 3]);
  });

  it("zeigt alle Aufträge ohne Filter", () => {
    expect(filterOrders(orders, null)).toHaveLength(3);
  });
});

Solche Tests sind kein Selbstzweck. Sie stellen sicher, dass die nächste Änderung in sechs Monaten den Filter nicht versehentlich wieder kaputt macht.

5. Übergabe als Pull Request

Am Ende steht ein Pull Request (bei GitLab: Merge Request). Das ist ein Antrag, die Änderungen aus dem Branch in den Hauptzweig zu übernehmen. Entscheidend ist: Übernehmen tun Sie, nicht der Entwickler. Bis Sie auf „Merge" klicken, ändert sich an Ihrer laufenden Anwendung nichts.

Ein brauchbarer Pull Request enthält:

• eine kurze Beschreibung, was geändert wurde und warum,
• die Liste der geänderten Stellen in verständlicher Sprache,
• Prüfschritte, mit denen Sie die Funktion selbst ausprobieren können,
• Hinweise auf alles, was beim Ausrollen zu beachten ist (neue Umgebungsvariable, Migration, Cache leeren).

Wie Sie einen Pull Request prüfen, ohne selbst zu programmieren, beschreibt der Beitrag Pull Requests prüfen, ohne Entwickler zu sein.

6. Abnahme anhand vorher vereinbarter Kriterien

Die Abnahme ist der Moment, in dem Sie bestätigen, dass das vereinbarte Ergebnis vorliegt. Damit das nicht zur Geschmacksfrage wird, sollten die Kriterien vor Beginn der Arbeit feststehen. Für das Filterbeispiel:

• In der Auftragsliste gibt es eine Auswahl „Status" mit den vorhandenen Statuswerten.
• Bei Auswahl „offen" erscheinen nur Aufträge mit Status offen.
• Nach dem Neuladen der Seite ist die Auswahl noch aktiv.
• Ohne Auswahl erscheinen alle Aufträge wie bisher.
• Build und bestehende Tests laufen durch, ein neuer Test deckt den Filter ab.
• Im Code stehen keine Zugangsdaten.

Prüfen können Sie das am besten in einer Vorschau-Umgebung. Viele Hoster wie Vercel oder Netlify erzeugen für jeden Pull Request automatisch eine eigene Vorschau-URL. Gibt es das nicht, kann der Entwickler die Prüfschritte so beschreiben, dass jemand mit Zugriff auf eine Staging-Umgebung sie nachvollziehen kann.

Ist ein Kriterium nicht erfüllt, benennen Sie genau dieses Kriterium. „Funktioniert nicht" hilft niemandem weiter, „Nach dem Neuladen ist der Filter wieder leer" schon.

7. Ausrollen und danach

Nach dem Merge wird die Änderung so ausgerollt, wie Ihre Anwendung sonst auch aktualisiert wird, bei vielen Setups automatisch. Planen Sie das nicht für Freitagnachmittag. Prüfen Sie danach einmal kurz die Funktion in der Live-Umgebung, und widerrufen Sie Zugänge, die nur für diese Aufgabe erteilt wurden.

Was die Arbeit beschleunigt

Ein großer Teil der Zeit bei Aufgaben in fremden Anwendungen geht nicht in die Funktion selbst, sondern in die Orientierung. Folgende Dinge helfen spürbar:

• Eine Anleitung, wie die App lokal gestartet wird, oder Zugang zu einer Staging-Umgebung.
• Testdaten, mit denen sich die Funktion ausprobieren lässt, ohne echte Kundendaten zu verwenden.
• Ein Screenshot der Stelle, an der die Funktion erscheinen soll, gern mit einer groben Skizze.
• Ein Hinweis auf eine ähnliche, bereits vorhandene Funktion, an der man sich orientieren kann.

Häufige Stolpersteine

• Die Beschreibung wächst während der Arbeit. „Und wenn Sie schon dabei sind …" ist der häufigste Grund, warum kleine Aufgaben groß werden. Notieren Sie neue Ideen als eigene Aufgabe.
• Der Hauptzweig hat sich verändert. Arbeitet parallel jemand anderes am Code, kann es Konflikte geben. Ein kurzer Hinweis, wer sonst gerade an der App arbeitet, hilft.
• Es gibt keine Tests im Projekt. Dann ist der erste Test oft der aufwendigste, weil die Testumgebung erst eingerichtet werden muss. Das sollte im Umfang berücksichtigt sein.
• Niemand weiß, wie die App ausgerollt wird. Klären Sie das vorab. Ein Pull Request, den niemand ausrollen kann, nützt wenig.

Häufige Fragen

Wie gebe ich einem Entwickler Zugang, ohne die Kontrolle abzugeben?

Laden Sie ihn in das Repository bei GitHub, GitLab oder Bitbucket ein. Er arbeitet auf einem eigenen Branch, der Ihre laufende Version nicht berührt, und braucht dafür keine Zugangsdaten zum Produktivserver. Konfigurationswerte wie API-Schlüssel gehören in Umgebungsvariablen; für die Entwicklung genügen in der Regel Test-Schlüssel oder eine Staging-Umgebung.

Wann ist die neue Funktion live?

Erst wenn Sie den Pull Request übernehmen. Bis Sie auf „Merge“ klicken, ändert sich an Ihrer laufenden Anwendung nichts. Danach wird die Änderung so ausgerollt, wie Ihre Anwendung sonst auch aktualisiert wird.

Wie prüfe ich die neue Funktion vor der Übernahme?

Anhand der vorher vereinbarten Abnahmekriterien und der Prüfschritte im Pull Request, am besten in einer Vorschau-Umgebung. Viele Hoster erzeugen für jeden Pull Request automatisch eine eigene Vorschau-URL. Ist ein Kriterium nicht erfüllt, benennen Sie genau dieses Kriterium und was Sie beobachtet haben.

---

Genau diesen Ablauf nutzen wir für die Aufgabe „Neue Funktion in einer bestehenden Web-App“ aus dem Leistungskatalog: Sie legen die Funktion als Karte auf Ihrem Board an, gern mit Beispiel und Abgrenzung wie oben, und laden uns in Ihr Repository ein. Sobald wir starten, stehen die Abnahmekriterien auf der Karte; wir arbeiten auf einem eigenen Branch, schreiben Tests und liefern 48 Stunden nach Start einen Pull Request mit Prüfschritten – gezählt von Montag 8 Uhr bis Freitag 16 Uhr. Vor der Übergabe prüft ihn ein Senior-Entwickler und gibt ihn frei; über den Merge entscheiden Sie. Die erste Aufgabe erledigen wir kostenlos, eine pro Unternehmen: Erste Aufgabe anlegen. Weitere Funktionen setzen wir im Prozess-Abo in der Reihenfolge um, die Sie auf dem Board festlegen; Details zur Kategorie finden Sie unter Programmierung.