So beschleunigen Sie den Codeüberprüfungsprozess und verhindern, dass sich Pull-Anforderungen häufen

Diese Woche adressierte MPJ eine Frage von einem seiner Gönner:

Wie verwalte ich Pull-Anfragen in einem Team?
Wie kann man den Stapel der Pull-Requests so niedrig wie möglich halten und gleichzeitig den Fokus des Teams hoch halten?
Auf der einen Seite möchten Sie, dass es so schnell wie möglich überprüft wird, auf der anderen Seite möchten Sie nicht zu viele Kontextwechsel für Ihre Teammitglieder erstellen.

Codeüberprüfungen sind eine wichtige Praxis, die zur Verbesserung der Codequalität, zur Verhinderung von Fehlern und zum Teilen von Wissen beiträgt. Sie können jedoch auch einen nervigen Engpass darstellen. In diesem Beitrag teile ich meine Erfahrungen mit diesem Problem.

Ist es das wert?

In einer Retrospektive äußerte ein Mitglied des Teams, in dem ich als Teamleiter tätig war, die Besorgnis: „Überprüfungen von Pull-Requests nehmen Zeit in Anspruch und verlangsamen den Prozess.

Wahrscheinlich hatten Sie auch dieses Problem: Sobald ein Ticket "erledigt" ist, sendet ein Ingenieur eine Pull-Anfrage zur Überprüfung und wechselt sofort zu einem anderen Ticket im Backlog. Andere Teammitglieder sind ebenfalls beschäftigt: Sie arbeiten an ihren eigenen Problemen, sodass die Überprüfung nicht sofort erfolgt. Wenn jemand schließlich eine Überprüfung einreicht, ist der Autor der Pull-Anforderung bereits mit der neuen Aufgabe beschäftigt, sodass er die Adressierung der Überprüfung aufschiebt. Im schlimmsten Fall hat der Autor eine Frage an den Rezensenten. Der Prüfer ist ebenfalls beschäftigt oder hat seinen Arbeitsplatz bereits verlassen. Die Konversation dauert Tage, Pull-Requests häufen sich, Ingenieure müssen Kontexte hin und her wechseln, was den Fluss unterbricht. Es gilt also zu fragen: Lohnt es sich wirklich?

Beschränken Sie die laufende Arbeit

Anstatt mich auf die naheliegendste Lösung zu einigen, habe ich vorgeschlagen, das Work in Progress-Limit einzuführen. Dies ist eine Technik, die die Anzahl der Probleme begrenzt, mit denen das Team gleichzeitig arbeiten kann. Um die Zusammenarbeit und die Paarprogrammierung zu fördern, liegt das Limit normalerweise unter der Anzahl der Teammitglieder. Sobald ein Ingenieur einen PR gesendet hat, muss er offene Pull-Requests überprüfen, jemandem helfen, seine Arbeit zu beenden, oder ihn bitten, die Pull-Requests zu überprüfen, anstatt zu einer anderen Aufgabe zu wechseln.

Trotz der Zweifel hat es geholfen, nicht nur die Gewohnheit zu machen, Pull-Requests zu überprüfen, sondern auch Pair-Programming in unser tägliches Leben zu bringen. Mein Team war auf eine Vielzahl von Zeitzonen verteilt, von Brasilien bis Indonesien. Wenn jemand am Abend eine Pull-Anfrage einreicht, besteht eine große Chance, dass diese beim Aufwachen überprüft wird. Ein weiterer Nebeneffekt des laufenden Limits war das gemeinsame Eigentum. Es war gängige Praxis, Überprüfungskommentare an die Pull-Anfrage eines anderen Teammitglieds zu richten, wenn diese abwesend oder beschäftigt waren.

Nachdem das Pairing für uns zur Standardpraxis geworden war, haben wir auch das Pairing-Überprüfungsverfahren übernommen: Der Autor der Pull-Anfrage erstellt einen Ad-hoc-Anruf und lädt andere Teammitglieder dazu ein. Eines der Teammitglieder teilt den Bildschirm, und sie lesen alle zusammen das Differential, stellen Fragen und äußern Bedenken gegenüber dem Autor. Es verbesserte die Qualität und beschleunigte den Prozess dramatisch.

Das eigentliche Problem

Aus diesem Grund haben langsame Codeüberprüfungen ein größeres Problem aufgezeigt: Wir haben nicht zusammengearbeitet und uns auf unsere eigene Arbeit konzentriert, nicht auf das gesamte Projekt. Sobald wir die Denkweise geändert hatten, verschwand das Problem und wir sind als Team besser geworden.

Wenn Sie mehr davon sehen möchten, folgen Sie mir auf Twitter!