P4 Code Review ist ein webbasiertes Review-Werkzeug für Teams, die ihre Projekte mit Perforce P4 verwalten. Änderungen lassen sich gemeinsam betrachten, kommentieren und bewerten. Das Werkzeug verbindet damit die Versionsverwaltung mit einem strukturierten Review-Prozess.
Was ist P4 Code Review?
P4 Code Review gehört zum Werkzeugangebot von Perforce und ist direkt auf die Zusammenarbeit mit Perforce P4 ausgerichtet. Das Programm war früher unter dem Namen Helix Swarm bekannt.
Über die webbasierte Oberfläche können Teammitglieder Änderungen an einem Projekt untersuchen. Dateien und einzelne Änderungen bleiben dabei mit den Informationen aus der Versionsverwaltung verbunden. Statt Quellcode außerhalb des eigentlichen Entwicklungsprozesses auszutauschen, findet die gemeinsame Prüfung direkt im Umfeld der zugehörigen Änderungen statt.
Von der Changelist zum Review
In P4 werden zusammengehörende Änderungen in Changelists organisiert. Änderst du beispielsweise die Türlogik, die Inventarabfrage und eine dazugehörige Konfiguration, können diese Dateien gemeinsam zu einer Aufgabe gehören.
Eine solche Änderung kann anschließend zur Überprüfung bereitgestellt werden. P4 Code Review zeigt den Reviewern, welche Dateien und Codebereiche verändert wurden. Dadurch müssen sie nicht das gesamte Projekt durchsuchen, sondern können sich auf die relevanten Unterschiede konzentrieren.
Was sehen die Reviewer?
Im Review lassen sich die zugehörigen Dateien und ihre Änderungen betrachten. Gerade bei Programmcode ist der Vergleich zwischen vorherigem und verändertem Stand wichtig: Hinzugefügte, entfernte oder angepasste Bereiche werden sichtbar.
Damit erhält ein Reviewer den notwendigen Kontext für Fragen wie: Warum wurde diese Bedingung verändert? Was geschieht in einem Sonderfall? Passt die neue Funktion zum restlichen System? Könnte eine Änderung unbeabsichtigte Auswirkungen auf andere Bereiche besitzen?
Kommentare direkt an Änderungen
Kommentare bilden einen zentralen Bestandteil von P4 Code Review. Rückmeldungen können sich auf einen Review, eine Datei oder konkrete Zeilen innerhalb einer Änderung beziehen.
Das erleichtert technische Diskussionen. Statt beispielsweise nur zu schreiben „Die Türfunktion muss noch einmal geprüft werden“, kann ein Reviewer seinen Hinweis unmittelbar an dem veränderten Code hinterlassen.
Andere Beteiligte können darauf antworten. So bleibt die Diskussion zusammen mit ihrem technischen Kontext erhalten.
Kommentare können zu Aufgaben werden
Ein Hinweis muss nicht lediglich ein Kommentar bleiben. Review-Kommentare können in P4 Code Review als Task, also als Aufgabe, markiert werden.
Ein Reviewer entdeckt beispielsweise, dass die neue Türfunktion keinen Fall für einen ungültigen Schlüssel berücksichtigt. Aus dem entsprechenden Kommentar entsteht eine offene Aufgabe. Der Entwickler kann die Änderung anschließend bearbeiten und die Aufgabe als erledigt kennzeichnen.
Damit lassen sich Punkte unterscheiden, die lediglich diskutiert werden, und solche, die vor Abschluss des Reviews noch bearbeitet werden sollen.
Bewertung und Freigabe
Reviewer können Änderungen bewerten und der Review besitzt einen nachvollziehbaren Status. Dadurch bleibt sichtbar, ob die Prüfung noch läuft, eine Änderung akzeptiert wurde oder weitere Arbeit erforderlich ist.
Je nach Konfiguration des Projekts können offene Aufgaben Einfluss darauf nehmen, ob ein Review freigegeben werden soll. Solche Regeln helfen Teams dabei, ihren eigenen Prüfprozess abzubilden.
Review vor oder nach dem Einreichen
P4 Code Review unterstützt unterschiedliche Arbeitsabläufe. Ein Review kann stattfinden, bevor eine Änderung endgültig eingereicht wird. Dieser Ansatz wird als Pre-Commit Review bezeichnet.
Daneben sind Reviews bereits eingereichter Änderungen möglich. Dann handelt es sich um einen Post-Commit Review. Teams können ihren Ablauf damit an die Anforderungen des jeweiligen Projekts anpassen.
Warum reicht die Versionsverwaltung allein nicht?
Die Versionsverwaltung beantwortet vor allem Fragen zur Änderungsgeschichte: Welche Datei wurde verändert? Wann geschah das? Welche Änderungen gehören zusammen?
Ein Review ergänzt diese Informationen um die gemeinsame Prüfung. Teammitglieder können diskutieren, ob eine Lösung sinnvoll ist, auf mögliche Probleme hinweisen und notwendige Überarbeitungen festhalten.
P4 und P4 Code Review übernehmen damit unterschiedliche Aufgaben, greifen im Entwicklungsprozess aber ineinander.
Vom Crash zum P4 Code Review
Auch beim Debugging kann ein Review erneut relevant werden. Angenommen, Build 120 funktioniert, während Build 121 beim Öffnen einer Tür abstürzt.
Ein Stack Trace führt die Untersuchung zur Türlogik. Über die Versionsgeschichte stellst du fest, dass dieser Code zwischen beiden Builds verändert wurde. Die betreffende Changelist wird damit zu einem möglichen Ausgangspunkt für die weitere Untersuchung.
In P4 Code Review lässt sich die Änderung gemeinsam betrachten. Kommentare aus einem früheren Review können zusätzlichen Kontext liefern. Ebenso kann das Team den Code mit dem Wissen über den inzwischen aufgetretenen Fehler erneut überprüfen.
Ein Review beweist die Fehlerursache nicht
Dass eine kürzlich überprüfte Änderung mit einem Crash zusammenhängt, macht sie noch nicht automatisch zur Ursache. Vielleicht hat die neue Türlogik lediglich einen bereits vorhandenen Fehler im Inventarsystem sichtbar gemacht.
P4 Code Review unterstützt die Untersuchung der Änderung. Die eigentliche Ursache musst du weiterhin durch Debugging, Tests und weitere technische Informationen bestätigen.
Automatisierte Tests im Review-Prozess
Review-Prozesse können außerdem mit automatisierten Tests verbunden werden. Dadurch erhält das Team Rückmeldung darüber, ob eine Änderung festgelegte Prüfungen besteht.
Ein bestandener automatisierter Test bedeutet allerdings nicht, dass der Code garantiert fehlerfrei ist. Automatische Prüfungen können nur die Situationen untersuchen, für die entsprechende Tests existieren. Manuelle Reviews und weitere Tests bleiben deshalb wichtige Bestandteile des Entwicklungsprozesses.
Verbindungen zu weiteren Entwicklungswerkzeugen
P4 Code Review lässt sich in weitere Arbeitsabläufe integrieren. Perforce nennt unter anderem Verbindungen zu Jira, Slack und TeamCity. Außerdem stehen Schnittstellen zur Automatisierung eigener Abläufe zur Verfügung.
Solche Integrationen sind vor allem für Teams interessant, deren Entwicklungsprozess nicht ausschließlich aus Versionsverwaltung und Code Review besteht. Aufgabenverwaltung, Kommunikation und automatisierte Tests können so mit dem Review-Prozess verbunden werden.
P4 Code Review als Teil des Entwicklungsablaufs
Das Werkzeug übernimmt damit nicht die Aufgabe eines Debuggers oder einer Testumgebung. Sein Schwerpunkt liegt auf der gemeinsamen Überprüfung und Diskussion von Änderungen.
Ein möglicher Ablauf beginnt mit einer Änderung in P4. Daraus entsteht ein Review, andere Teammitglieder prüfen die betroffenen Dateien und hinterlassen Kommentare oder Aufgaben. Nach notwendigen Überarbeitungen kann die Änderung freigegeben und der Entwicklungsprozess fortgesetzt werden.
Tritt später trotzdem ein Fehler auf, bleibt die Verbindung zur Versionsgeschichte erhalten. Dadurch lässt sich nachvollziehen, welche Änderung vorgenommen wurde und welcher Review dazugehörte. P4 Code Review ergänzt P4 damit um die menschliche Prüfung hinter den gespeicherten Änderungen.
Weitere Artikel auf Games und Lyrik
Wenn du dich neben der technischen Spieleentwicklung auch für klassische Adventures interessierst, findest du auf Games und Lyrik weitere Beiträge. In Runaway 3: A Twist of Fate begleitest du Brian und Gina durch ein Point-and-Click-Adventure mit Rätseln, ungewöhnlichen Situationen und einer Geschichte voller Wendungen.
Weitere Informationen zu Funktionen und Arbeitsabläufen findest du in der offiziellen Dokumentation zu P4 Code Review.
