it-swarm.com.de

Wie wichtig ist positives Feedback bei Codeüberprüfungen?

Ist es wichtig, während einer Codeüberprüfung auf die gut Teile des Codes hinzuweisen und die Gründe, warum er gut ist? Positives Feedback kann für den zu überprüfenden Entwickler ebenso nützlich sein wie für die anderen, die an der Überprüfung teilnehmen.

Wir führen Überprüfungen mit einem Online-Tool durch, sodass Entwickler Überprüfungen für ihren festgeschriebenen Code öffnen können und andere ihren Code innerhalb eines bestimmten Zeitraums (z. B. 1 Woche) überprüfen können. Andere können den Code oder die Kommentare anderer Prüfer kommentieren.

Sollte es ein Gleichgewicht zwischen positivem und negativem Feedback geben?

47
c_maker

Verbessern Sie Qualität und Moral mithilfe von Peer-Code-Überprüfungen
http://www.slideshare.net/SmartBear_Software/improve-quality-and-morale-using-peer-code-reviews

Dinge, die jeder tun sollte: Code Review
http://scientopia.org/blogs/goodmath/2011/07/06/things-everyone-should-do-code-review/

In beiden Artikeln heißt es, dass einer der Zwecke der Codeüberprüfung darin besteht, Wissen über gute Entwicklungstechniken auszutauschen und nicht nur Fehler zu finden.

Ich würde sagen, es ist sehr wichtig. Wer möchte zu einem Meeting gehen und nur kritisiert werden?

40
Robert Harvey

Wenn ich Code-Reviews mache, neige ich dazu, nur einen laufenden Monolog zu haben. Wenn ich also verstehe, was ich lese, wird es eine Menge "Ok, ich sehe, was das macht. Gut, es verbindet sich damit und ruft an das, in Ordnung ... und dieses Stück hängt von beiden ab, in Ordnung. ".

Ich denke auf diese Weise ist es nicht "oo la la das ist so großartig!", Es könnte ein völlig trivialer, langweiliger Code sein, aber wenn jemand anderes tatsächlich analysiert und versteht, was Sie geschrieben haben, ist dies eine Form von positivem Feedback an und für sich. Das Feedback lautet "Dieser Code macht Sinn". Wenn ich auf Teile stoße, die ich nicht verstehe, bitte ich um Erklärung. Wenn ich es verstehe, rufe "Ah, ich habe es" aus.

Ich denke, dass die einfache Übertragung von Verständnis ein Lob für einen anderen Ingenieur ist, weil wir alle wollen, dass unser Code von anderen verstanden wird. Es gibt eine Form der impliziten Validierung.

Das heißt, wenn Sie Teile des Codes sehen, die gute oder positive Eigenschaften haben (selbst langweiliger trivialer Code kann gut sein, wenn es die minimale Form von sich selbst ist), neige ich definitiv dazu, diese Eigenschaften anzugeben, wieder schreibe ich sie nicht als "Wow" zu groß!" So sehr wie "Ich sehe, dass dies eine minimale Implementierung ist" oder "Ok, dieser komplexe Algorithmus hat viele Kommentare", konzentrieren Sie sich auf die Attribute des Codes, nicht so sehr auf die inhärente Güte oder Schlechtigkeit.

Jedes Mal, wenn Sie dem Code in einer Codeüberprüfung "Güte" oder "Schlechtigkeit" zuschreiben, um zu vermeiden, dass sich der Ingenieur auf ein Podest herabgesehen oder auf einem Podest gehalten fühlt, sagen Sie nicht, dass etwas gut oder schlecht ist, sondern sprechen Sie über Ursache und Wirkung von ihren Code.

"Ok, dieser Teil macht Sinn, ah, hier gibt es eine magische Zahl. Die Bedeutung dieses Wertes wird vom nächsten Ingenieur, der dies berührt, möglicherweise nicht gut verstanden."

"Ich sehe, dass Sie hier einen DI-Container haben, also haben Sie eine lose Kopplung mit diesem Repository."

"Ah, hier gibt es ein statisches Wörterbuch. Wenn mehrere Threads dieses Wörterbuch berühren, könnten wir auf einige Rennbedingungen stoßen."

Beachten Sie, dass ich nicht sage, dass etwas gut oder schlecht ist, aber ob der Ingenieur es ändern sollte oder nicht, wird von dem Ingenieur verstanden, dessen Code überprüft wird. Natürlich müssen Sie die Codeüberprüfung mit einem Ja oder Nein beenden, aber wenn Sie diese Aussagen im Laufe der Zeit ansammeln, werden die Nein-Aussagen weicher, da bereits Erklärungen in Form von Ursache-Wirkungs-Aussagen abgegeben wurden, wenn Sie ihnen sagen: "Ich möchte diese magischen Zahlen wurden vor dem Einchecken festgelegt ".

29
Jimmy Hoffa

Wenn ich in einer Codeüberprüfung etwas sehen würde, das mir sehr gut gefallen hat und über den "gut genug" -Code hinausgeht, würde ich positives Feedback geben.

Im Allgemeinen denke ich, wenn jemand einen Stückcode schreibt, der Sie tatsächlich dazu bringt zu sagen: "Wow, das ist wirklich schön!" dann ja, positives Feedback ist wichtig - es macht den Autor darauf aufmerksam, dass das, was sie getan haben, anderen gefallen hat, und sie sollten versuchen, es erneut zu tun. Es muss jedoch mehr sein als nur das Befolgen von Richtlinien und Standardpraktiken. Lob aussprechen, weil jemand nett eingerückt ist oder Kommentare auf der Kesselplatte hinzugefügt hat, könnte die Messlatte eher niedrig legen.

Dies ist weniger eine Programmierfrage als vielmehr eine allgemeine Management- und Interaktionsfrage. Positives Feedback in Codeüberprüfungen ist genauso wichtig wie positives Feedback in jeder Art von Überprüfung.

Ob dies erforderlich ist oder nicht (und inwieweit dies erforderlich ist), hängt von der Disposition und der emotionalen Zusammensetzung der Person ab, mit der Sie sprechen. Manche Menschen reagieren viel effektiver auf Korrekturen, wenn sie mit Lob verbunden sind. Andere sehen Lob als unaufrichtig an, wenn es mit Korrektur geliefert wird.

Die allgemeine Formel wird manchmal als "Feedback Sandwich" bezeichnet: Gute Sachen zuerst, schlechte Sachen zweitens, gute Sachen zuletzt. Die Idee ist, den Gesamtton positiv zu halten und gleichzeitig sicherzustellen, dass das negative Feedback empfangen wird. Dies kann dazu beitragen, Stress zu vermeiden, wenn eine Überprüfung erwartet wird, und dazu beitragen, ein selbstsüchtiges Grübeln danach zu verhindern. Beides ist sehr wichtig für Produktivität und Qualität. Dies ist nicht nur ein empfindlicher emotionaler Quatsch; Es ist menschliches Verhalten 101.

Auch hier müssen Sie die Person kennen, mit der Sie arbeiten, und verstehen, worauf sie reagiert. Der Umgang mit Menschen ist das, worum es beim Management geht, und gute Manager wissen, wie man Menschen dazu bringt, darauf zu reagieren.

6
tylerl

Ich denke, positives Feedback ist sehr wichtig und stammt hauptsächlich aus einer persönlichen, realpolitischen Dynamik. Wir alle sitzen und schreiben Code für Stunden, Tage, Wochen, Monate, und die meisten von uns sind stolz auf das, was wir tun. Codeüberprüfungen sind eine Chance, dies zu demonstrieren.

Wenn Sie zu einer Codeüberprüfung gehen und das beste Ergebnis, auf das Sie hoffen können, "kein Kommentar" ist (d. H. Es gibt kein ausgewogenes positives Feedback), könnte das Meeting in Outlook leicht den Titel "Finden Sie heraus, wie schlecht die Leute denken, dass Sie saugen" tragen. Infolgedessen werden Entwickler anfangen, sich über Codeüberprüfungen zu ärgern oder diese sogar zu fürchten, und das ist eindeutig ein Nachteil für das Team. Entwickler werden "vergessen", ihren Code überprüfen zu lassen, oder sie werden erlernte Hilflosigkeit entwickeln und einfach ihre ständigen Kritiker fragen, was sie mit jeder Kleinigkeit tun sollen, um nicht in diesen Meetings in die Luft gejagt zu werden.

Es ist schön und gut zu sagen, dass es theoretisch am logischsten ist, das Schlechte zu beheben und alle zu bitten, Emotionen an der Tür zu lassen, aber genau solche Einstellungen, die für die Entwickler von Repräsentanten verantwortlich sind, werden als zwischenmenschlich taub empfunden. Abgesehen von den Theorien sind wir Menschen und Menschen mögen es, von Zeit zu Zeit einen Klaps auf den Rücken zu bekommen, sogar einen nominellen. Das Zeug ist wichtig.

4
Erik Dietrich

Es ist wichtiger, wenn Sie Side-by-Side- oder Team-Reviews durchführen. In einer schriftlichen Bewertung sind keine Nachrichten gute Nachrichten. Ziel ist es, Code in die Produktion zu bringen. Wenn es Ihr Code ist, sollten Sie sich gut fühlen.

Die Codeüberprüfung sollte als Informationsquelle verwendet werden, um das Mentoring und die Verwaltung des Teams zu unterstützen. Es gibt viele Möglichkeiten, positives Feedback zu geben, ohne die Codeüberprüfungsdatenbank zu überladen. Beispiele können herausgezogen werden, um sie mit anderen zu teilen.

Es gibt viel mehr zu tun, um den Entwickler zu überprüfen, als seinen Code. Die Überprüfung der Codeüberprüfungszeit kann kontraproduktiv sein, um eine App auf den Markt zu bringen. Stellen Sie die Zeit ein, die spezifisch für die Unterstützung des Entwicklers außerhalb von Codeüberprüfungen ist. Dies bedeutet jedoch nicht, dass Sie das Feedback zur Codeüberprüfung ausschließen sollten.

3
JeffO

Ich kann mir nur vorstellen, wo ein positives Feedback zu Code nach hinten losgehen könnte, wenn Sie nicht darauf achten, das "Rückhandkompliment" zu vermeiden. Die meisten Leute sind damit vertraut ... es wird durch Sätze wie "Großartige Arbeit, aber ..." bezeichnet.

Wenn jeder zu dem Treffen mit der Einstellung kommt, dass dies keine persönliche Überprüfung des Programmierers ist, sondern eine Bemühung, die Codierungspraxis für die Qualität des gesamten Systems zu verbessern, ist jedes Feedback "gutes" Feedback. Feedback, das Möglichkeiten zur Verbesserung der Codierungspraxis aufzeigt, wird genauso wichtig wie Feedback, das eine nützliche neue Methode zur Behandlung eines Problems hervorhebt.

Zumindest, wenn man nicht so weit geht, sollte betont werden, dass das Streben nach einem Zyklus "gutes Feedback, schlechtes Feedback, gutes Feedback, schlechtes Feedback" innerhalb des Überprüfungsprozesses nur mit dem Problem einhergeht das gleiche Rückhandkomplimentgefühl. Versuchen Sie nicht, gutes Feedback zu erzwingen, gute Anstrengungen zu verstärken und Wissenslücken zu schließen.

Sätze, aus denen ich im Laufe der Jahre am meisten gelernt habe:

  • "Das ist ein interessanter Ansatz. Was passiert, wenn wir [einen anderen Anwendungsfall] berücksichtigen müssen?"
  • "Netter Versuch! Wussten Sie, dass wir bereits eine Methode dafür haben? Vielleicht sollten wir ein Benchmarking durchführen, um herauszufinden, welcher Ansatz effizienter ist."
2

Der Workflow, den ich bei Codeüberprüfungen am meisten mochte, war folgender:

  1. Dev sendet Patch auf Mailingliste/Online-Tool.
  2. Jeder, der sich um den Patch kümmern muss, schlägt Verbesserungen vor.
  3. Dev kehrt zu # 1 zurück
  4. Wenn keine Verbesserung erforderlich ist, sagen die Leute: "Gute Arbeit, bitte verpflichten Sie sich." <- POSITIVES FEEDBACK. Der gesamte akzeptierte Code ist gut. Je weniger Leute dir sagen müssen, dass du etwas ändern sollst, desto besser geht es dir.
  5. Dev legt fest, fährt mit dem nächsten Element fort.

Normalerweise würde es passieren, dass neue Entwickler viel mehr "korrigierendes" Feedback erhalten, wenn sie sich mit der Codebasis vertraut machen.

Die Vorteile dieses Ansatzes sind:

  1. Jeder weiß, was jeder tut. Es gibt kein Wissen, das Monopolisierung oder Rätsel begeht.
  2. Jeder lernt aus dem Feedback des anderen. Das ist wichtig. Wenn während des Pairings nur zwischen zwei Personen in einem persönlichen Gespräch eine Rückmeldung erfolgt, profitiert jemand auf der anderen Seite des Raums nicht auf die gleiche Weise wie auf der Mailingliste.
  3. Andere Entwickler können normalerweise einige Fehler erkennen, bevor sie in der Versionskontrolle sind.
2
MrFox

Dem kann ich überhaupt nicht zustimmen. Was ist der Unterschied zwischen guten Entwicklungstechniken und sogenannten Ninja-Codierern, die großartigen, aber unerklärlichen Code schreiben können? Die Softwareentwicklung ist jetzt (IMO) eine Disziplin mit dem kleinsten gemeinsamen Nenner, in der Flair und List zugunsten von Wartbarkeit und Verständlichkeit gemieden werden. Es ist einfach zu riskant.

Ich kann mir keine Zeit vorstellen, in der ich jemals Code in einer Rezension gesehen habe, die mich dazu bringen würde, "Oh, das ist cool" zu sagen. Ich kann nur davon ausgehen, dass ein solcher Code in das Lager Cool-Yet-Inacceptable fallen würde.

Sie hätten auch Probleme mit Leuten, die kein positives Feedback erhalten, sich vielleicht zu sehr anstrengen und schließlich ein Chaos anrichten. "Vertrau mir, es funktioniert!".

Codeüberprüfungen dienen dazu, die Verantwortung für die Codequalität auf das Team zu verteilen, d. H. Ein einzelner Entwickler kann nicht beschuldigt werden, wenn später ein ernstes Problem auftritt. Verwenden Sie es, um Probleme zu finden, und verwenden Sie es, um Erklärungen vom ursprünglichen Entwickler von seltsamen Dingen zu erhalten, falls Sie es jemals warten müssen. Persönlich bin ich mehr daran interessiert, negatives Feedback zu erhalten. Kunden kümmern sich nicht um die Coolness Ihres Codes, sondern nur darum, dass er das tut, was sie wollen.

Überlassen Sie den Backslapping der Kneipe.

1
James

Es ist mir wichtig. Ich möchte keine Flusenkommentare oder Positivität aus Gründen der Positivität. Wenn der ganze Code, den ich geschrieben habe, beschissen ist, sagst du mir warum und lass es uns korrigieren und lernen. Aber wenn ich etwas richtig mache, ist es schön, es ab und zu zu hören. Ich brauche keine positive Verstärkung für alles, was ich getan habe, was "richtig" war, aber selbst wenn es ein "Lasst uns X, Y und Z verbessern, aber der Rest sieht gut aus" ist, ist es wichtig.

1
peacedog

Nicht annähernd so wichtig wie ehrliches Feedback. Ich arbeite für ein großes Finanzunternehmen, und unseren Kunden ist es egal, ob der Programmierer sich anstrengt oder ein guter Kerl ist oder normalerweise guten Code schreibt! Sie benötigen Software, die funktioniert.

0
aserwin

Ich denke, es ist wichtig, völlig objektiv zu sein. Der Versuch, die Moral durch positive Kommentare zu verbessern, ist für mich Zeitverschwendung.

Dies kann bedeuten, dass Codeüberprüfungen übermäßig kritisch sind - aber das ist dann nicht der Punkt. Wir sollten uns selbst gegenüber kritisch sein. Ich finde, dass die Annahme, dass der Code, den ich geschrieben habe, wahrscheinlich völliger Müll ist und definitiv verbessert werden könnte, mich dazu veranlasst, meinen Code und mein Können zu verbessern.

Wenn Sie keine Kommentare erhalten, können Sie davon ausgehen, dass Sie gute Arbeit geleistet haben.

0
user619818