Ich bin ein führender Java-Entwickler bei Yandex.Money.

An jedem Arbeitsmorgen im Jahr 2018 warteten ungefähr 30 Pull-Anfragen auf eine Überprüfung, und ich hatte nicht genug Zeit, um sie alle an einem Tag zu sortieren. Am Ende des Sommers machte ich Urlaub und als ich zurückkam, fand ich eine Warteschlange von 50 PR, die mir zugewiesen war. Es gab keine Lust, sie zu harken, aber tatsächlich war es nur die Spitze des Eisbergs, die ich mit meinen eigenen Augen sah. An diesem Tag entschied ich, dass es Zeit war, etwas zu ändern.

Dies ist eine Geschichte darüber, wie wir die Codeüberprüfung beschleunigt, die führenden Entwickler entladen und die Tools verbessert haben, die wir jeden Tag verwenden.

Code Review 1.0. Wie war es vorher?

In Yandex.Money war eine Codeüberprüfung lange Zeit eine obligatorische Entwicklungsphase, und jeder war lange daran gewöhnt. Einige erkannten, dass dies genauso eine Sache war wie das Testen; andere betrachteten dies als notwendiges Übel, und jemand stieß nur als Autor von Pull-Anfragen auf eine Codeüberprüfung, verzichtete jedoch auf die Codeüberprüfung eines anderen. Ich denke, dass viele nacheinander vom letzten zum ersten gereist sind, und das ist normal.

Für die Codeüberprüfung haben wir von Anfang an Bitbucket verwendet. Für jedes Komponenten-Repository wurde eine Liste mit 3-4 Standardprüfern hinzugefügt, die allen PRs hinzugefügt wurden. Normalerweise wurde diese Liste vom Abteilungsleiter zusammengestellt und bearbeitet, und manchmal wurden dort Freiwillige hinzugefügt, die selbst eine bestimmte Komponente überprüfen wollten. Die Bibliotheks-Repositorys waren etwas einfacher - die Liste der Prüfer war für alle Bibliotheken gleich, und leitende Entwickler wurden dort aufgenommen.

Infolgedessen fiel fast die gesamte Belastung auf die Prüfer unter den leitenden Entwicklern, die nach und nach nicht mehr ausreichten. Dies berücksichtigte das Wachstum der Abteilung auf 60 Mitarbeiter, die Zunahme der Anzahl der Repositories (über 60 Komponenten, über 100 Bibliotheken) und die Beschleunigung unserer CI / CD.

Neben der hohen Arbeitsbelastung und dem Mangel an Ressourcen für Prüfer gab es weitere Probleme:

• in einigen Komponenten könnte man eine Reaktion der Rezensenten für mehr als einen Tag erwarten,
• hohe Arbeitsbelastung der als Gutachter ernannten Personen in mehreren Komponenten,
• Es ist schwierig, neue Rezensenten zu gewinnen, auch aufgrund des vorherigen Absatzes.
• Wenn der Hauptprüfer krank wurde oder im Urlaub war, nahm die Überprüfung des Zeitcodes der Komponenten merklich zu.
• Die benannten Prüfer verfügten nicht immer über echte Fachkenntnisse in der Komponente, da die Qualität der Codeüberprüfung darunter litt.

Bevor Sie diese Probleme lösen, müssen Sie entscheiden, was wir im Allgemeinen von einer Codeüberprüfung erwarten.

Die richtige Codeüberprüfung ist wie?

Wir haben vier Punkte identifiziert, die in der aktualisierten Codeüberprüfung enthalten sein sollten:

1. Überprüfen Sie die Lösungsarchitektur . Ziemlich offensichtliche Sache. Wir erwarten dies von erfahrenen Entwicklern mit Fachkenntnissen in dieser Komponente.
2. Überprüfung der technischen Umsetzung , die wir auch von hochrangigen und mittleren Spezialisten mit Fachkenntnissen in dieser Komponente erwarten.
3. Der Wissenstransfer , der in der Untersuchung der Geschäftslogik und der Codebasis durch Anfänger und Juni durch Codeüberprüfungen besteht.
4. Fähigkeit, die harten Fähigkeiten von Entwicklern zu bewerten . Ich möchte, dass jedem Entwickler ein Mentor zugewiesen wird, der das Wachstum bewertet, den Entwicklungsvektor bestimmt, einige Mängel feststellt, Kommentare abgibt und so weiter. Daher sollte der Mentor auch den Code seiner Schutzzauber sehen.

Vielleicht sieht jemand andere Ziele oder ist mit unseren nicht einverstanden - teilen Sie in den Kommentaren. In der Zwischenzeit werde ich von der Formulierung von Zielen zur Suche nach Mitteln zur Erreichung dieser Ziele übergehen - wir haben beschlossen, dass wir alle und (fast) sofort erreichen wollen.

Code Review 2.0. Wie ist es

Was haben wir uns ausgedacht? Wir begannen Schritt für Schritt zu argumentieren.

In Yandex.Money arbeiten Entwickler in Teams in Geschäftsbereichen, normalerweise 2-4 Backend-Entwickler in einem Team.

Angenommen, ich werde eine Pull-Anfrage öffnen, dh ich bin der Autor . Ich habe mein Team , dessen Entwickler sich der Geschäftslogik meiner Arbeit bewusst sind, weil wir alle an gemeinsamen Projekten teilnehmen, oft synchronisieren und im Allgemeinen aktiv interagieren. Daher möchte ich sie zunächst zu meinen Pull-Anfragen hinzufügen, damit sie zumindest auf dem neuesten Stand sind, was ich tue.

Jede Komponente in Yandex.Money verfügt über ein Team, das für die Produktion verantwortlich ist und diese begleitet.

Wenn ich eine Komponente ändere, für die ein anderes Team verantwortlich ist, erscheint es logisch, Entwickler aus diesem Team zu den Überprüfern hinzuzufügen. Sie sind für diese Komponente verantwortlich und müssen die Qualität ihres Codes überwachen. Um die Rezensenten nicht zu überlasten, nehmen wir nur eine zufällige Person aus diesem Team - wir glauben, dass dies ausreicht.

Es kann vorkommen, dass das für die Komponente verantwortliche Team nicht über ausreichende Fachkenntnisse verfügt. Dies geschieht, wenn Neulinge im Team erscheinen oder ihnen erst kürzlich diese Komponente anvertraut wurde. Ich weiß jedoch, dass wir in diesem Unternehmen echte Experten für dieses Repository haben, und es wäre großartig, wenn einer von ihnen meinen Code betrachten würde! Natürlich ist mein Wissen schwer zu formalisieren, aber Sie können den Verlauf des Repositorys verwenden und die Codeüberprüfung basierend auf der Anzahl der PRs und Statistiken berechnen, die viel an diesem Code gearbeitet und / oder viel überprüft haben. Wir berechnen die Expertise-Metrik im Repository, wählen die Top-Entwickler für diese Metrik aus, nennen sie Experten und fügen den Reviewern einen zufälligen Experten hinzu.

Im Jahr 2018 haben wir das Mentoring-Institut im Unternehmen eingeführt. Jetzt beobachtet ein Mentor unter den leitenden Entwicklern jedes Team. Außerdem hat jeder Neuling im Unternehmen zunächst einen persönlichen Mentor.

Lassen Sie meinen Mentor meinen Code beobachten! Er kann bei Problemen bei der Codeüberprüfung helfen und hat auch eine Vorstellung von meinen Stärken und Schwächen bei den technischen Fähigkeiten.

Insgesamt können fünf bis sechs Personen zu den Überprüfern jeder Pull-Anfrage hinzugefügt werden. Tatsächlich sind sie jedoch normalerweise etwas kleiner, da verschiedene Rollen in einer Person kombiniert werden können. Mein Mentor kann gleichzeitig ein Experte sein, und mein Team kann für die Komponente verantwortlich sein. Subjektiv wären 3-4 Prüfer für Pull-Anfragen optimal.

Code Review 2.0. Was ist unter der Haube?

Der Punkt ist klein: alles zum Laufen bringen. Es hat hier geholfen, dass alle unsere Aufstellungen bereits in einem separaten System eingerichtet wurden, das die REST-API für den Empfang bereitstellt. Daher wurde nach ein paar Wochen gemächlicher Entwicklung in meiner Freizeit die erste Version des Plug-Ins für Bitbucket geboren, die im Herbst schrittweise weiterentwickelt und mit allen erforderlichen Funktionen ausgestattet wurde.

Wie das Plugin funktioniert

Normalerweise füllt Bitbucket beim Erstellen einer PR die Viewer vor, die in den Projekt- oder Repository-Einstellungen angegeben sind. Aus Sicht des Benutzers hat sich hier nichts geändert - alle Prüfer werden auch beim Öffnen dieser Seite vorab ausgefüllt, außer dass ein Feld mit einer Beschreibung hinzugefügt wurde, welcher Prüfer in welcher Rolle hinzugefügt wurde. Und die Rollen der Rezensenten sind wie folgt erschienen:

• Teamkollege ist ein Mitglied des Teams des PR-Autors. Dank der REST-API mit Team-Kompositionen kann es problemlos hinzugefügt werden
• Repository-Eigentümer - ein zufälliges Mitglied des Teams, das für die Komponente verantwortlich ist; In den Repository-Einstellungen musste die Möglichkeit gegeben werden, das verantwortliche Team auszuwählen.
• Repository-Experte - zufälliger Repository-Experte; Ich werde Ihnen später mehr darüber erzählen
• Mentor - Ein Mentor für ein Team oder einen Anfänger, ist auch über die REST-API bei einem Dienst mit Teamzusammensetzungen erhältlich.

Repository-Experten

Ich werde Ihnen etwas mehr darüber erzählen, wie wir Experten betrachten. Jeden Tag durchläuft das Plugin alle Repositorys, überprüft alle Pull-Anforderungen des letzten Jahres und berücksichtigt zwei einfache Metriken:

• die Anzahl der vom Entwickler erstellten Pull-Anforderungen,
• Die Anzahl der PRs, die er überprüft und genehmigt hat, muss bearbeitet oder abgelehnt werden.

Wir fügen diesen Metriken Gewichte hinzu, basierend auf der Tatsache, dass aus Sicht des Fachwissens im Code die Verfeinerung dieses Codes wichtiger ist als die Überprüfung. Zuerst haben wir die Anzahl der Pull-Anfragen geschätzt, die eineinhalb Mal wichtiger sind als eine Überprüfung, und später haben wir das Verhältnis auf drei zu eins erhöht. Wir fassen die Metriken multipliziert mit ihren Gewichten zusammen und erhalten die Entwicklerbewertung.

Als nächstes sortieren wir alle diese Entwickler nach Bewertungen, wählen die Top 5 auf dem Weg aus und schneiden diejenigen ab, deren Bewertung unter dem Schwellenwert liegt, um gelegentliche Passanten auszuschließen. Normalerweise erhalten wir drei bis fünf Experten für jedes Repository.

Oben habe ich Ihnen den Ansatz für die Auswahl der Prüfer beschrieben, den wir ausgewählt und implementiert haben. Dabei haben wir jedoch mehrere kleine Verbesserungen gleichzeitig implementiert, wodurch der Codeüberprüfungsprozess noch schneller, bequemer und angenehmer wurde.

Verbinden Sie die Pull-Anforderung, bis die Aufgabe in Jira eingecheckt wurde

Solch eine offensichtliche und notwendige Sache, die leider nicht sofort einsatzbereit ist. Wir erhalten nur stabilen Code in dev, der nicht nur statische Prüfungen und Entwicklertests, sondern auch Integrationstests zusammen mit anderen Diensten bestanden hat. Der Status solcher Tests spiegelt sich nur in der Jira-Aufgabe wider. Daher mussten Entwickler zuvor manuell prüfen, ob die Aufgabe überprüft wurde, um die Pull-Anforderung zu verlangsamen.

Automatische Merge-Pull-Anforderung

Pull-Request kann einen beträchtlichen Teil seines Lebens in einem Zustand verbringen, in dem ihn nichts daran hindert, sich Zeit zu nehmen, aber eine Person vergisst dies oder nicht sofort. Ein bemerkenswertes Beispiel ist die Erwartung, eine Aufgabe zu testen, ohne die wir sie nicht in dev behalten. Hier bietet sich eine automatische Zusammenführung an, die nach einem einfachen Prinzip funktioniert: Wenn PR eingefroren werden kann, tun wir dies.

Alle notwendigen Bedingungen für die Zusammenführung werden durch Schecks abgedeckt. Wir überprüfen den Erfolg der Assembly, den Grad der Testabdeckung, das Fehlen von Snapshot-Abhängigkeiten der Bibliotheken, den Status der Aufgabe in Jira und das Vorhandensein aller erforderlichen Aktualisierungen. Das heißt, wir haben alles, um diese Funktionalität zu nutzen und PR zu vergessen, sobald wir die Codeüberprüfung bestanden und die Aufgabe getestet haben (es sei denn, die Qualitätssicherung findet natürlich Probleme darin).

Und wir haben dies auf eine recht bequeme Weise implementiert: Wir haben einen speziellen AutoMergeBot-Bot eingeführt, den wir nur den Überprüfern hinzufügen müssen, damit er diese Pull-Anforderung überwachen und zu gegebener Zeit einfrieren kann.

Berücksichtigung der Abwesenheit von Gutachtern

Befindet sich der Eigentümer oder Experte der Komponente im Urlaub oder im Krankheitsurlaub, wird er vom Prüfer nicht hinzugefügt, und sein Platz wird von demjenigen eingenommen, der am Arbeitsplatz ist. Als Bonus fällt ein Berg von Pull-Anfragen anderer Leute beim Verlassen des Urlaubs nicht auf diesen Rezensenten. Dies zu realisieren war nicht schwierig, da der gesamte Mangel an Mitarbeitern bei uns mit Anträgen in Jira eingereicht wurde.

Bilanzierung der Beschäftigung von Gutachtern

Jemand überprüft zehn PRs pro Tag und fünf. Jemand hat bereits 20 nicht angezeigte PRs gesammelt, während jemand fast keine hat. All dies berücksichtigen wir, um die Belastung der Prüfer gleichmäßiger zu verteilen. Je mehr Last, desto weniger wird es neuen PRs hinzugefügt - alles ist einfach.

PR-Größen beim Erstellen markieren

Auf der Seite zum Erstellen von Pull-Anforderungen kann der Autor die ungefähre Größe auswählen: S, M oder L. Dies hilft den Überprüfern, die ungefähre Zeit zu schätzen, die sie für die Codeüberprüfung aufwenden werden. Zum Beispiel habe ich 5 Minuten Zeit und ich verstehe, dass ich es schaffen kann, die Größenanforderung Pull-Anfrage S zu sehen. Es ist nicht sinnvoll, M oder L zu öffnen, da ich keine Zeit habe, sie anzusehen und das nächste Mal von vorne anfangen muss.

In Zukunft wollen wir diese Attribute bei der Berechnung der PR-Statistik berücksichtigen.

Kennzeichnung dringender PR

Außerdem kann der Autor beim Erstellen einer PR angeben, dass die Aufgabe sehr dringend ist, indem er dem Namen PR ein solches Symbol hinzufügt. Es wird sofort von den Rezensenten gesehen und versucht, es zuerst zu sehen. Es scheint eine Kleinigkeit zu sein, aber sehr nützlich und bequem.

Verfolgung der Überprüfung des Start- und Endcodes

Wenn es während der Verbesserung des Prozesses unmöglich ist zu verstehen, um wie viel er sich verbessert hat, macht es keinen Sinn, damit zu beginnen.

So ist es auch mit der Codeüberprüfung - wir können versuchen, sie so weit zu verbessern, wie wir möchten, aber wie können wir uns einer positiven Dynamik ohne Metriken und Statistiken sicher sein? In unserem Fall ist dies nicht die einfachste Aufgabe - Bitbucket und Jira gaben sofort nicht die Möglichkeit, die Codeüberprüfungszeit zu verfolgen. Wir waren nur mit der PR-Lebensdauermetrik ausgestattet, was nicht ganz zu uns passte, da wir erst nach dem Ende der Testaufgabe eine Pull-Anfrage stellten. Daher wurden in dieser Metrik Fremdindikatoren gemischt.

Jira speichert und ermöglicht das Hochladen aller Kontrollpunkte des Task-Lebenszyklus. Daher hielten wir es für richtig, diese Daten mit zwei zusätzlichen Beschriftungen anzureichern: der Start- und Endzeit der Codeüberprüfung. Es war nur notwendig, das Plugin für Bitbucket zu lehren, um diese Tags in Jira zu pushen. Somit war und ist Jira ein einziger Wahrheitspunkt für die Aufgabe, und anhand dieses Datensatzes können wir den Zeitpunkt der Codeüberprüfung vom Zeitpunkt des Testens der Aufgabe trennen.

Der dünnste Punkt hier ist, wie man bestimmt, wann eine Codeüberprüfung beendet werden soll. Vielleicht ist dies die Zeit, um die erste App zu bekommen, vielleicht die letzte, oder vielleicht ist dies die Zeit für die letzten Änderungen, die der Autor von PR vorgenommen hat? Ich habe keine Antwort auf diese Frage, hier muss ich mich nur einigen und eine Sache auswählen oder alle drei Ereignisse mit Metriken abdecken und den Abweichungen folgen.

Verfolgung von Downloads von Rezensenten

Eine weitere nützliche Metrik ist die Arbeitsbelastung der Prüfer. Wie ich oben geschrieben habe, berücksichtigen wir dies bei der Zuweisung von Gutachtern zu neuen PRs, veröffentlichen diese Informationen jedoch auch, um die Dynamik von Teams, Abteilungen oder Unternehmen zu überwachen. Manchmal hilft dies dabei, Anomalien und potenzielle Probleme zu erkennen: Wenn klar ist, dass eine oder mehrere Personen in einem Team täglich 10 oder mehr nicht angezeigte PRs hängen, gibt es einen Grund, herauszufinden, ob alles in Ordnung ist.

Anzeigen von Metriken in Grafana

Das Erstellen von Berichten zu Daten von Jira ist nützlich, aber nicht sehr praktisch. Daher haben wir auch das Senden von Metriken für die Hauptereignisse in StatsD hinzugefügt, um Diagramme zu Betriebsdaten in Grafana zu erstellen. Wir überwachen die durchschnittliche Zeit bis zum ersten Test, die durchschnittliche Lebensdauer der PR, und untersuchen auch die anomalen Werte für diese Metriken, um Probleme schnell zu finden und zu lösen.

Zum Zeitpunkt des Schreibens sieht unser Dashboard folgendermaßen aus:

Was hast du am Ende bekommen?

Leider sind wir alle im Nachhinein stark, so dass wir die oben genannten Metriken für die Codeüberprüfung nicht eingeführt haben, bevor sich der Prozess selbst zu ändern begann (September bis Oktober 2018), sondern bereits auf dem Weg dorthin, sodass wir Verbesserungen oder Verschlechterungen erst ab Anfang Dezember 2018 zuverlässig verfolgen können Was haben wir bemerkt?

Das erste, was auffällt, ist die Verringerung der Belastung für leitende Gutachter, und ich habe dies anhand meines eigenen Beispiels gespürt. Wie ich bereits erwähnte, war es für mich normal, morgens ungefähr 30 PRs in der Schlange zu sehen, aber jetzt schwankt diese Zahl zwischen 10 und 15. Statistiken der Abteilung bestätigen dies: Seit Dezember 2018 wurde die maximale Anzahl von PRs, die auf eine Überprüfung warten, von niemandem erhöht über 15. Im Durchschnitt beobachten wir ein Bild, das darauf hindeutet, dass jeder Entwickler im Durchschnitt 4-5 nicht angezeigte PRs am Morgen erwartet, was eine ziemlich angemessene Zahl zu sein scheint.

In Bezug auf die Relevanz der Auswahl der Prüfer und die Qualität der Codeüberprüfung können wir uns hier nur auf subjektive Indikatoren stützen. Laut Umfragen von Kollegen haben wir wirklich eine hervorragende Auswahl an Gutachtern erhalten, jetzt muss niemand mehr manuell hinzufügen, und keine PRs werden aufgegeben und vergessen.

Wenn wir über die Zeit sprechen, die zum Bestehen der Codeüberprüfung benötigt wird, ist es zu früh, um Statistiken zu diesem Indikator zu berechnen, da wir kürzlich mit der Erfassung begonnen haben. Zu unserer Verfügung steht nur die Lebensdauer von Pull-Anfragen, die tatsächlich nicht gestiegen oder gefallen sind. Diese Metrik enthält die Zeit zum Testen der Aufgabe. Daher ist es schwierig, eindeutige Schlussfolgerungen zu ziehen. Außerdem haben wir den Überprüfungscode nicht geändert, da wir ihn geändert haben.