Wie wichtig ist positives Feedback in Code Reviews?

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

Wir führen Überprüfungen mit einem Online-Tool durch, damit 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 Überprüfer kommentieren.

Sollte es ein Gleichgewicht zwischen positivem und negativem Feedback geben?

Verbessern Sie Qualität und Moral mit Peer Code Reviews.
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.

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

Wenn ich Codeprüfungen durchführe, habe ich normalerweise nur einen laufenden Monolog. Wenn ich also verstehe, was ich gerade lese, wird es eine Menge "Ok, ich verstehe, was das bewirkt. Gut, es verbindet sich damit und ruft auf das ist in Ordnung ... und dieses Stück hängt von beiden ab. "

Ich denke auf diese Weise ist es nicht "oo la la das ist so großartig!", Es könnte vollkommen trivialer, langweiliger Code sein, aber jemand anderes zu hören, der das, was du geschrieben hast, parst und zeigt, ist 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 und wenn ich das verstehe, rufe "Ah, ich habe es".

Ich denke, dass eine einfache Weitergabe des Verständnisses an einen anderen Ingenieur ein Lob ist, da wir alle möchten, 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, und schreibe sie nicht als "Wow" 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 ihm innewohnende Güte oder Schlechte.

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

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

"Ich sehe, Sie haben hier einen DI-Container, 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 unter bestimmten Rennbedingungen laufen."

Beachten Sie, dass ich nicht sage, dass etwas gut oder schlecht ist, aber ob der Ingenieur es ändern sollte oder nicht, wird der Ingenieur verstehen, 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 akkumulieren, werden sie gemildert, da bereits Erklärungen in Form von Ursachen- und Wirkungsaussagen abgegeben wurden, wenn Sie ihnen "Ich möchte" mitteilen "Diese magischen Zahlen wurden vor dem Einchecken behoben".

Wenn ich etwas in einer Codeüberprüfung sehen würde, das mir wirklich gut gefällt und über "gut genug" Code hinausgeht, würde ich positives Feedback geben.

Im Allgemeinen denke ich, dass, wenn jemand einen Stückcode schreibt, der Sie tatsächlich sagen lässt: "Wow, das ist wirklich schön!" Ja, positives Feedback ist wichtig - es macht den Autor darauf aufmerksam, dass das, was er getan hat, anderen Spaß gemacht hat, und sie sollten es erneut versuchen. Es muss jedoch mehr als nur das Befolgen von Richtlinien und Standardpraktiken sein. Lob aussprechen, weil jemand nett eingerückt ist oder Kommentare hinzugefügt hat, die die Messlatte ziemlich niedrig legen könnten.

Dies ist weniger eine Programmierfrage als vielmehr eine allgemeine Management- und Mensch-Interaktionsfrage. Positives Feedback in Code Reviews ist genauso wichtig wie positives Feedback in jeder Art von Review.

Ob dies erforderlich ist oder nicht (und inwieweit dies erforderlich ist), hängt von der Disposition und der emotionalen Verfassung der Person ab, mit der Sie sprechen. Manche Menschen reagieren viel effektiver auf Korrekturen, wenn sie mit Lob einhergehen. Andere halten Lob für unaufrichtig, 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 die negative Rückmeldung empfangen wird. Dies kann helfen, Stress bei der Antizipation einer Überprüfung zu vermeiden und ein selbstabsorbierendes Brüten danach zu verhindern. Beides ist sehr wichtig in Bezug auf Produktivität und Qualität. Dies ist nicht nur ein empfindsamer emotionaler Schwachsinn; 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 zum Reagieren bringt.

Ich halte positives Feedback für sehr wichtig und es geht hauptsächlich um eine persönliche, realpolitische 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-Reviews 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 (dh es gibt keine Balance zwischen positivem Feedback), könnte die Besprechung leicht den Titel "Finden Sie heraus, wie schlecht die Leute denken, dass Sie scheißen" haben. Infolgedessen werden Entwickler sich über Code-Reviews ärgern oder diese sogar fürchten, und das ist eindeutig ein Nachteil für das Team. Entwickler "vergessen", ihren Code überprüfen zu lassen, oder entwickeln erlernte Hilflosigkeit und fragen ihre ständigen Kritiker, was sie mit all den Kleinigkeiten tun sollen, um bei diesen Besprechungen nicht in die Knie zu geraten.

Es ist gut und schön 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 sind dafür verantwortlich, dass die Mitarbeiterentwickler als zwischenmenschlich taub empfunden werden. Abgesehen von den Theorien sind wir Menschen und Menschen möchten von Zeit zu Zeit einen Klaps auf den Rücken bekommen, sogar einen nominellen. Das Zeug ist wichtig.

Es ist wichtiger, wenn Sie nebeneinander oder im Team Bewertungen durchführen. In einer schriftlichen Rezension sind keine Neuigkeiten gute Neuigkeiten. 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 für die Betreuung und Verwaltung des Teams verwendet werden. Es gibt viele Möglichkeiten, positives Feedback zu geben, ohne die Datenbank für die Codeüberprüfung zu überfüllen. Beispiele können herausgezogen werden, um sie mit anderen zu teilen.

Das Überprüfen des Entwicklers beinhaltet viel mehr als nur den Code. Das Entführen der Codeüberprüfungszeit kann kontraproduktiv sein, wenn eine App herausgebracht wird. Legen Sie eine bestimmte Zeit fest, um dem Entwickler außerhalb der Codeüberprüfung zu helfen. Dies bedeutet jedoch nicht, dass Sie das Feedback zur Codeüberprüfung ausschließen sollten.

Die einzige Möglichkeit, wie ich mir vorstellen kann, wenn Sie ein positives Feedback zu Code geben, besteht darin, das "Kompliment der Rückhand" nicht zu vermeiden. Die meisten Leute kennen das ... es wird durch Sätze wie "Großartige Arbeit, aber ..." angezeigt.

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

Zumindest, wenn man nicht auf diese Länge 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 übereinstimmt das gleiche Gefühl des Rückhandkompliments. 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."

Der Workflow, der mir bei Codeüberprüfungen am besten gefallen hat, ist 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 begehen Sie." <- POSITIVES FEEDBACK. Jeder akzeptierte Code ist gut. Je weniger Leute dir sagen müssen, dass du Dinge ändern sollst, desto besser machst du es.
5. Dev legt fest, fährt mit dem nächsten Element fort.

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

Die Vorteile dieses Ansatzes sind:

1. Jeder weiß, was jeder tut. Es gibt kein Wissensmonopol oder Mystery Commit.
2. Jeder lernt aus dem Feedback des anderen. Das ist wichtig. Wenn beim Pairing nur zwischen zwei Personen in einem persönlichen Gespräch eine Rückmeldung erfolgt, hat jemand auf der anderen Seite des Raums nicht den gleichen Nutzen wie auf der Mailingliste.
3. Andere Entwickler können in der Regel einige Fehler erkennen, bevor sie sich in der Versionskontrolle befinden.

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

Ich kann mir keine Zeit vorstellen, in der ich jemals Code in einer Rezension gesehen habe, der mich dazu bringen würde, "Oh, das ist cool" zu sagen. Ich kann nur vermuten, dass, wenn ich auf Code wie diesen stoßen würde, dieser in das Lager Cool-Yet-Inacceptable fallen würde.

Sie könnten auch Probleme mit Leuten haben, die kein positives Feedback erhalten und sich möglicherweise zu sehr anstrengen und ein Chaos anrichten "Vertrau mir, es funktioniert!".

Code Reviews dienen dazu, die Verantwortung für die Codequalität im Team zu verteilen, dh 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, für den Fall, dass Sie es jemals warten müssen. Persönlich bin ich mehr an negativen Rückmeldungen interessiert. Kunden interessieren sich nicht für die Coolness Ihres Codes, sondern nur dafür, dass er das tut, was sie wollen.

Überlasse das Backslapping der Kneipe.

Es hat mir etwas ausgemacht. Ich möchte keine Fluff-Kommentare oder Positivität aus Gründen der Positivität. Wenn der ganze Code, den ich geschrieben habe, beschissen ist, sag mir warum und lass es uns korrigieren und lernen. Aber wenn ich etwas richtig mache, ist es schön, es hin und wieder 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 es wichtig.

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

Ich halte es für wichtig, absolut objektiv zu sein. Der Versuch, die Moral durch positive Kommentare zu steigern, ist für mich Zeitverschwendung.

Dies kann bedeuten, dass Codeüberprüfungen übermäßig kritisch sind - ist aber dann nicht der springende Punkt. Wir sollten auch uns selbst gegenüber kritisch sein. Ich stelle fest, dass die Annahme, dass der von mir geschriebene Code wahrscheinlich kompletter Unsinn ist und definitiv verbessert werden könnte, mich veranlasst, meinen Code und meine Fähigkeiten zu verbessern.

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

Mantra ist einfach: Wenn man einen Qualitätscode will (der in der Realität weniger ist), müssen geeignete Überprüfungsmethoden geübt werden. Allerdings hilft positives Feedback einem Entwickler / Programmierer beim Überlegen und Entwickeln von Ideen / Lösungen / Korrekturen. Sei nicht zu hart, aber sei auf dem Punkt fest. Q & A-Manager sollten sich guter Methoden und Praktiken bewusst sein, damit sie das Team (oder ein Mitglied) in die richtige Richtung leiten können. Daraus resultiert Qualität. Zeitraum.

Wenn der Code für einen Wettbewerb bestimmt ist oder für ein Vorstellungsgespräch eingereicht wurde (mit anderen Worten, Code, der geschrieben wurde und nicht umgeschrieben werden kann), sind positive Kommentare ein Muss. In der Tat sollten Sie sicherstellen, dass es sowohl positives (wo möglich!) Als auch negatives Feedback gibt. Auf diese Weise weiß der Codierer, wo seine Stärken und Schwächen liegen, und kann dies ausgleichen.

Sie scheinen jedoch in einer Arbeitsumgebung zu sprechen, in der der Code umgeschrieben werden kann. In diesem Fall versuchen Sie verdammt noch mal, Fehler aus Ihrem System herauszuholen. In dieser Situation sind also nur negative Bugs von Wert.

Wenn Ihnen dies unangenehm ist, veranstalten Sie ein wöchentliches Code-Review-Meeting, bei dem jeder sowohl über guten als auch über schlechten Code diskutieren kann.

EDIT: Obwohl ich sagen werde, dass, wenn Sie etwas genug beeindruckt, nichts Sie daran hindert, Ihr Lob persönlich auszudrücken. Der Tracker scheint jedoch nur zur Überprüfung des Seriencodes gedacht zu sein.