Code Reviews in einem externen Entwicklungsteam benötigen einen gemeinsamen Maßstab. Ein deutsches Produktunternehmen kann festlegen, welche Änderungen geprüft werden und welche Nachweise dazu gehören. Die Regeln sollen Fehler früh erkennen und Entscheidungen erklären, ohne jede Stilfrage zu einem langen Abstimmungsprozess zu machen.
Den Zweck der Änderung erklären
Ein Änderungsvorschlag verweist auf die betreffende Aufgabe und beschreibt das erwartete Verhalten. Ergänzen Sie das Ergebnis der Tests und bekannte Grenzen. Der Prüfer sollte verstehen, warum der Code verändert wurde, bevor er einzelne Zeilen bewertet.
Große Änderungsvorschläge lassen sich schwerer überprüfen. Besprechen Sie mit dem Partner, wie zusammenhängende Arbeit in nachvollziehbare Schritte aufgeteilt werden kann, ohne einen unbrauchbaren Zwischenstand auszuliefern.
Einen passenden Prüfrahmen festlegen
| Frage | Gegenstand des Reviews |
|---|---|
| Entspricht die Änderung der Regel? | Verhalten und Ausnahmefälle |
| Werden Rechte geprüft? | Serverzugriff und Rollen |
| Sind Fehler verständlich behandelt? | Ausfälle und erneute Versuche |
| Wird die Änderung nachweisbar getestet? | Relevante Prüfungen |
| Ändert sich der Betrieb? | Konfiguration und Dokumentation |
Automatisieren Sie rein formale Prüfungen, wo Ihre Werkzeuge dies sinnvoll unterstützen. Halten Sie die vereinbarten Regeln im Projekt fest.
Zuständigkeit und Antwortzeit vereinbaren
Benennen Sie die prüfenden Personen und einen Weg bei Abwesenheit. Wenn jeder Vorschlag auf eine einzige ausgelastete Person wartet, steigt die Lieferzeit. Diese interne Kapazität gehört in die Planung.
Ein Review kann zu einer Korrektur, einer Frage oder einer späteren Verbesserung führen. Trennen Sie diese Ergebnisse. Nicht jede Beobachtung muss denselben Änderungsauftrag blockieren.
Entscheidungen erhalten
Wenn eine Lösung bewusst gewählt wird, dokumentieren Sie ihre Konsequenzen. Spätere Mitglieder können dann erkennen, ob ein Verhalten unbeabsichtigt oder eine vereinbarte Einschränkung ist.
Prüfen Sie nach mehreren Lieferungen, welche Fehler trotz Review auftreten. Passen Sie Tests oder Regeln an die Ursachen an. Die Anzahl der Kommentare ist kein brauchbarer Qualitätsnachweis, wenn ihre Wirkung auf den Produktstand unklar bleibt.
Das Vorhaben vorbereiten
Weiterlesen: Testdaten für Entwicklung außerhalb des EWR: Zugriffe vorbereiten. Für eine Projektanfrage nutzen Sie den Kontakt zu Sky Vaults auf Englisch.