Wie können wir Code-Reviews beschleunigen, ohne die Gründlichkeit der Code-Reviews zu opfern?

An unserem Arbeitsplatz verwenden wir die Methode Agile Scrum. Allerdings folgen wir ihm nicht wirklich religiös.

Wir führen jedoch sehr gründliche Code-Reviews durch. Das Problem bei Code-Reviews ist, dass es eine Weile dauert, die Probleme mit dem Code zu dokumentieren und an den Entwickler zurückzusenden. Ich nehme an, sie möchten, dass die Code-Reviews dokumentiert werden, weil es für Auditzwecke gut sein könnte und auch beweist, dass die Code-Reviewer ihre/seine Arbeit tatsächlich richtig machen.

Aber es scheint viel Zeit in Anspruch zu nehmen, wenn wir den Code von jemandem analysieren und Fehler dokumentieren. Es wäre besser gewesen, die Zeit mit neuer Entwicklung/Forschung/Support/Wartung zu verbringen.

Wie können wir Code-Reviews beschleunigen, ohne die Gründlichkeit der Code-Reviews zu opfern?

Sicherlich sind Sie jetzt besser dran, die Zeit für die Codeüberprüfung zu verwenden, anstatt sich in Zukunft mit dem angesammelten Ball von Code schlechter Qualität zu beschäftigen. Und wenn das Dokumentieren aller Fehler so lange dauert, müssen Sie ansprechen, warum es so viele Fehler gibt
Ein feines Detail: Möchten Sie nicht auf Gründlichkeit verzichten, oder haben Sie möglicherweise etwas mehr Gründlichkeit als Sie eigentlich brauchen und sind bereit, diese gegen Geschwindigkeit einzutauschen? Letzteres ist ein Balanceakt, sodass Ihnen normalerweise mehr Optionen zur Verfügung stehen.

Antworten (5)

Ein paar Vorschläge:

Code-Qualitäts-Tools

Es lohnt sich, über den Einsatz automatisierter Codequalitätstools wie Findbugs , PMD und Checkstyle nachzudenken .

Bringen Sie das Team idealerweise dazu, sich auf eine Reihe von Codierungsstandards zu einigen und diese als Vorlagen in den verschiedenen Codequalitätstools zu implementieren. Führen Sie dann die Tools von Continuous Integration aus und scheitern Sie möglicherweise sogar an Builds, wenn die Qualitätsstandards nicht erfüllt werden.

Dies wird Code-Reviews nicht ersetzen, aber es wird hoffentlich Diskussionen bei Code-Reviews in Bezug auf Codierungsstil, Formatierung usw. reduzieren.

Allein die Tatsache, dass Sie klare Standards haben, trägt dazu bei, den Zeitaufwand für Code-Reviews zu reduzieren.

Code-Review-Tools

Es gibt einige gute Code-Review-Tools.

Ein Beispiel ist Crucible .

Diese Arten von Tools sind großartig, um Code-Reviews zu erleichtern, und sie helfen auch sehr bei Code-Reviews, die remote durchgeführt werden (z. B. wenn ein Teammitglied von zu Hause aus arbeitet).

Sind die Ziele, dass die Überprüfung geprüft werden kann? oder um zu beweisen, dass der Prüfer seine/ihre Arbeit macht? Wir dokumentieren sie als neue Aufgaben/Entdeckungen auf unserem Scrum-Board und einige greifen sie einfach auf.

Ich denke, das Hauptziel von Code-Reviews ist der Wissensaustausch und das Auffinden wiederkehrender Codefehler, nicht die Dokumentation, es sei denn, Sie sind gesetzlich dazu verpflichtet :)

Auf Checklisten basierende Code-Reviews : Dieses E-Book bietet eine großartige praktische und leichtgewichtige Strategie für Peer-Code-Reviews. Für eine Zusammenfassung dieser Strategie lesen Sie meine Antwort auf eine andere Frage zu SE.

Paarprogrammierung : Einige Teams denken, dass Paarprogrammierung eine gute Alternative zu Codeüberprüfungen ist, da der Code während des Vorgangs von einer anderen Person überprüft wird.

Paarprogrammierung ist gut, aber nicht ausreichend, um eine Überprüfung zu ersetzen - die Überprüfung erfolgt kühl, während das Paar beide in der Hitze des Gefechts ist
Laut Untersuchungen von Cisco (basierend auf über 2500 Code-Reviews) zeigen 61 % der Code-Reviews keine Mängel. Daher denke ich, dass in der Mehrheit (61%) der Fälle Paarprogrammierung ausreichend wäre. Abhängig von den tatsächlichen realen Risiken kann eine zusätzliche Überprüfung erforderlich sein, aber in Umgebungen mit relativ geringem Risiko kann dies gerade gut genug sein. Die Ergebnisse können sehr unterschiedlich sein und die Meinungen zu diesem Thema gehen auseinander. Sie könnten nur Paarprogrammierung versuchen und eine Ursachenanalyse für Probleme durchführen. Dies, um herauszufinden, ob eine formellere Überprüfung dieses Problem gefunden hätte, und Ihren Prozess entsprechend zu aktualisieren.
Hmm.. Das bedeutet, dass Überprüfungen in 39 % der Fälle Fehler finden – wenn 2 von 5 Überprüfungen einen Fehler finden, ist das definitiv ein Grund, damit fortzufahren. Und was genau ist ein Mangel in Bezug auf diese Studie? Ein tatsächlicher Fehler/eine Regression oder eine Designentscheidung, die technische Schulden mit sich bringt?
Wenn Sie es so ausdrücken, haben Sie vielleicht Recht :) Trotzdem würde ich vermuten, dass die Anzahl der Fehler nach der Paarprogrammierung geringer ist. Ich weiß nicht genau, was Defekt in Bezug auf diese Studie bedeutet, aber auf die Studie wird im verlinkten E-Book meiner Antwort verwiesen und sie zusammengefasst, wenn Sie wirklich interessiert sind. (obwohl ich hinter einer Anmeldewand versteckt war, dachte ich, das Lesen war meine Zeit wert)
Einmal ließ ich den letzten Fehler, den ich im Code fand, für die Überprüfung zurück, als Test, um zu sehen, ob das Code-Überprüfungsteam ihn finden würde. Sie haben es nur in 50 % der Fälle gefunden, daher ist das Fehlen von Fehlern, die in einer Codeüberprüfung gefunden wurden, für mich ein Warnsignal.

Vor ein paar Jahren steckte mein Team in einer großen Zeit-/Ressourcenkrise. Wir haben diese Frage gelöst, indem wir einen Senior (mich) beauftragt haben, die Code-Reviews durchzuführen.

Ich habe Findbugs verwendet, um meine Suche einzugrenzen und offensichtliche Fehler zu identifizieren, aber ich vertraute ihm nicht vollständig, da es anfällig für Fehlalarme war. Zum Beispiel würde es häufig behaupten, dass der Logger eine unbenutzte Variable war, obwohl ich sehen konnte, dass der Code stark protokolliert wurde.

Nachdem ich Findbugs in diesem Umfang verwendet hatte, überprüfte ich den betreffenden Code manuell im Kontext, um Fehlalarme auszuschließen und Probleme zu finden, für deren Suche Findbugs schlecht gerüstet sind (Rechtschreib- und Grammatikfehler).

Ich würde 30 bis 60 Minuten damit verbringen, mich auf die Codeüberprüfung vorzubereiten, dann 10 Minuten für das eigentliche Meeting. Die insgesamt aufgewendeten Ressourcen betrugen im Durchschnitt weniger als 1 Programmiererstunde. Wir haben es nie versäumt, in jedem Meeting mindestens drei Fehler zu finden und zu beseitigen.

Ich stimme sicherlich zu, dass die Vorbereitung auf eine Codeüberprüfung der Schlüssel ist!

Sie könnten erwägen, Elemente des Test Driven Development zu verwenden.

Möglicherweise finden Sie die Code-Reviews schneller und nicht weniger gründlich, wenn Sie die Tests vor der Entwicklung erstellen lassen, sodass der Entwickler seinen Fortschritt kontinuierlich analysieren kann, bis er die Anforderungen des vorab genehmigten Tests erfüllt.

Dies könnte sicherlich das Hin und Her der Überprüfung verringern.

Hören Sie auf, Code-Reviews durchzuführen, und beginnen Sie mit der Paarprogrammierung. Wenn der Zweck von Code-Reviews darin besteht, die Qualität des Codes zu verbessern und Teammitgliedern dabei zu helfen, ihr Domänenwissen zu erweitern, dann ist Pair Programming eine viel proaktivere Form der Code-Review. Es baut Qualität auch früher in Ihren Entwicklungsprozess ein.

Beschleunigen = Effizienz verbessern. Sie fragen sich also, wie wir die Effizienz steigern können, ohne die Effektivität zu opfern. Ein großer Nachteil von Code-Reviews besteht darin, dass die Teammitglieder, die den Code-Review durchführen, zuerst das Geschäftsproblem sowie den Code, den sie zu überprüfen versuchen, verstehen müssen. Dies geschieht oft durch reaktives Überprüfen der User Story und des Codes, nachdem alles bereits „fertig“ ist.

Ein praktischer Weg, um dasselbe Wissen zu erlangen, ist die Paarprogrammierung. Sie schlagen zwei Fliegen mit einer Klappe; Implementierung der User Story und parallel dazu eine gründliche CR. Da ist Ihr Effizienzgewinn (und es ist normalerweise auch effektiver, da die meisten Erwachsenen durch praktische Aktivitäten besser lernen als passiv alleine zu lernen).

Wie können wir Code-Reviews beschleunigen, ohne die Gründlichkeit der Code-Reviews zu opfern?
AntwortenHierDatenschutz-Bestimmungen1y, 0v