Thema: code-review
-
Welche Code-Review-Kennzahlen sagen entwichene Fehler voraus, ohne manipulierbar zu sein?
Offene Frage: Durchlaufzeit der Review, Kommentardichte und Änderungsgrösse lassen sich leicht messen, aber welche davon sagen tatsächlich Fehler voraus, die erst nach dem Merge gefunden werden, und welche verlieren ihre Wirkung, sobald Teams darauf optimieren?
-
Datenschutz-Prüfliste für ein Feature
Zehn Fragen, die eine prüfende Person beantwortet, bevor ein Feature live geht: Inventar neuer personenbezogener Daten, Minimierungsentscheidungen, Aufbewahrungsjob, Zugriff und Zugriffsprotokollierung, Abdeckung von Export und Löschung, Präferenzzwecke, Drittanbieter-Abläufe, ein kurzer LINDDUN-Durchgang, Testdaten und ein festgehaltenes Ergebnis; nur technische Eigenschaften, keine rechtliche Beurteilung.
-
Automatisierte Formatierung und Linting als Team-Vereinbarung
Layout an einen Formatter und mechanische Prüfungen an einen Linter zu delegieren, nimmt Stildiskussionen aus dem Review; EditorConfig, PEP 8 und Werkzeuge wie Ruff zeigen, wie sich die Vereinbarung im Repository festhalten lässt.
-
Eine Änderung so beschreiben, dass Reviewer sie prüfen können
Eine Änderungsbeschreibung nennt das Problem, den gewählten Ansatz samt Alternativen, wie getestet wurde und worauf Reviewer achten sollten; sie verlinkt das Ticket und listet Risiken und Folgearbeiten, sodass die Prüfung mit Verständnis beginnt statt mit Archäologie.
-
Von einem KI-Agenten geschriebenen Code überprüfen
Ein vorgeschlagenes Review-Protokoll für generierte Änderungen: den Diff mit der Anfrage abgleichen, die Existenz jeder API und Abhängigkeit bestätigen, Testbehauptungen durch Ausführen und gezieltes Scheiternlassen der Tests verifizieren, Tests vor der Implementierung lesen, nach verschluckten Fehlern suchen und festhalten, was geprüft wurde.
-
Code-Review: eine Checkliste für Reviewer
Eine kompakte Prüfliste für Code-Reviews: Zweck verstehen, Design vor Stil, Korrektheit und Randfälle, Tests, Lesbarkeit; Rückmeldung innerhalb eines Arbeitstags und Freigabe, sobald die Änderung den Code insgesamt verbessert.
-
Code Smells vor dem Refactoring erkennen
Code Smells sind oberflächliche Symptome (lange Methoden, grosse Klassen, Feature Envy, Shotgun Surgery, Primitive Obsession), die auf ein tieferliegendes Designproblem hindeuten; sie zu benennen gibt der Codeüberprüfung ein Vokabular und einen Auslöser für Refactoring.
-
Kommentare schreiben, die der Code nicht sagen kann: Gründe, Randbedingungen, Fallen
Ein Kommentar lohnt sich, wenn er etwas sagt, das im Code nicht steht: den Grund für eine überraschende Entscheidung, die äussere Randbedingung, die Falle für die nächste Person. Was der Code sagt, wiederholt er nicht; PEP 8 hält fest, dass Kommentare, die dem Code widersprechen, schlimmer sind als keine. Bevor man kommentiert, prüft man, ob ein besserer Name oder ein Test den Kommentar überflüssig macht.
-
Eine Code-Review durchführen, die den Code verbessert
Ein aus Googles Engineering-Praktiken abgeleitetes Vorgehen für Reviewerinnen: beurteilen, ob die Änderung die allgemeine Codequalität verbessert, Design vor Stil prüfen und die Durchlaufzeit innerhalb eines Arbeitstags halten.
-
Ein Design-Review durchführen: Kommentarfrist, benannte Entscheidungsperson und dokumentierte Entscheidung
Ein Vorschlags-Review braucht eine begrenzte Kommentarfrist, eine benannte Person oder Gruppe, die entscheidet, eine schriftlich festgehaltene Entscheidung (annehmen, ablehnen, zurückstellen) mit Begründung sowie eine Regel für die Wiedereröffnung; der Rust-RFC-Prozess und Pythons PEP-Prozess zeigen die Form, und diese Methodik passt sie an ein einzelnes Team an.
-
Schriftlich widersprechen: die Position im besten Licht darstellen (Steelmanning), dann den zentralen Punkt widerlegen
Ein schriftlicher Widerspruch, der eine Entscheidung tatsächlich ändern kann, gibt die andere Position zunächst in ihrer stärksten Form wieder, benennt genau, was strittig ist, zitiert die fragliche Stelle, liefert abgestufte Belege und schlägt eine Alternative vor; Paul Grahams Hierarchie des Widerspruchs ordnet Erwiderungen von blosser Beschimpfung bis zur Widerlegung des zentralen Punkts.
-
Reformatierungs-Commits aus git blame heraushalten: -w und Ignore-Revs-Dateien
git blame -w ignoriert Whitespace beim Nachverfolgen von Zeilen, --ignore-rev und eine committete Datei .git-blame-ignore-revs überspringen benannte Commits wie Massen-Reformatierungen, sodass Zeilen der vorangegangenen inhaltlichen Änderung zugeschrieben werden, und -M/-C verfolgen verschobene oder kopierte Zeilen; GitHub liest dieselbe Datei automatisch.
-
Schriftlich widersprechen, ohne zu verletzen: Zitat, Kernpunkt, Alternative
Ein schriftlicher Widerspruch, der eine Entscheidung ändern kann, gibt die Gegenposition zuerst in ihrer stärksten Form wieder, zitiert die strittige Stelle, greift den Kernpunkt an statt Ton oder Person, stuft die eigene Evidenz ehrlich ein und schlägt eine Alternative vor. Paul Grahams Hierarchie des Widersprechens und Googles Leitfaden für Reviewer liefern die Massstäbe.
-
Refactoring in kleinen, geprüften Schritten
Refactoring ändert die innere Struktur, nicht das beobachtbare Verhalten. Ein benanntes Refactoring aus dem Katalog nach dem anderen, Tests nach jedem Schritt grün, bei Rot rückgängig statt vorwärts debuggen, Struktur- und Verhaltensänderungen in getrennten Commits – so bleibt die Arbeit sicher und in Minuten prüfbar.
-
Snapshot- und Golden-File-Tests, und wie man sie ehrlich hält
Ein Snapshot-Test serialisiert eine Ausgabe und vergleicht sie mit einer gespeicherten Referenz; er deckt alles ab und beschreibt nichts. Snapshots klein halten, flüchtige Felder normalisieren, Snapshot-Diffs wie Code überprüfen und sie gezielt aktualisieren – sonst verkommen sie zu abgenicktem Störgeräusch.
-
A security-focused code review checklist for changes at trust boundaries
A short list of questions a reviewer asks of any change that touches input, authentication, authorization, data access, outbound requests, files, secrets or dependencies: where does the untrusted data enter, who is allowed to do this, what does it query, where does it send or store, and what is logged. Applied to boundary-touching changes only, so that it stays short enough to be used.
-
Vier-Augen-Prinzip beim Deployment: Freigaben technisch erzwingen
Kein Stand erreicht die Produktion, ohne dass eine zweite Person ihn gesehen und freigegeben hat – und zwar so, dass das Werkzeug es erzwingt statt die Disziplin: geschützte Zweige mit Pflicht-Review, Freigabepflicht für die Produktionsumgebung, keine Umgehung für Administratoren, und ein Notweg, der protokolliert statt verboten wird.
-
Cleaning up a branch before review
Before asking for review, squash fix-up commits, split mixed ones and rewrite messages so that each commit is one reviewable change; git rebase -i and autosquash do the mechanical part.
-
Smaller change sets are reviewed faster and with fewer defects
A testable hypothesis: keeping change sets small (roughly under a few hundred changed lines) shortens review time and reduces defects that escape review, with a proposed measurement.
Maschinenlesbar: JSON