Code Reviews, was sind die Vorteile? [geschlossen]

In meinem Team führen wir keine formellen Codeüberprüfungen durch. Wir neigen dazu zu glauben, dass es bei der Paarprogrammierung und beim Drehen von Paaren oft genug ist.

Sollten wir formelle Codeüberprüfungen in Betracht ziehen? Was wären die Vorteile?

Wir machen Code-Reviews ein bisschen anders (vielleicht).

Wir kommen alle Programmierer zusammen (jeden Freitag) und schauen, was wir in einem Zeitraum von Wochen gemacht haben. Dann wählten wir die Projekte aus, die wir überprüfen möchten, damit jedes abgeschlossene / in Bearbeitung befindliche Projekt mindestens eine oder wenige Personen hat. Dann schauen wir uns in ungefähr einer Stunde die vorgenommenen Änderungen an, suchen nach Fehlern, wie andere Projekte funktionieren usw. Anschließend diskutieren wir, teilen die Fehler mit, wie sie gemacht werden sollten (wir beheben keine Fehler, sondern weisen nur darauf hin und spamme den Code mit FIXME). Alles in allem dauert es für uns (10 Programmierer) normalerweise ca. 2 Stunden.

Die Profis:

• Jedes Mitglied weiß, was im Unternehmen passiert
• Bugs werden schneller gefunden
• Es zwingt uns, lesbaren Code zu schreiben (Code, der ohne Erklärung oder Einführung gelesen werden kann!)
• Optimierungsmethoden / Tricks / Produktivprogramme verbreiten sich schneller
• Programmierer als Spezialist "entwickeln" sich schneller
• Es macht Spaß

Was ich wie erwähnt gegen Pair Programming habe (das ist sicher nur meine persönliche Meinung) ist, dass je länger das Team zusammenarbeitet, desto schneller wird es.

Ich hoffe, es würde ein wenig zum Nachdenken anregen. Viel Glück.

Vielleicht möchten Sie dieses kostenlose Buch lesen:

http://smartbear.com/best-kept-secrets-of-peer-code-review/

Sicher, sie haben ein Produkt zu pushen, aber es gibt immer noch eine Menge nützlicher Informationen.

Außerdem wird erläutert, wie die Paarprogrammierung einige der gleichen Vorteile bietet. Wenn Sie also ein Paar programmieren, müssen Sie den Code möglicherweise überhaupt nicht überprüfen.

Ich habe nicht viel Erfahrung in der Überprüfung in Ihrer Umgebung. Wir machen hier nicht viel Paarprogrammierung. Wir führen Code-Reviews durch, um das Wissen über die Software im Team zu verbreiten. Wir haben ein weiteres Paar Augen, um die Fehler herauszufinden und einen formellen Punkt, um zu überprüfen, ob die Software unseren Kodierungsrichtlinien entspricht .

Die ersten beiden Punkte werden von der Paarprogrammierung ziemlich gut abgedeckt, der dritte Punkt ist sehr abhängig vom Paar und könnte durch eine formale Codeüberprüfung verbessert werden.

Sollten Sie formelle Codeüberprüfungen durchführen?

Absolut

Nur als kurze Randnotiz, ich habe sehr wenig Erfahrung mit Paired Programming, aber ich glaube nicht, dass Reviews mit diesen Methoden in Konflikt geraten würden.

Ich möchte zwei Arten von Code-Reviews vorstellen:

Peer-Code-Überprüfungen

Selbst wenn die gekoppelte Programmierung für Sie funktioniert, schadet es nie , den Code noch einmal im Auge zu behalten. Die Vorteile hierfür sind:

1. Es wird eine Reihe von neuen Augen auf den Code geworfen, jemanden, der genauere Kenntnisse über Bereiche der Codebasis hat, mit denen Sie (und / oder Ihr Partner) möglicherweise nicht so vertraut sind. Dies kann zu Problemen führen.
2. Damit können Sie (das Paar) Ihre Lösung vor der Einreichung erneut validieren. Da der Rezensent nichts über das, was Sie geschrieben haben, weiß, müssen Sie es in seiner Gesamtheit erklären. Dies kann Randfälle aufdecken, an die Sie nicht gedacht haben, oder ungültige Logik.

Peer Code Reviews (in meiner Welt) werden vor jeder Einreichung durchgeführt. Wie sich dies in der gepaarten Programmierwelt auswirkt, weiß ich nicht.

Gruppencode-Überprüfungen

Diese kommen seltener vor als Peer-Code-Überprüfungen. Ich würde meine Gruppe (oder einen Teil meiner Gruppe) im Allgemeinen in einen Besprechungsraum ziehen, um einen informellen Code zu erhalten. Ich würde im Allgemeinen einen Code auswählen, der von einer zufälligen Person im Team geschrieben wurde, vorzugsweise Code, der von Grund auf neu geschrieben wurde - überarbeiteter Code legt keine Probleme wie frischer Code offen.

Stellen Sie sicher, dass jeder weiß, dass diese Bewertungen nicht dazu gedacht sind, die Leistung zu beeinträchtigen und zu reflektieren. Sie sollen lediglich sicherstellen, dass die Kodierungsstandards Ihres Teams eingehalten werden, und allen helfen , bessere Ingenieure zu sein und somit für das Team nützlicher zu werden (und weitere Karrierezuwächse usw.) - und sicherstellen, dass dies die wahre Absicht der Überprüfungen ist . Wenn jemand etwas anderes vermutet, werden diese gefürchtet und weniger produktiv.

Ich würde den Code einigermaßen informell durchgehen und jeden im Raum auf verschiedene Lösungen hinweisen lassen, die er möglicherweise hat, oder auf logische Mängel, auf die er stößt. Dies soll eher eine Gruppendiskussion sein als ein Leiter, der allen sagt, wie sie codieren sollen.

Ich habe festgestellt, dass der Einsatz dieser beiden Methoden den Fortschritt der Ingenieure beschleunigt und die Anzahl der Fehler erheblich senkt :)

Ich habe in der Praxis noch nie Pair-Programmierung gemacht (nur darauf gehofft), daher kann ich die beiden Praktiken nicht direkt vergleichen. Ich kann jedoch über meine Erfahrungen mit formalen Code-Überprüfungen berichten.

Ich habe in einem früheren Projekt formelle Codeüberprüfungen zu Legacy-Code durchgeführt. Das Projekt war völlig durcheinander und das Management begrüßte jede Initiative mit der Hoffnung, Ordnung ins Chaos zu bringen. Zu dieser Zeit dachte ich, formale Codeüberprüfung sei eine gute Idee. Wir haben Fehler gefunden und festgestellt, dass die Qualität von frisch geschriebenem Code erheblich besser war als die von altem Code. Ich habe Statistiken, Fehlerzählungen usw. gesammelt, um dies zu beweisen.

Wir haben durchschnittlich eine Sitzung pro Woche mit 3-5 Personen durchgeführt. Jede Sitzung dauerte ungefähr 3-4 Stunden pro Person (einschließlich Vorbereitung) und überprüfte 200-300 Codezeilen (LOC) *. In diesem Tempo konnten wir in einem Zeitraum von mehr als 6 Monaten etwa 5.000 von etwa 50.000 LOC überprüfen.

Rückblickend halte ich das für sehr kostspielig. Bei diesem Tempo hätten wir 5 Jahre gebraucht, um die gesamte alte Codebasis zu überprüfen. OTOH, das mehr als eine Sitzung pro Woche hat, hätte der Entwicklung Ressourcen entzogen. Das ist natürlich das typische Dilemma mit altem Code. Aber selbst die formelle Überprüfung des gesamten frisch geschriebenen Codes würde viel Zeit in Anspruch nehmen und die Entwicklung erheblich verlangsamen.

Mein Fazit ist, dass formale Codeüberprüfungen am besten an neu geschriebenem Code durchgeführt werden, der sich auf die kritischsten Teile des Codes konzentriert. Der Rest wird informeller gehandhabt, möglicherweise über die Paarprogrammierung. Dies ist jedoch nur meine aktuelle Meinung, die sich ändern kann. Ich behaupte nicht, ein Code-Review-Guru zu sein.

* Dies ist das normale Tempo für formale Codeüberprüfungen.

Typische Codeüberprüfungsraten liegen bei etwa 150 Codezeilen pro Stunde. Das Überprüfen und Überprüfen von mehr als ein paar hundert Codezeilen pro Stunde auf wichtige Software (z. B. sicherheitskritische eingebettete Software) ist möglicherweise zu schnell, um Fehler zu finden.

Zitiert aus Wikipedia (Schwerpunkt von mir).

Der Grund, warum Code-Überprüfungen existieren, besteht darin, dass isolierte Programmierer ihren Code erfüllen und diskutieren und prüfen müssen, ob er ihrem Standard entspricht.

Sie erwähnen keine Qualitätsprobleme, so dass es den Anschein hat, als würde Ihr Team bereits genug Codeprüfungen durch die Paarprogrammierung durchführen. Genial!

Richtig durchgeführte Paarprogrammierungen machen formale Codeüberprüfungen überflüssig. Aber versuchen Sie es ein paar Wochen und sehen Sie, wie es funktioniert, aber ich vermute, Sie werden keine Verbesserungen bemerken.

Denken Sie daran, dass Codeüberprüfungen ein anstrengender, teurer Prozess sind und nicht leichtfertig durchgeführt werden dürfen. Es führt im Wesentlichen eine Übergabe in Ihr Projekt ein, die kostspielig ist und alles verlangsamt . Es ist viel besser, zunächst sicherzustellen, dass der Code korrekt ist, als später nach Problemen zu suchen.

Könnte sein. Codeüberprüfungen brauchen Zeit. Sie sind nur dann sinnvoll, wenn die Zeit, die die Überprüfung in Anspruch nimmt, zu einem anderen Zeitpunkt im Prozess gespeichert wird. Welche Einsparungen erwarten Sie bei Codeüberprüfungen? Haben Sie Schwierigkeiten, die durch Codeüberprüfungen verhindert werden könnten?

Wenn Sie Pair-Programmierung durchführen, verringert sich die Notwendigkeit einer Code-Überprüfung erheblich, aber Sie würden sicherlich von einer Peer-Überprüfung profitieren. Damit dies von Vorteil ist, muss es von einer älteren und erfahreneren Person als den Paarmitgliedern durchgeführt werden.

Was sind die Vorteile? Nun, es wäre besser, wenn Sie das Risiko in Betracht ziehen, es nicht zu tun.

• Das Paar könnte etwas falsch machen oder es auf suboptimale Weise tun
• Möglicherweise befolgen Sie keine Codierungsstandards oder dokumentieren den Code nicht ordnungsgemäß. Ein Peer Review ist wirklich gut darin, diese zu finden
• Niemand außer dem Paar versteht einen bestimmten Code. Was passiert also, wenn beide Partnermitglieder gegangen sind und der Code schlecht dokumentiert ist? Andere werden Zeit damit verschwenden, Dinge herauszufinden. Eine dritte Person, die weiß, was Sie getan haben, verringert das Risiko.

Ich bin amüsiert, dass die Leute gesagt haben, dass die Codeüberprüfung eine Zeitverschwendung ist. Ja, das braucht Zeit. Möglicherweise wird der Code dadurch nicht geändert, aber das bedeutet nicht, dass er verschwendet wird. Das heißt, Sie müssen Ihr Brandschutzsystem nicht regelmäßig überprüfen, weil es Zeitverschwendung ist.

Für mich ist der Hauptvorteil von Code Reviews, dass die Leute besseren Code schreiben.

Wenn Sie wissen, dass Ihr Code gelesen und überprüft wird, sind Sie sich der Lesbarkeit und der "korrekten" Ausführung Ihres Codes bewusster. Wenn Sie wissen, dass der Code direkt in das Repository gelangt und niemand anderes ihn liest, es sei denn, es handelt sich um Fehlerbehebungen, kann es passieren, dass Dinge verrutschen und Feldnamen nicht neu faktorisiert werden, wenn sich ihre Verwendung ändert einkalkuliert werden etc. etc.