Code-Reviews sind in Softwareunternehmen inzwischen eine weit verbreitete agile Technik, die jedoch oft missbraucht wird. Manchmal wird sie zu einem Wettkampfsport zwischen Entwicklern. Manchmal ist es nur der leitende Entwickler, der die Arbeit seiner Untergebenen korrigiert, so wie ein Lehrer die Hausaufgaben korrigiert. Manchmal ist es nur ein Blick auf den Pull Request (PR) vor dem Zusammenführen, eine obligatorische und nutzlose Aufgabe. Manchmal wird es sogar ganz fallen gelassen, weil es Zeitverschwendung ist. In diesem Beitrag werde ich ein wenig über unsere Überprüfungsgewohnheiten in unserem Team hier bei Aliz sprechen, seit es Teil unserer Unternehmenskultur geworden ist.
Wir machen ernsthafte Code-Reviews. Wir sind sozusagen Hardcore. Von jedem Entwickler im Projekt wird erwartet, dass er mehr oder weniger vom ersten Tag an dabei ist. Sie haben vielleicht das Gefühl, dass Sie nichts Sinnvolles zu sagen haben (mir ging es jedenfalls so!), aber das haben Sie tatsächlich. Wenn Sie einen Kommentar oder einen Teil des Codes nicht verstehen, ist das allein schon ein Problem. Wir bauen ein großes System auf, an dem noch jahrelang gearbeitet wird und dessen Code auch nach Jahren noch überarbeitet werden muss. Es muss unbedingt sichergestellt werden, dass alle unsere Entwickler in der Lage sind, ihn zu verstehen. Und die Teilnahme an der Codeüberprüfung ist eine großartige Möglichkeit, die Codebasis kennen zu lernen. Sie tauchen in den Programmierstil, die Praktiken und die Werte des Teams ein. Sie sehen auch die Kommentare der anderen Prüfer und lernen auf diese Weise, worauf es ankommt. Es gibt keine festen Regeln darüber, wie viel Zeit Sie mit der Überprüfung verbringen sollten oder wie oft, aber es wird von Ihnen erwartet, dass Sie es zu einem Teil Ihrer Routine machen.
Wir verwenden Reviewable, ein ziemlich cooles Tool, das vollständig mit GitHub integriert ist. Ich überprüfe Reviewable immer dann, wenn ich etwas Freizeit habe. Wenn ich eine neue Pull-Anfrage sehe, schaue ich sie mir an: Das hilft mir, bei Änderungen auf dem Laufenden zu bleiben. Es ist, als hätte ich den Finger am Puls des Projekts. Und wenn ich offensichtliche Probleme entdecke, weise ich sofort darauf hin: schnelles Feedback ist wichtig.
Ich versuche auch, mir jeden Tag etwa eine Stunde Zeit zu nehmen, um PRs gezielt zu prüfen:
Am besten ist es, eine PR zu überprüfen, an der man nicht maßgeblich beteiligt war. Wenn Sie an der Lösung mitgewirkt haben, werden Sie die Fehler darin nicht erkennen! Aber natürlich, wenn Sie eine PR über einen Teil des Codes überprüfen, über den Sie absolut nichts wissen, nun, dann wird das eine Menge Arbeit für Sie bedeuten. Und höchstwahrscheinlich werden Sie nicht in der Lage sein, tiefere Probleme zu erkennen, aber das ist in Ordnung. Wie bei jedem agilen Prozess besteht der Trick darin, dass wir ihn jederzeit abbrechen können. Wenn ich mich wirklich überfordert fühle, bitte ich jemanden, der mehr Erfahrung hat, es ebenfalls zu überprüfen.
Ihre Arbeit wird also überprüft werden. Es werden Probleme, Fehler und Unklarheiten gefunden werden, aber das ist zu erwarten (der natürliche Zustand von Code ist, dass er fehlerhaft ist). Manchmal wird es bedeuten, dass die Hälfte des Pull Requests umgeschrieben und neu entworfen werden muss, und das wird unangenehm sein. Es besteht die Möglichkeit, dass Sie sich kritisiert fühlen, vielleicht sogar verletzt.
Aber es ist wichtig zu erkennen, dass nicht Sie bewertet werden, sondern die Lösung, die Sie erstellen. Ihre Kompetenz wird nicht in Frage gestellt. Sie werden nicht kritisiert. Ihre Prüfer sind nicht darauf aus, Fehler an Ihnen zu finden, sondern an Ihrem Code; sie wollen Ihnen helfen. Es geht nur darum, gemeinsam etwas zu schaffen. Es kann einige Zeit dauern, bis Sie sich an diese Denkweise gewöhnt haben, vor allem, wenn Sie aus einer sehr hierarchischen Unternehmenskultur kommen.
Es mag anfangs schwierig sein, überprüft zu werden, aber die Belohnungen, oh Mann, die Belohnungen sind einfach großartig:
Okay, genug der Lobeshymnen.
Die Codeüberprüfung als Prozess ist nicht ohne Schwierigkeiten und Fallstricke. Zum einen zerbricht die Codeüberprüfung, wenn es sich nicht um eine Diskussion unter Gleichen handelt, wenn Hierarchie ins Spiel kommt. Man sollte nicht einfach jedem glauben, dass er Recht hat. Sie sollten Ihren Code nicht ändern, nur weil man es Ihnen sagt; Sie sollten immer versuchen, die Gründe dafür zu verstehen. Seien Sie selbstbewusst, wenn Sie prüfen und wenn Sie geprüft werden. Das ist manchmal schwierig. Man braucht Mut, um einem erfahrenen Entwickler zu sagen, dass er eine Funktion falsch verwendet, oder um ihm zu sagen, dass dieser Vorschlag zwar toll ist, aber nicht in diese Ausgabe gepackt werden sollte.
Denn, ja, Code-Reviews führen manchmal zu schleichenden Verbesserungen. Ich habe mich dessen auch schon schuldig gemacht. Wenn es sich nicht um eine dringende Problemlösung handelt, verliert man leicht den Fokus, weil man den PR immer weiter verbessern will. Auch hier gilt: Seien Sie durchsetzungsfähig und konzentriert.
Es besteht auch die Gefahr, dass Meinungsverschiedenheiten ins Leere laufen. Diese entstehen in der Regel dadurch, dass der Gutachter sich nicht klar genug ausdrückt oder der Begutachtete an diesem Tag ein wenig langsam ist. Glücklicherweise kommt dies selten vor. Wenn es nach dem ersten Austausch ein Missverständnis oder eine Meinungsverschiedenheit gibt, rufen wir uns schnell gegenseitig an und besprechen das Problem persönlich. Wenn wir es dann immer noch nicht klären können, ziehen wir eine dritte Partei hinzu, die uns bei der Entscheidung hilft. Es ist wichtig, die endgültige Entscheidung auch in einem abschließenden Kommentar in der Rezension zu dokumentieren. Das Lesen von Überprüfungskommentaren vergangener PRs ist eine gute Möglichkeit, mehr über ein altes Problem herauszufinden.
Eine weitere häufige Beschwerde gegen Code-Reviews ist, dass es zu lange dauert, bis jemand die Sache überprüft. Dieses Problem haben wir auch manchmal: Wenn Ihr PR groß und einschüchternd ist, werden sich die Leute scheuen, ihn überhaupt zu prüfen. Eine Möglichkeit, dies zu bekämpfen, ist es, ihn in kleinere Commits aufzuteilen (was wir sowieso alle anstreben sollten), oder in mehrere PRs. Es hilft auch, wenn Sie den Mut haben, jemanden als Überprüfer zu markieren: Die Leute ignorieren selten, wenn man sie auf diese Weise darauf hinweist.
Trotzdem sind verspätete Überprüfungen ein Problem, vor allem weil es den Entwickler zu häufigen Kontextwechseln zwingt.
Code Review ist kein Allheilmittel, keine magische Lösung, die alle Probleme löst. Es ist nur eine Technik, die in der Softwareentwicklung eingesetzt wird. Sie erfordert eine starke Unternehmenskultur und kann leicht missbraucht werden.
Die offensichtliche Alternative ist die Paarprogrammierung, die (wenn sie richtig gemacht wird) so etwas wie ein Code-Review auf Steroiden ist. Aber im Gegensatz zur Paarprogrammierung sind Reviews asynchron und erfordern keine physische Anwesenheit. Pair Programming ist auch nicht wirklich skalierbar: Mob Programming macht zwar Spaß, ist aber kaum effizient. Die Asynchronität von Code-Reviews macht Mob Programming zu einer echten Möglichkeit! All dies lässt sich gut mit Teams vereinbaren, die aus der Ferne und mit flexiblen Arbeitszeiten arbeiten, und das ist in der derzeitigen Pandemie eine große Sache.
Code-Reviews sind konservativer als Pair Programming und trunk-basierte Entwicklung und eignen sich besser für die Arbeit an großen, veralteten Systemen. Zum Beispiel werden die Ergebnisse der Überprüfung automatisch dokumentiert, während die Diskussionen während der Paararbeit verloren gehen.
