Eine Code-Review-Checkliste für .NET-Pull-Requests sollte zuerst Korrektheit, Testabdeckung und Verständlichkeit prüfen und erst danach Detailfragen zu Design und Betrieb. Für Teams mit Azure DevOps ist sie am wirksamsten, wenn sie mit Build Validation, klaren Review-Regeln und kleinen Änderungen verbunden ist.
Ein Pull Request ist der formale Änderungsvorschlag vor dem Merge. In Azure Repos lässt sich dieser Ablauf über Branch Policies stützen, etwa mit Mindestanzahl an Reviewern, Kommentarauflösung und der Pflicht zu verknüpften Work Items; laut Microsoft Learn auf den Seiten „Branch policies overview“ und „Branch policies“, gelesen am 01.11.2026, sind diese Richtlinien standardmäßig deaktiviert.
Im Alltag trägt eine Checkliste dann, wenn sie knapp bleibt und direkt am Review-Ablauf hängt:
- wenige feste Prüfpunkte,
- automatische Regeln für Wiederholbares,
- überschaubare Änderungen statt übergroßer Pull Requests.
Gerade der letzte Punkt entscheidet oft darüber, ob ein Review gründlich oder nur oberflächlich wird. Für die Teamregel hilft deshalb eine klare Grenze, wie groß ein Pull Request sein darf.
Korrektheit und Tests
Beginnen Sie mit der Kernfrage: Erfüllt der Pull Request das verknüpfte Work Item fachlich und technisch, ohne darüber hinaus unnötige Änderungen mitzunehmen? Je klarer diese Frage beantwortbar ist, desto belastbarer wird das Review.
Achten Sie darauf, ob Ziel und Umfang der Änderung im Pull Request verständlich beschrieben sind und ob der Bezug zum Work Item erkennbar bleibt. In Azure Repos kann die Policy „Check for linked work items“ diesen Zusammenhang verbindlich machen; Microsoft führt sie in „Branch policies overview“ als Branch Policy auf, gelesen am 01.11.2026. Wenn Ihr Team viele Änderungen zunächst zur Diskussion einstellt, kann auch ein Blick auf Entwürfe im Review-Ablauf hilfreich sein.
Im eigentlichen Code-Review reicht es nicht, nur den offensichtlichen Hauptpfad zu lesen. Prüfen Sie auch:
- Randfälle und leere Eingaben,
- Fehlerpfade und Ausnahmen,
- Rückgabewerte und Seiteneffekte,
- Änderungen, die mehr berühren als die Anforderung verlangt.
Bei .NET-Code sollte neue oder geänderte Logik durch passende Tests abgesichert sein. Testnamen sollten das erwartete Verhalten beschreiben, nicht nur technische Details der aktuellen Umsetzung. Schauen Sie außerdem auf die Aussagekraft der Tests: Decken sie das relevante Verhalten ab oder bestätigen sie nur die bestehende Implementierung? Bei Bugfixes ist besonders nützlich, wenn ein Test den ursprünglichen Fehler reproduziert oder das gewünschte Verhalten nun eindeutig festhält.
Prüfen Sie zuletzt, ob Build und Tests in Azure Pipelines als Build Validation im Pull Request laufen. Microsoft nennt „Build validation“ in „Branch policies overview“ als Branch Policy, die standardmäßig aus ist, gelesen am 01.11.2026. Auch die Größe zählt: Wird ein Pull Request zu groß, sinkt die Prüfbarkeit und Kommentare bleiben leichter an der Oberfläche.
Design und Benennung
Achten Sie darauf, ob die Änderung in die vorhandene Struktur passt, statt nebenbei eine neue einzuführen. Ein Pull Request wird schwerer prüfbar, wenn er fachliche Änderung, Umbau und neue technische Muster zugleich mischt.
Hilfreich ist ein kurzer Blick auf die Grenzen der Verantwortlichkeit: Eine Klasse sollte eine erkennbare Aufgabe haben. Orchestrierung, Fachregeln, Datenzugriff und Infrastrukturcode sollten nicht ohne Not in derselben Methode oder demselben Typ zusammenlaufen.
Prüfen Sie bei Refactorings besonders, ob Verhalten und Struktur getrennt bleiben. Wenn beides vermischt ist, wird unklar, worauf sich Kommentare und Freigaben eigentlich beziehen.
Für die Benennung gilt: Namen sollten Absicht tragen und zum Fachwortschatz des Systems passen. Das betrifft nicht nur öffentliche Typen und Methoden, sondern auch lokale Variablen, DTOs und Testfälle. Ein DTO ist ein einfacher Datenträger zum Austausch von Werten zwischen Teilen eines Systems.
Oft reichen dafür wenige Fragen:
- Ist der Name aus Sicht der Fachlichkeit verständlich?
- Entsteht ein neues Konzept, obwohl schon eines existiert?
- Erklärt ein Kommentar echten Kontext oder nur schlechten Code?
Wenn Sie Reviews technisch weiter in Ihren Ablauf einbinden wollen, helfen je nach Team die Ansteuerung über die REST API oder Ereignisse per Service Hooks.
Sicherheit und Secrets
Prüfen Sie zuerst, ob die Änderung neue Vertrauensgrenzen aufmacht. Das betrifft nicht nur klassische Secrets, sondern auch Stellen, an denen Daten in andere Prozesse, Dienste oder Protokolle geraten. Eine Vertrauensgrenze ist der Übergang zwischen Bereichen mit unterschiedlichem Zugriffs- oder Schutzbedarf.
Achten Sie im Pull Request besonders auf diese Punkte:
- neue Umgebungsvariablen, App Settings oder Service-Verbindungen,
- zusätzliche Rechte für Managed Identities, Service Principals oder Benutzer,
- Änderungen an Pipeline-Definitionen, Templates und Bereitstellungsschritten,
- neue Exportpfade für Logs, Events, Artefakte oder Diagnoseausgaben,
- Beispiel- und Testdaten mit Personenbezug oder echten internen Kennungen.
Hilfreich ist außerdem die Frage, ob die Änderung das Prinzip der kleinsten nötigen Rechte wahrt. Wird ein Dienstkonto breiter berechtigt, sollte im Pull Request klar sein, warum das nötig ist und wie der Zugriff begrenzt bleibt.
Für Azure Repos nennt Microsoft in „Securely use repositories and pull requests“ (gelesen am 01.11.2026) zwei sinnvolle Leitplanken für sensible Bereiche: automatisch eingeschlossene Reviewer für sensitive paths und stark eingeschränkte Rechte für „Bypass policies when completing pull requests“ sowie „Bypass policies when pushing“.
Sobald Review-Funktionen oder Agenten Code, Pull-Request-Inhalte oder Metadaten verarbeiten, gehört auch der Datenpfad in die Prüfung. Für Datenschutz, DORA, NIS2 und Mitbestimmung sollten Sie die Rechtsfrage mit Anwältin oder Anwalt beziehungsweise Datenschutzbeauftragten klären. Für den Stand geplanter Datenpfade, Identitäten und Guardrails hilft die Sicherheits- und Datenseite.
Performance und Logging
Schauen Sie im Review auf das Laufzeitprofil der Änderung, nicht nur auf korrektes Verhalten. Kritisch sind vor allem neue Schleifen über große Mengen, mehrfaches Materialisieren von Abfragen, unnötige Serialisierung und zusätzliche Netzaufrufe in ohnehin häufig genutzten Pfaden.
Bei .NET lohnt sich ein prüfender Blick auf asynchrone Stellen. Relevant ist weniger, ob überall async steht, sondern ob I/O sauber von CPU-Arbeit getrennt bleibt, Aufgaben korrekt weitergereicht werden und keine blockierenden Aufrufe in Request- oder Job-Pfaden stecken. Ein Hot Path ist ein besonders häufig ausgeführter Codepfad und daher für Last und Latenz wichtig.
Für Logging gilt: wenig, aber nützlich.
Prüfen Sie insbesondere:
- ob Logeinträge bei Fehlern den nötigen fachlichen und technischen Kontext tragen,
- ob Log-Level zum Ereignis passen,
- ob Korrelation über Request-, Job- oder Nachrichten-Grenzen erkennbar bleibt,
- ob keine personenbezogenen Daten, Secrets oder interne Kennungen unnötig mitgeschrieben werden.
Wenn sich Betriebsverhalten ändert, sollte auch sichtbar werden, woran Sie Erfolg und Probleme später erkennen. Dazu gehören etwa passende Metriken, Health Signals und klar benannte Fehlerpfade. Für ergänzende automatische Prüfungen im Pull Request bleibt dennoch die Grenze wichtig: Kontext zu Last, Diagnose und Betriebsfolgen muss das Team selbst bewerten.
Was Tools statt Menschen prüfen sollten
Automatisieren Sie nur das, was sich mit festen Regeln verlässlich bewerten lässt. Das sind im Review-Ablauf vor allem Ergebnisse mit klaren Ein- oder Ausgängen: erfolgreich oder fehlgeschlagen, vorhanden oder nicht vorhanden, erfüllt oder verletzt.
Dazu passen typischerweise:
- Kompilieren und Testlauf,
- Format- und Analyzer-Regeln,
- Pflicht zu verknüpften Work Items,
- Kommentarauflösung vor Abschluss,
- Build Validation und Status Checks.
Status Checks sind Rückmeldungen anderer Systeme direkt am Pull Request. Sie eignen sich dort, wo ein Ergebnis maschinenlesbar vorliegt, aber nicht sinnvoll als Reviewer-Stimme modelliert ist.
Bei den Review-Regeln lohnt sich der Blick auf die Feinheiten. In Azure Repos können Sie nicht nur eine Mindestzahl an Reviewern verlangen, sondern auch festlegen, ob bei neuen Pushes eine Freigabe der letzten Iteration nötig ist. Das verhindert, dass ein älteres Okay stillschweigend für späteren Code mitgezählt wird.
Für KI-gestützte Prüfungen ist die Grenze noch wichtiger. Laut Microsoft Learn auf den Seiten „Copilot code reviews“ sowie „Review pull requests“, gelesen am 01.11.2026, hinterlässt die Funktion in Azure Repos ein Comment review. Sie ersetzt damit keine erforderliche Freigabe und blockiert keinen Merge. Weil Preview-Funktionen keine SLA haben und sich ändern können, sollten Teams solche Prüfungen als Zusatzsignal behandeln, nicht als tragende Review-Regel.
Wenn Sie Ihre Grenze zwischen automatischer und manueller Review schärfen wollen, hilft eine einfache Frage: Braucht dieser Punkt Urteilsvermögen oder nur eine Regel?
Häufige Fragen, die Sie sich dabei stellen könnten
Woran erkenne ich, dass eine Checkliste im Teamalltag noch trägt?
Sie trägt, wenn sie vor dem ersten Kommentar schnell anwendbar ist und im Review nicht erklärt werden muss. Ein brauchbarer Test ist einfach: Finden zwei Reviewer bei demselben Pull Request mit der Liste ähnliche Schwerpunkte, ohne lange Auslegung?
Warnzeichen sind andere:
- Punkte werden fast nie erwähnt,
- dieselbe Frage steht doppelt in anderer Form,
- die Liste mischt Pflicht, Hinweis und Ausnahmefall.
Dann hilft meist Streichen statt Ausbauen.
Welche Azure-Repos-Regeln sind für wichtige Branches zuerst sinnvoll?
Für zentrale Branches sollten Sie zuerst die Regeln wählen, die den Ablauf klar machen. Microsoft nennt in „Securely use repositories and pull requests“, gelesen am 01.11.2026, als Sicherheitsbasis unter anderem mindestens zwei Reviewer, verknüpfte Work Items, Kommentarauflösung, Build Validation und automatisch eingeschlossene Reviewer für sensible Pfade.
Wichtig ist auch die Feineinstellung bei neuen Pushes: Eine Iteration ist eine neue Fassung des Pull Requests nach weiterem Commit. Wenn Freigaben nach einer neuen Iteration neu bewertet werden müssen, zählt altes Review nicht einfach still weiter.
Wie ordne ich KI-Review in meinen Prozess ein, ohne den Merge davon abhängig zu machen?
Behandeln Sie es als zusätzliches Signal. Für Azure Repos beschreibt Microsoft in „Review pull requests“, gelesen am 01.11.2026, ein Comment review, nicht eine Freigabe. Sinnvoll ist KI-Review daher eher für Hinweise auf Muster, auffällige Stellen und Rückfragen als für die eigentliche Verantwortungsübernahme im Review.
Ob dazu später belastbare Messwerte vorliegen, gehört auf eine Seite mit späteren Messungen, nicht in die Checkliste selbst.
Was prüfe ich vorab bei Datenpfaden und internen Zuständigkeiten?
Klären Sie vor der Einführung, welche Inhalte verarbeitet werden, wo Verarbeitung stattfinden kann und welche Rollen beteiligt sind. Bei Datenschutz, DORA, NIS2 und Mitbestimmung sollten Sie die Frage mit Anwältin oder Anwalt sowie Datenschutzbeauftragten prüfen.
Wenn Sie den Stand eines in Entwicklung befindlichen Dienstes verfolgen wollen, helfen öffentliche Änderungen. Hinweise zu geplantem Self-Service, Kontingenten im Abo und zum Stand „in Entwicklung, noch nicht erhältlich“ stehen auf der vorläufigen Übersichtsseite.
Nächster Schritt
Legen Sie die Checkliste als feste Review-Definition für Ihr Team fest: kurz, eindeutig und für jede Änderung gleich anwendbar. Entscheidend ist nicht die Länge, sondern dass vor dem Abschluss eines Pull Requests klar ist, was geprüft sein muss und was nur Hinweis bleibt.
Praktisch hilft diese Trennung:
- Pflichtpunkte für jeden Pull Request,
- optionale Hinweise je nach Risiko,
- Ausnahmen nur mit Begründung im Pull Request.
So bleibt das Review nachvollziehbar, auch wenn mehrere Personen beteiligt sind.
Wenn Sie das Thema weiter verfolgen: Polier von ballmüller solutions, Berlin, ist in Entwicklung und am 01.11.2026 noch nicht verfügbar.