it-swarm.dev

Wie bringen Sie die Leute dazu, die Codeüberprüfung zu akzeptieren?

Alle Programmierer haben ihren Programmierstil. Aber einige der Stile sind sagen wir ... sagen wir nicht. Sie müssen also Code überprüfen, um bestimmte Regeln für gutes Design und gute Programmiertechniken festzulegen.

Aber die meisten Programmierer mögen keine Codeüberprüfung. Sie mögen es nicht, wenn andere Leute ihre Arbeit kritisieren.

Wen glauben sie, sollen sich besser als ich betrachten und mir sagen, dass dies schlechtes Design ist, dies könnte auf andere Weise geschehen. Es funktioniert richtig? Was ist das Problem? Dies ist etwas, was sie könnten sagen (oder denken, aber nicht sagen, was genauso schlimm ist, wenn nicht schlimmer).

Wie bringen Sie die Leute dazu, die Codeüberprüfung zu akzeptieren, ohne einen Krieg zu beginnen?

Wie können Sie sie davon überzeugen, dass dies eine gute Sache ist? das wird nur ihre Programmierkenntnisse verbessern und später viel Arbeit vermeiden, um zig Mal etwas zu reparieren und zu patchen, was hey ... "es funktioniert"?

Die Leute werden Ihnen sagen, wie Sie eine Codeüberprüfung durchführen (Peer-Programmierung, formelle Inspektionen usw.), worauf Sie bei einer Codeüberprüfung achten müssen. Es wurden Studien durchgeführt, um die Anzahl der Fehler zu zeigen, die entdeckt werden können, bevor die Software die Produktion erreicht usw. Aber wie Überzeugen Sie Programmierer, eine Codeüberprüfung zu akzeptieren?

152
user7197

Ich habe festgestellt, dass Leute, die keine Codeüberprüfungen mögen, ihr Bestes geben werden, um alles zu umgehen, was Sie eingerichtet haben.

Der beste Weg, um sicherzustellen, dass der Code, mit dem Sie arbeiten, ordnungsgemäß überprüft wird, besteht darin, irgendwo zu arbeiten, wo dies als normale Codierungsmethode behandelt wird und nur Entwickler eingestellt werden, die wahrscheinlich gut in diese Umgebung passen.

Wenn Sie nicht ändern können, mit wem Sie arbeiten, haben Sie möglicherweise Erfolg, wenn Sie zuerst Ihren eigenen Code zur Überprüfung angeben. Ermutigen Sie sie, daran etwas auszusetzen (wage ich vorzuschlagen, ein paar absichtliche Fehler hinzuzufügen?), Damit Sie zeigen können, dass es nicht ist, um den betreffenden Entwickler zu kritisieren. Das ist das Hauptproblem, IMO: Die Leute nehmen Codeüberprüfungen zu persönlich.

170
Jon Skeet

Einfach: Weisen Sie die wichtigen Projekte Programmierern zu, die Codeüberprüfungen akzeptieren. Das ist eine klare Botschaft: Dieses Projekt ist zu wichtig, um es Amateuren zu überlassen.

Die Programmierer, die nicht kooperieren, können Wartungsarbeiten durchführen. Ihr Unternehmen wird reichlich davon haben, wenn Codeüberprüfungen nicht weit verbreitet waren. Machen Sie deutlich, dass dies eine Sackgasse ist. Diese Produkte werden an Bedeutung verlieren, fallen gelassen oder durch neuere Produkte ersetzt, die vom Code überprüft wurden.

Machen Sie bei der Einstellung deutlich, dass Codeüberprüfungen in Ihrem Unternehmen die Norm sind. Weisen Sie den neuen Projekten die neuen Mitarbeiter zu, die Codeüberprüfungen akzeptieren.

Insgesamt wird dies Ihren Entwicklern mitteilen, dass das Unternehmen Codeüberprüfungen durchführt. Sie können wählen: mitgehen oder raus. Es gibt in keinem Unternehmen eine Zukunft für Menschen, die gegen das Unternehmen kämpfen.

39
MSalters

Nun, Sie können nicht wirklich, wenn sich jemand einfach weigert und Sie nicht ihr Chef sind.

Aber der Hauptgrund für einen anderen Stil ist ...

Konsistenz

Ich denke, was auch immer für ein verrückter Stil es gibt, er muss konsequent sein. Wenn ein Projekt in diesem Stil erstellt wird, muss es normalerweise in diesem Stil bleiben, es sei denn, es gibt einen außergewöhnlich zwingenden Grund für eine Änderung. Also, wenn ihr Stil nicht passt; Es ist eine Tatsache, dass es passend gemacht werden sollte. Keine Frage hier.

Es gibt andere Probleme, die einfach falsch sind. Sicherheit, allgemeines "Unrecht" usw. Diese sind unbestreitbar und sollten geändert werden.

Wenn sich jemand weigert, etwas als schlechtes Design anzuerkennen, nachdem Sie ihm den richtigen Weg gezeigt und ihm alle Risiken und Probleme seiner Arbeit gezeigt haben, müssen Sie meiner Meinung nach selbst entscheiden, wie er handeln soll. Aber Sie würden hoffen, dass Sie nicht mit Menschen arbeiten, die so unvernünftig sind.

30
Noon Silk

Ich bin Programmierer und ich genieße Codeüberprüfungen. Der Schlüssel zu guten Codeüberprüfungen liegt meiner Erfahrung nach darin, den Code zu verbessern.

Wenn ich mit einem Kollegen eine Codeüberprüfung durchführe und er/sie auf mögliche Verbesserungen oder lauernde Fehler hinweist, bin ich glücklich. Der Code verbessert sich und wir werden wahrscheinlich beide etwas schlauer. Warum sollte mir das nicht gefallen?

Leider sehen einige Leute Codeüberprüfungen als eine Möglichkeit, die Tatsache zu betonen, dass Ihr Code 4 Leerzeicheneinrückungen anstelle von 3 Leerzeicheneinrückungen oder anderen nicht wichtigen Details aufweisen muss.

Stellen Sie sicher, dass Personen, die Codeüberprüfungen durchführen, nützliche Informationen geben können und werden. Wenn die einzige Überprüfung des Eingabecodes etwas ist, das mit einem Tool leicht durchgeführt werden kann, sind Codeüberprüfungen Zeitverschwendung.

Stellen Sie sicher, dass Codeüberprüfungen keine Zeitverschwendung sind und die meisten Entwickler sie genießen werden.

26
Brian Rasmussen

Wenn ich bei der Verwaltung eines Projekts sage, dass wir Codeüberprüfungen durchführen, werden wir Codeüberprüfungen durchführen. Ich werde natürlich gute Gründe dafür liefern, aber letztendlich liegt es in meiner Verantwortung und Entscheidung, sie umzusetzen.

Und wenn es den Programmierern nicht gefällt, können sie eine alternative Beschäftigung finden. Die meisten fehlgeschlagenen Projekte können sinnvoll verbessert werden, indem ohnehin die Hälfte der Entwickler entfernt wird. Nach meiner Erfahrung sind es die ärmsten Entwickler, die sich am meisten gegen Codeüberprüfungen aussprechen.

12
anon

Der einzige Grund, warum ich mich für den Codeüberprüfungsprozess entschieden habe, war, dass vor ungefähr einem Jahr die Person, die versucht hat, sie durchzusetzen, die Überlegenheitskarte herausgezogen hat und uns veranlasst hat, den Code des anderen für ein bestimmtes Projekt zu überprüfen. Am Ende dieses Projekts konnte ich den enormen Nutzen erkennen und versuche nun, Codeüberprüfungen für meine Projekte durchzuführen.

12
James Hay

"Es funktioniert" ist nicht genug. Code ist nicht nur für die Ausführung von Maschinen geschrieben, sondern auch für Benutzer zum Lesen, Anpassen und Verbessern. Wenn die Leute sich nicht durch Code zurechtfinden, können sie nicht alle diese Aufgaben erledigen, die ein wesentlicher Bestandteil der Programmierung sind.

Wenn Joe Programmer sagt: "Sehen Sie sich meinen Code nicht an, ich bin die einzige Person, die ihn verstehen muss." Ich würde dies bezweifeln. Nur in seltenen Fällen wird Code von nur einer Person berührt. Und selbst wenn dies der Fall ist: Versteht Joe nächste Woche, nächsten Monat, nächstes Jahr seinen eigenen Code? Wahrscheinlich nicht.

9
lutz

In fast allen kommerziellen Einrichtungen (und den meisten nichtkommerziellen) besitzen Programmierer nicht den Code, den sie schreiben, sondern ihren Arbeitgeber.

In fast jeder kommerziellen Einrichtung (und den meisten nichtkommerziellen) scheinen die meisten Programmierer zu glauben, dass sie do besitzen den Code, den sie schreiben.

Dies verursacht eine Menge Probleme bei der Akzeptanz der Codeüberprüfung als Technik zur Designverbesserung ...

Möglichkeiten zur Reduzierung des Widerstands können sein:

  • einführung Paarprogrammierung : Es wird kein Code geschrieben, es sei denn, zwei Programmierer betrachten ihn. Sofortige Codeüberprüfung in Echtzeit. Stellen Sie sicher, dass die Paare regelmäßig wechseln.
  • finden Sie einen Weg, um Code-Bewertungen zu "anonymisieren", so dass es nicht persönlich sein kann
  • überprüfung in kleinen Stücken, so dass niemand mit langen Listen von Verbesserungen konfrontiert wird
  • lassen Sie keinen Code einchecken, bis er überprüft wurde (und Aktionspunkte implementiert und überprüft wurden).
  • einführung einer diskretionären Komponente zur Zahlung, abhängig von der Akzeptanz von Codeüberprüfungen

Ich empfehle keine (naja, vielleicht die erste) der oben genannten speziell.

Was zählt, ist ein wirkliches Verständnis dafür zu bekommen, was die real Einwände gegen Bewertungen sind, nicht was Sie an der Oberfläche hören. Vielleicht anwenden 5 Warum um tiefer zu werden?

9
Mike Woodhouse

Ich mag keine Codeüberprüfung, wenn ich Entwickler bin.

Aber ich möchte wirklich eine Codeüberprüfung durchführen, wenn ich führend bin. Wir wissen warum.

Einige Entwickler werden jedoch sicher keine Codeüberprüfung mögen, genau wie ich.

Wie wäre es mit tring anonym Codeüberprüfung?

Wir können nach der Codeüberprüfung beispielhafte Codeteile oder Tipps schreiben, um herauszufinden, was der bessere Weg ist.

Ein einfaches Beispiel:

Originalstück:

s=objGotFromSomewhere.doSomething()

besseres Stück:

if(objGotFromSomewhere!=null){
      s=objGotFromSomewhere.doSomething()
  }

memo:

In einem Projekt haben wir ... ein Problem, das durch ... Grund verursacht wurde

Tipps:

immer überprüfen ...

Wir können dies ins Wiki oder irgendwohin stellen und dann in der wöchentlichen Teambesprechung darüber sprechen. Tech Leader wird es tun und hochrangige Entwickler und jedes Teammitglied dazu ermutigen.

Ich denke, anonym ist wichtig, das heißt, niemand weiß, wer den schlechten Code generiert hat.

Die Leute mögen vielleicht keine Codeüberprüfung, möchten aber wissen, was der bessere Weg ist.

9
chiesa

Ich habe gute Erfahrungen mit Paarbewertungen gemacht. Zwei Personen untersuchen sich gegenseitig im Quellcode, während beide vor demselben Monitor sitzen. Wir stellen sicher, dass es nicht immer die gleichen Leute sind und dass im Voraus klar und vereinbart ist, wonach beide suchen.

Um Codeüberprüfungen durchzuführen, sind jedoch aufgeschlossene Personen erforderlich, die bereit sind, Kritik zu akzeptieren.

8
Benedikt

Wenn eine höhere Behörde einen Überprüfungsprozess einleitet, sollte dies funktionieren. Sogar diejenigen, die sich zuerst gegen die Idee auflehnen, sollten hoffentlich vorbeikommen, um ihre Vorteile zu sehen. Wenn sie nicht ... nun, können sie das nicht wirklich ändern.

Wenn Sie nur ein Einzelkämpfer unter uninteressierten Kollegen sind, wird es Ihnen viel schwerer fallen. Der Schlüssel in beiden Szenarien ist jedoch, den Rezensenten klar zu machen, dass es sich nicht um einen persönlichen Angriff auf ihre Fähigkeiten handelt, sondern um eine Teamleistung, um alle Bugs effizienter zu quetschen.

7
deceze

Wie bringen Sie die Leute dazu, Ihre Codeüberprüfung zu akzeptieren?

Du kannst nicht, also tust du nicht. Und Sie sind nicht für die Arbeit anderer verantwortlich, bis Sie aufgefordert werden, die Verantwortung dafür zu übernehmen.

Sie könnten sich Ihrer "Bewertung" nähern, so dass es eher wie "Feedback" ist. Sie sind nicht der Chef, der nach Dingen sucht, die jemand anderes falsch gemacht hat, sondern zwei Fachleute, die unterschiedliche Ansätze für dasselbe Problem diskutieren.

IMO, zwei beliebige Programmierer werden unterschiedliche Wege finden, um ein Problem zu lösen, und beide können Recht haben.

Fragen Sie den Rezensenten: "Was ist für Sie der Vorteil dieses Ansatzes?" Geben Sie auch die Nachteile an, die Sie sehen, und die Vorteile Ihres alternativen Ansatzes. Bitten Sie um Bestätigung der DAs, auf die Sie hingewiesen haben: "Stimmen Sie zu, dass dies ein Problem mit dem Code sein könnte, den Sie haben?"

Ich denke, die meisten Programmierkonflikte beruhen auf Wertunterschieden und der Vermutung, was in Zukunft passieren könnte. Menschen können Stunden damit verbringen, über etwas völlig Unbestimmtes zu streiten. Konzentrieren Sie sich jetzt auf echte Probleme, weniger auf Dinge, die später passieren könnten (aber nicht vermeiden).

7
Beth

Der beste Weg ist, dass die Entscheidung von den Programmierern kommt, die sie treffen.

Ich würde vorschlagen, einige Fähigkeiten der Menschen zu nutzen und mit einer Diskussion darüber zu beginnen, wie sichergestellt werden kann, dass die Gruppe zusammenarbeiten kann. Ich würde auch darüber sprechen, wie sichergestellt werden kann, dass die Fähigkeiten der Programmierer am Arbeitsplatz auf dem neuesten Stand bleiben.

Eine Möglichkeit besteht natürlich darin, Codeüberprüfungen durchzuführen, aber es gibt auch andere Möglichkeiten, die erfolgreich sein könnten, beispielsweise das Lesen und Diskutieren eines Buches über das Programmieren. Ich empfehle "Clean Code: Ein Handbuch für agiles Software-Handwerk" ( http://www.Amazon.com/Clean-Code-Handbook-Software-Craftsmanship/dp/0132350882 ).

Eine andere Sache ist, dass jeder Programmierer seine Projekte vor der Gruppe präsentiert, wenn er etwas erledigt hat. Das stellt natürlich sicher, dass die hässlichsten Dinge nicht geschrieben werden und jeder stolz darauf ist, etwas erreicht zu haben.

6

Persönlich denke ich, dass ein Programmierer, der eine Codeüberprüfung nicht mag, nur ein sehr schlechter Programmierer ist. Wenn Sie guten Code schreiben, haben Sie bei einer Überprüfung nichts zu befürchten. Sie könnten tatsächlich für Ihren Stil gelobt werden. Aber wenn Sie es sich zur Gewohnheit machen, schlechten Code zu schreiben, kann ich mir vorstellen, warum jemand eine Bewertung nicht mag. Es ist jedoch nur nützlich, wenn jemand anderes auf die Fehler in Ihrem Stil hinweist, um Ihre eigene Erfahrung zu verbessern! Sie sollten aus einer Bewertung lernen und nicht davor zurückschrecken. Dies ist eine enorme Steigerung der Codequalität.

Wenn Sie Codeüberprüfungen durchführen, stellen Sie klar, dass Sie dies tun, um die Codequalität zu verbessern und nicht um die schlechten Entwickler zu bestrafen. Stellen Sie sicher, dass Ihre Programmierer diese Überprüfungen als lehrreich betrachten und nicht als Möglichkeit, ihre Leistung zu messen.

Ich hatte viele Codeüberprüfungen und habe mich auf komplexe Algorithmen spezialisiert, daher sieht mein Code für andere eher komplex aus. Mitprogrammierer halten mich für sehr gut in dem, was ich tue, und lieben es einfach, meinen Code zu überprüfen, weil er einen pädagogischen Wert hat. Und natürlich finden sie gelegentlich einige kleine Fehler in meinem Code, aber im Allgemeinen sind diese Codeüberprüfungen Verbesserung der Arbeitsqualität der Person, die den Code überprüft!

6
Wim ten Brink

Wir verwenden ReviewBoard , um Bewertungen durchzuführen. In unserem Unternehmen sind Überprüfungen freiwillig: Wenn Sie etwas Interessantes tun (wesentliche Ergänzungen oder Änderungen), erwarten wir, dass Sie eine Überprüfungsanfrage erstellen, die von den Kollegen in Ihrem Team durchgeführt wird. Die ausgewählten Teammitglieder können dann die Überprüfung genehmigen oder weitere Änderungen anfordern.

Wenn Sie Überprüfungen erzwingen müssen, weil ein Programmierer nicht mitspielt, müssen möglicherweise alle Festschreibungen an das SCM mit einer Überprüfungs-ID versehen werden, die überprüft wird, um als genehmigt markiert zu werden, bevor sie akzeptiert wird.

5
MathieuK

Gehen Sie nicht immer davon aus, dass das Problem am Ende ist. Vielleicht machst du es falsch.

Finden Sie heraus, warum sie es nicht mögen, und anstatt automatisch anzunehmen, dass sie ein "schlechter Programmierer" sind, überlegen Sie zunächst, ob sie einen Punkt haben und ob Sie ein schlechter Prüfer von Code sind oder einfach nur schlecht kommunizieren. Es ist möglich.

Wenn Ihre Codeüberprüfungs-/Stilregeln nicht subjektiv, willkürlich oder verrückt sind, können Sie jedem kompetenten, professionellen Programmierer die Gründe dafür leicht erklären. Wenn Sie nicht können, müssen Sie vielleicht überdenken, was Sie tun oder wie Sie es präsentieren.

Wenn das Problem nur bei ein oder zwei Personen auftritt, handelt es sich wahrscheinlich eher um ein tieferes HR-Problem mit diesen Personen und hat nichts mit der Codeüberprüfung zu tun. Die Sache mit der Codeüberprüfung ist nur ein Symptom für dieses größere Problem.

5
frankodwyer

Wenn Sie von Anfang an für das Projekt verantwortlich sind oder der Hauptentwickler sind, sollten Sie in der Lage sein, Codeüberprüfungen durchzuführen, indem Sie diese als Teil Ihrer Projektmethodik einführen. Stellen Sie sicher, dass die Überprüfungen durchgeführt werden, indem Sie sie gegebenenfalls selbst leiten. Wenn Sie verantwortlich sind und einige Leute Ihrem Beispiel nicht folgen, müssen Sie sie entweder davon überzeugen, mit dem Programm zu beginnen, oder sie durch Leute ersetzen, die dies tun.

Wenn Sie nicht verantwortlich sind, müssen Sie die Teammitglieder davon überzeugen, dass es für sie von Vorteil ist, Codeüberprüfungen durchzuführen. Überzeugen Sie zunächst die anderen Teammitglieder, Ihren Code zu überprüfen. Dokumentieren Sie Ihr Design und Ihre Schnittstellen und führen Sie sie durch Ihren Code. Schreiben Sie dann eine Zusammenfassung und Aktionselemente nach der Überprüfung für sich selbst und verteilen Sie sie an Ihre Teammitglieder. Wenn sich daraus ein Vorteil ergibt, wird dies für das Team schnell ersichtlich.

Wenn es Widerstand gibt, müssen Sie herausfinden, was die Einwände der Menschen sind. Sie könnten gültig sein. Zum Beispiel könnte das Projekt klein genug sein und das gesamte Team könnte so erfahren sein, dass jeder im Projekt den gesamten Code im Projekt auch ohne formelle Überprüfungen effektiv begutachtet.

Ich finde Codeüberprüfungen am nützlichsten bei sehr großen Projekten, bei denen es einer Person nicht möglich ist, den gesamten Code zu analysieren, bei denen es unerfahrene Entwickler gibt, die das Feedback benötigen, um ihre Codierungs- und Analysefähigkeiten zu entwickeln, oder bei denen es keine Codierung gibt Mitglieder des Teams, die das Design und den Code verstehen müssen. Ich finde Überprüfungen wesentlich oder sogar obligatorisch, wenn rechtliche Konsequenzen vorliegen oder wenn der Code fehlschlägt (z. B. Flugsteuerungssysteme für Flugzeuge). Ich finde sie überflüssig, wenn ich mit erfahrenen Programmierern zusammenarbeite, bei denen jeder im Team Code produziert, das Projekt klein ist und die Teammitglieder den Code sowieso ständig lesen und kritisieren.

4
Jeff Leonard

Sie müssen akzeptieren, dass Sie die Benutzer nicht dazu bringen können, die Codeüberprüfung zu akzeptieren.

Sie können einen Compiler dazu bringen, das zu tun, was Sie wollen, aber bei Menschen ist das Beste, was Sie anstreben können:

"Wie kann ich einflussreicher sein, wenn ich den Code einer anderen Person überprüfe?"

... und das ist eine ganz andere Frage.

4
Leon Bambrick

Ich denke, das größte Problem bei Codeüberprüfungen ist, dass einige Leute sie nicht richtig machen können. Zum Beispiel spielt es keine Rolle, final vor class/method/parameter/irgendetwas zu setzen und sollte nicht in einer Codeüberprüfung sein. Ein anderes Beispiel ist die Verwendung der falschen Schleife, da nur foreach in Ordnung ist. Benötigen, um alles zu kommentieren. String +/StringBuilder/StringBuffer-Optimierungen. Wenn ich eine Codeüberprüfung mit all diesen Dingen bekommen würde, würde ich denken, dass dieser Typ ein Idiot ist, und wenn ich nicht gezwungen wäre, den Code zu ändern, würde ich das nicht tun.

Manchmal sind Codeüberprüfungstools auch einfach falsch, zum Beispiel Standard PMD (Java) sagt gerne, dass die Klasse zu viele Methoden hat, also habe ich sie erstellt abstrakte Elternklasse und Push einige Methoden dort. Ich hätte die Klasse in zwei Klassen aufteilen können, aber ich denke, dass die API mit all diesen Methoden in einer Klasse einfacher zu verwenden ist (es ist eine kleine Bibliothek und meine Entwurfsentscheidung). Einige Leute verwenden immer nur die Standardeinstellung, daher sollte es nicht beschissen sein.

4
martin

Das 1-3-2-Prinzip gilt hier (ich spreche 1. Person, dann 3. Person, dann 2. - in dieser Reihenfolge).

Erste Priorität ist zu übe was ich predigeDas heißt, ich möchte zuerst sagen, dass ich Codeüberprüfungen benötige (und diese durchführe).

Nur wenn sich die Atmosphäre nicht an Code-Reviews anpasst, sage ich, dass "Leute" Code-Reviews brauchen (und liste die guten Gründe auf).

Erst danach, wenn alles andere fehlschlägt (und ich bin in Autorität :)), lege ich das Gesetz fest und sage "Sie" brauchen Codeüberprüfungen. Dies ist der Teil, den die Leute richtig aufgezählt haben, aber ich zucke nur, wenn die Mentalität der 3. Person nicht die letzte ist. Wenn ich nicht die Faust der ersten Person spreche und nicht praktiziere, was ich predige, bin ich nicht nur ein "ineffektiver" Überreder, sondern auch ein viel größerer Idiot.

ps. Beachten Sie, wie ich das alles in der ersten Person gesagt habe :)

4
Alexander Bird

Um eine andere Perspektive zu bieten, habe ich manchmal festgestellt, dass Codeüberprüfungen zu Dingen führen, die nicht einmal sinnvoll zu diskutieren sind. Als hätte dieser Typ meinen Code überprüft und gesagt, dass ich in einem der Kommentare, die ich dem Code hinzugefügt habe, nicht die richtige Interpunktion (ein Stopp) habe. Während es subjektiv ist, ob so etwas wichtig ist (wenn Sie Inline-Dokumentation schreiben, die beispielsweise in freigegebene Dokumente gezogen wird, könnte dies wichtig sein), war dies in meinem Fall eindeutig nicht der Fall.

Ich denke, Codeüberprüfungen sind obligatorisch. Codeüberprüfungskommentare haben mir fast immer geholfen, und manchmal dauert es ein bisschen, bis ein neues Teammitglied versteht, warum sie wichtig sind. Es ist aber auch wichtig, dass die Objektivität erhalten bleibt, jeder Vorschlag einen objektiven Grund haben sollte und nicht aufgrund subjektiver Präferenzen eines Rezensenten gemacht werden sollte.

Um die Frage zu beantworten: Es ist gut, neue Teammitglieder in einem Stadium, in dem sie wahrscheinlich zuhören, über die Wichtigkeit und den Zweck der Codeüberprüfung zu beraten. Und mit der Erfahrung werden sie lernen, dass es nicht persönlich ist. Es ist auch wichtig, dass die richtigen Leute Rezensenten sind, nicht Leute, die anderen ihre subjektive Meinung aufzwingen.

4
alps123

Überprüfung mit Fragen, nicht mit Befehlen

Ich denke, ein grundlegendes Problem bei Ihrem Überprüfungsprozess ist Ihre Idee, dass Sie irgendetwas in die Kehle zwingen müssen. Stellen Sie stattdessen Fragen wie "Warum haben Sie sich für den X-Ansatz anstelle von Y entschieden?"

Dies lässt sie über ihren eigenen Codierungsprozess nachdenken, anstatt sie zu zwingen, Ihren Codierungsprozess zu akzeptieren. Und hey, vielleicht lernst du auch etwas.

3
Sean

Ich hatte nie die Gelegenheit, an der Codeüberprüfung teilzunehmen, aber ich denke, es ist sicherlich eine ausgezeichnete Praxis.
Damit die Codeüberprüfung gut angenommen wird, können Sie eine Schulung zum Thema "positive Kritik" organisieren.

Übrigens könnte eine solche Schulung auch eine Gelegenheit sein, die Menschen an die Prinzipien der Unternehmens-/Projektentwicklung zu erinnern und Teambuilding zu betreiben.

2
Patrick Honorez

Beginnen Sie zunächst, wie bei allen Problemen, dieses Problem selbst zu lösen. Stellen Sie sicher, dass Sie alles tun, um Codeüberprüfungen so produktiv und nicht konfrontativ wie möglich zu gestalten.

  1. Verwenden Sie keine Codeüberprüfungen, um Best Practices durchzusetzen, wenn Sie eine Automatisierung verwenden können. Halten Sie Standardbibliotheken bereit, um die häufigsten Aufgaben zu erledigen: Verschlüsselung, Datenbankzugriff usw. Verwenden Sie AOP und Richtlinieninjektion, um sich um standardisierte Protokollierung, Überwachung, Sicherheitsbeschränkungen usw. zu kümmern "Übrigens, machen Sie es einfach einfacher. Wir sind faul, also gehen wir einfach den Weg des geringsten Widerstands.
  2. Suchen Sie nicht nach Variablennamen, standardisierten Kommentarblöcken und anderen Details. Wenn der Variablenname nicht schwer zu verstehen ist, ist er in Ordnung. "Konsistenz" ist nur eine Ausrede, um Autorität auszuüben, und jeder kann sie durchschauen.
  3. Lassen Sie nicht den mürrischsten Mann in Ihrer Gruppe die Bewertungen machen. Oder achten Sie darauf, dass keine Personen mit Persönlichkeitskonflikten den Code des anderen überprüfen.
  4. Nehmen Sie bei jeder Codeüberprüfung Snacks und Getränke zu sich. Jeder mag Snacks und Getränke.
2
Chris McCall

Nach meiner Erfahrung hat pair Programmierung weit mehr Vorteile als nur Bewertungen. Es findet nicht nur mehr Fehler, sondern fördert auch kreativere Lösungen, Wissensaustausch, Teambildung und offene Kommunikation und ermöglicht es einem Team, einen natürlichen Programmierstil kontinuierlich zu verfeinern.

Jedes Mal, wenn ich in einem Team war, das Bewertungen ausprobiert hat, wird es konfrontativ und läuft dann aus, wenn sich eine harte Frist abzeichnet.

Es kann für einen erfahrenen Entwickler schwierig sein, sich auf die Idee von Bewertungen einzustellen, aber wenn es klickt, nimmt die Dynamik wirklich zu. Probieren Sie es ein paar Wochen lang aus und sehen Sie, ob es für Sie funktioniert.

1
Eric Nicholson

Versuchen Sie, sie unter dem Aspekt Lernen zu verkaufen. Fast jeder Programmierer, den ich getroffen habe, lernt gerne und ich persönlich habe bei jeder Codeüberprüfung etwas gelernt (ob ich der Prüfer oder der Prüfer war).

Sobald Sie mit den Überprüfungen beginnen, ist es jedoch Ihre Aufgabe, sicherzustellen, dass sie sich lohnen. Lassen Sie sich nicht in kleinen Formatierungsargumenten festfahren (nehmen Sie diese offline). Verwenden Sie statische Analysetools (wie FindBugs für Java), suchen Sie nach TODOs, überprüfen Sie jede Compiler-Warnung, überprüfen Sie die Dokumentation auf Vollständigkeit usw.

Je wertvoller die in der Überprüfung enthaltenen Erkenntnisse sind, desto erfolgreicher werden die Bewertungen sein.

1
Brad Cupit

Codeüberprüfungen sind ein wesentlicher Bestandteil der frühzeitigen Verhinderung einer größeren Katastrophe. Viele der großen Entwicklungsgeschäfte benötigen Codeüberprüfungen für ihre Projekte.

Um das Akzeptieren zu erleichtern, sollten Richtlinien vorhanden sein, denen der Prüfer folgen kann. Wenn die Person das Gefühl hat, herausgegriffen zu werden oder wenn der Rezensent einen Groll haben könnte, zögert sie möglicherweise, eine Rezension durchzugehen. Wenn alle im Voraus über die Richtlinien informiert werden und wissen, wonach der Prüfer suchen wird, haben Sie möglicherweise einen besseren Empfang. Niemand mag Subjektivität, wenn sie sich auf seine Karriere oder Leistung auswirkt.

Aus Erfahrung habe ich mit einer Reihe von Entwicklern an hochkarätigen Regierungsverträgen gearbeitet, bei denen es sich um Anti-Code-Überprüfungen handelte. Woher hat uns das gebracht? Weit hinter dem Zeitplan und weit über dem Budget. Entwickler, die etwas zu verbergen haben, werden sich gegen Menschen wehren, die ihre Arbeit erledigen, da sie sich ihrer Mängel bewusst sind.

Ich habe die Erfahrung gemacht, dass diejenigen, die nicht bereit oder gegen Bewertungen resistent sind, auch dieselben Menschen sind, die nicht bereit sind, zu lernen und ihren Denkstil an das jeweilige Problem anzupassen, was für ein Projekt ein schlüpfriger Hang sein kann, wenn die Person ist in einer Entscheidungsrolle.

Noch etwas zum Nachdenken; Wenn das Budget und das Unternehmen es zur Verfügung stellen können, lassen Sie jemanden, der ausschließlich mit Codeüberprüfungen beauftragt ist, oder bringen Sie sogar jemanden aus einem anderen Projekt mit, um die Überprüfung durchzuführen. Wenn keine vorherige Beziehung besteht, kann dies für beide Parteien einfacher sein.

Wenn alles andere fehlschlägt und Sie besorgt sind, kann die Einstellung der Person Probleme für das gesamte Projekt verursachen, dokumentieren Sie es und eskalieren Sie das Problem auf respektvolle Weise an einen Vorgesetzten. Jemanden zu verfolgen oder auf seine Mängel hinzuweisen, wird für Sie schlecht aussehen und möglicherweise die Aufmerksamkeit auf Ihre eigene Arbeit lenken.

1
Doomspork

Ich war erstaunt, dass noch niemand die agile Praxis namens "The Perfection Game" erwähnt hat, die Teil der Core Protocols ist. Core Protocols schlägt eine Art Codeüberprüfung vor, die für Programmierer leichter zu akzeptieren ist.

Zusammenfassend funktioniert es so:

  • der Programmierer fragt einen potenziellen Rezensenten, ob er ein Perfektionsspiel spielen darf
  • wenn der Prüfer in Ordnung ist, überprüft der Prüfer den Code und gibt einen Wert von 1 bis 10 an, abhängig von dem Wert, von dem er glaubt, dass er zum Code hinzugefügt werden kann (wenn er beispielsweise 1 sagt, kann dies bedeuten, dass dies entweder ein Stück Scheiße ist, aber ich tue es ein bisschen davon nicht zu verstehen, wird keine Hilfe sein, oder es kann bedeuten, dass dies fast perfekt ist, ich könnte es nicht besser machen. Wenn der Rezensent andererseits 10 sagt, würde das bedeuten: Ihr Code ist ein Miststück , aber du hast Glück: Ich kann dir dabei helfen, weil ich ein Experte für diese Art von Mist bin.
  • der Rezensent erklärt im geprüften Code, was ihm gefällt ( und nicht, was er nicht mag )
  • der Programmierer fragt dann, was erforderlich wäre, um diesen Code perfekt zu machen, und der Prüfer erklärt ihn.
  • der Programmierer bedankt sich dann beim Prüfer und ändert gegebenenfalls seinen Code.

Natürlich kann dies wiederholt werden, bis der Programmierer aufhört, nach Perfektion zu suchen, oder der Rezensent nicht mehr helfen kann (er wird eine niedrige Bewertung abgeben und der Programmierer wird dort aufhören).

Dies ist ein bisschen formal, da es aus Kernprotokollen stammt, aber der Programmierer ist immer für die Codeänderungen verantwortlich und bittet um Überprüfung als Dienst. Normalerweise verwendet er diese Art der Überprüfung nicht, um die Verantwortung abzulehnen. Im Gegenteil, der Programmierer sollte einen anderen Prüfer fragen, ob ein bestimmter nicht helfen kann.

Perfection Game trifft möglicherweise nicht auf jeden Fall zu, da es auf freiwilliger Basis funktioniert (ich verstehe die Frage als Frage nach obligatorischen Codeüberprüfungen). Es wurde auch deutlich, dass das Label "Code Review" viele zugrunde liegende unterschiedliche Praktiken abdeckt (in der agilen Welt sind nur Perfection Game und Pair Programming beispielsweise zwei völlig unterschiedliche Arten von Code Reviews).

Einige Übungen sind leichter zu akzeptieren als andere und können auch vom Team und dem einzelnen Programmierer abhängen. Als Nachwort würde ich auch auf die ursprüngliche Frage antworten, indem ich sage, dass Codeüberprüfungen einfacher sind, wenn zwischen den Mitgliedern eines Teams Vertrauen besteht.

Unabhängig von den gewählten Praktiken ist das Vertrauen gegenüber anderen Teamarbeitern sicherlich der Kern der Akzeptanz der Codeüberprüfung durch Programmierer.

0
kriss

Eine weitere Option: Wir führen regelmäßige "Reflexionen" über unseren Prozess mit allen Programmierern eines Projekts durch. Ein Teil dieser Praxis besteht darin, eine "Ursachenanalyse" für die kürzlich aufgetretenen Fehler durchzuführen. Was hat das verursacht? War das eine Regression? War dies ein Mangel an IE6-Tests? Würde es helfen, Joe danach zu fragen? Das Ziel ist herauszufinden, warum wir diese Fehler haben und was wir ändern können, um sie zu verhindern.

Wenn Codeüberprüfungen ein geeignetes Werkzeug sind, wird dies während der Diskussion herauskommen. Und es werden die Programmierer selbst sein, die es vorstellen, und so erhalten Sie von Anfang an viel mehr Buy-In. Wir waren uns einig, dass der gesamte Code vor dem Einchecken überprüft werden muss. Entwickler fragen im Allgemeinen danach, aber wenn sie es vergessen, geben sie es verlegen zu ... sie wissen, dass sie sich nicht nur dem "Management" widersetzen, sondern gegen die Vereinbarung des Teams verstoßen .

(Oder wenn es kein geeignetes Werkzeug ist, können die Leute erklären, warum.)

0
ndp

Ich habe eine andere Situation. Da ich kein sehr erfahrener Entwickler bin, möchte ich vor jeder Veröffentlichung eine Codeüberprüfung für meinen Code durchführen. Aber meistens passt die Codeüberprüfung einfach nicht in unseren engen Zeitplan. Oder meine Firma hält es nicht für wichtig genug, um den Fall zu klären. Gleiches gilt für die testgetriebene Entwicklung. Wenn ich wirklich Fragen habe, greife ich zu einem erfahrenen Entwickler, um meinen Code anzusehen. Nicht ideal, aber dies hilft mir, meine Codierungsfähigkeiten zu verbessern.

0
logoin

Wenn sie keine Codeüberprüfungen durchführen, dann einfach ... entlassen Sie sie einfach. Offensichtlich geht es ihnen sowieso nicht darum, sich zu verbessern. Es ist nicht nötig, totes Gewicht herumzuhalten.

0
Alex Baranosky

Machen Sie die Codeüberprüfung zu einem obligatorischen Bestandteil des Festschreibens von Code an das Mainline-Repository.

Dies ist, was ich von meinem Team tun lasse, und es erhöht die Qualität des Codes und eliminiert fast vollständig die Möglichkeit, dass fragwürdiger Code in die Codebasis gelangt, ohne speziell als "technische Schulden" gekennzeichnet zu sein.

Wir verwenden Git und Gitorious, um unsere Codebasen und Repositorys zu verwalten.

Es gibt ein mainline Repository, das niemand direkt festlegt, sondern von dort zu seinen privaten Klonen auf dem Gitorious-Server zieht.

Die Arbeit und Push werden auf ihren privaten serverseitigen Klon übertragen und führen dann Zusammenführungsanforderungen aus, um zu beantragen, dass ihre Änderungen in die Hauptzeile aufgenommen werden.

Jemand anderes antwortet auf die Zusammenführungsanforderung, vorzugsweise den technischen Leiter des Teams/Projekts, und überprüft den Code der Änderungen, wendet sie an, kompiliert und führt Tests aus und schiebt die Änderungen an, wenn alles in Ordnung ist das mainline Repository und schließt die Zusammenführungsanforderung.

Team/Projekt Technische Leiter haben ihre Zusammenführungsanfragen an eine andere Person im Team beantwortet. Dies ist eine großartige Lernerfahrung für Junior-Mitglieder, wenn kein Peer dafür verfügbar ist.

In beiden Fällen ist jetzt mehr als eine Person am Haken, weil schlechter Code in das Repository mainline Festgeschrieben wird und sich auf den Rest des Teams und das gesamte Unternehmen auswirkt. Wenn ein älteres Mitglied des Teams auf die meisten Zusammenführungsanforderungen reagiert, ist es qualifizierter, schlechte Implementierungen oder Designs zu beheben oder abzulehnen, bevor sie sich auf die gesamte Codebasis auswirken können.

Diese Mini-Code-Überprüfungen sind viel nützlicher als herkömmliche Code-Überprüfungen, die normalerweise Zeitverschwendung sind. Design Reviews sind viel wertvoller, weil eine richtige * Implementierung eines ** schlechten Designs viel schlechter ist als eine schlechte Implementierung eines richtiges Design.

0
user7519