Denken über Git Diff (Die Kunst der Code-Review)

1. Konzeptüberblick und systemisches Problem

Jahrzehntelang galt die Tippschnelligkeit als Kernkompetenz von Entwicklern: Wie viele hundert Zeilen Code können Sie pro Schicht über die Tastatur eingeben?

Im Zeitalter autonomer Agenten und des Vibe Coding hat diese mechanische Fähigkeit an Wert verloren. Jedes Sprachmodell generiert 1.000 Zeilen Code in 8 Sekunden. Damit wurde das Kunststück der schnellen Diff-Analyse (Diff-First Mindset) zum zentralen Wert eines Ingenieurs.

Sie sind nicht mehr der Autor jedes einzelnen Zeichens – Sie sind Chefredakteur und Architekt. Ihre Aufgabe besteht darin, auf einen Bildschirm mit rot-grünen Änderungen zu blicken und innerhalb von 10 Sekunden eine deterministische Entscheidung zu treffen:

• „Der grüne Code ist korrekt, aber der rote hat eine kritische Session-Prüfung entfernt – abgelehnt!“
• „Die Änderungen sind sauber, die Architektur ist nicht gebrochen – wir committen!“

Das mentale Modell: So wie ein Chefredakteur einer Zeitschrift nicht alle Kolumnen selbst schreibt, sondern die Druckfahnen vor dem Druck prüft, filtert ein Senior-Ingenieur die Ausgaben der Agenten durch das Sieb des Git Diff.

┌─────────────────────────────────────────────────────────────┐
│                 АРХІТЕКТУРА ДИФ-ФІЛЬТРАЦІЇ                  │
├─────────────────────────────────────────────────────────────┤
│ 1. ПРОМПТ ДО АГЕНТА:                                        │
│    «Додай кешування сесій через Redis у модуль auth.ts»     │
├─────────────────────────────────────────────────────────────┤
│                          │                                  │
│                          ▼ Автономна генерація              │
├─────────────────────────────────────────────────────────────┤
│ 2. НЕПРЕЗЕНТАБЕЛЬНИЙ СИРИЙ ВИХІД (4 файли змінено)         │
├─────────────────────────────────────────────────────────────┤
│                          │                                  │
│                          ▼ Контрольний шлюз DIFF-REVIEW     │
├─────────────────────────────────────────────────────────────┤
│ 🛑 ТАКСОНОМІЯ ПЕРЕВІРКИ:                                    │
│    • ЧЕРВОНІ РЯДКИ (-): Чи не стерто логування та типи?    │
│    • ЗЕЛЕНІ РЯДКИ (+): Чи немає галюцинованих пакетів?     │
│    • СТАТИСТИКА: Якщо просили 5 рядків, а змінилося 120 —   │
│      НЕГАЙНИЙ REJECT!                                       │
└─────────────────────────────────────────────────────────────┘

2. Ingenieursbeispiel: Anatomie eines korrekten Diffs

diff --git a/src/services/billing.ts b/src/services/billing.ts
--- a/src/services/billing.ts
+++ b/src/services/billing.ts
@@ -42,7 +42,9 @@ export async function calculateInvoice(user: UserProfile) {
-  // Тимчасовий хак: фіксована знижка для тестів
-  return user.cartTotal * 0.95;
+  // Перевірка активної підписки перед розрахунком
+  const discountRate = await getSubscriptionDiscount(user.id);
+  return user.cartTotal * (1 - discountRate);
 }

Beim Betrachten dieses Fragments verifiziert ein erfahrener Ingenieur sofort drei Punkte:

1. Rotes Minus: Genau der technische Schuldposten (temporärer Hack) wurde entfernt, wie im Ticket gefordert.
2. Grünes Plus: Der Aufruf getSubscriptionDiscount ist asynchron und await wurde hinzugefügt.
3. Vertrag: Der Rückgabewert bleibt numerisch, es gibt keine Seiteneffekte auf benachbarte Methoden. Man kann bedenkenlos auf Accept klicken.

3. Praktische CLI-Befehle zur Diff-Inspektion im Terminal

Alle modernen IDEs (Cursor, VS Code, Windsurf) bieten grafische UIs für Diffs, doch echte Kontrolle erreicht man im Terminal durch präzise Git-Flags:

# 1. Швидка зведена статистика: скільки рядків додано/видалено у кожному файлі
git diff --stat

# 2. Перегляд змін лише для конкретного файлу без стороннього шуму
git diff src/lib/auth.ts

# 3. Перегляд змін, які вже додані до staging (перед git commit)
git diff --staged

# 4. Інтерактивний покроковий розбір (Patch Mode): дозволяє приймати або відхиляти шматки файлу (hunk) по черзі
git checkout -p

# 5. Ігнорування змін пробілів та форматування, щоб побачити чисту логіку
git diff -w --ignore-blank-lines

4. Vier goldene Regeln der Diff-Lesehygiene

1. Fokus auf Rot (Red First): Neuer Code (grün) sieht fast immer glatt aus. Die gefährlichsten Regressionen und Sicherheitslücken verstecken sich stets in den gelöschten roten Zeilen.
2. Import-Prüfung: Achten Sie auf die ersten 10 Zeilen der Datei. Hat der Agent eine externe Bibliothek (z. B. lodash oder axios) hinzugefügt, obwohl das Projekt bereits native Tools nutzt?
3. Regel des Volumenslimits (Diff Budget): Wenn Sie das Modell gebeten haben, eine Formularvalidierung zu ändern, der Diff aber +180 -95 Zeilen in 5 Dateien zeigt – versuchen Sie nicht, ihn zu lesen. Klicken Sie auf Reject und starten Sie den Prompt mit einer harten Einschränkung neu: "Ändere nur die Funktion validateForm in der Datei Form.tsx, fasse den restlichen Code nicht an".
4. Line-by-line Accept: Vermeiden Sie bei komplexen Dateien die Schaltfläche „Accept All“. Nehmen Sie Änderungen blockweise (Hunk by Hunk) an.

5. Abschließende ingenieurtechnische Schlussfolgerung

Das Diff-First Mindset ist die entscheidende Überlebensfähigkeit im Jahr 2026. Es schützt Ihre Codebasis vor schrittweiser Degradation und synthetischem Müll und verwandelt die rasende Geschwindigkeit neuronaler Netze in stabile und zuverlässige Geschäftsergebnisse.