Codeüberprüfungen führen häufig zu Kontroversen. Bei der Vorbereitung des Vortrags „Wir lernen von toxischem Verhalten bei der Codeüberprüfung “ auf der AlterConf- Konferenz war ich bereit, eine Reihe von Einwänden und Kritikpunkten zu hören. Aber sie hatte nicht erwartet, dass die Community die Idee so sehr unterstützen würde. Ich nahm Widerstand an, aber die Gemeinde hat mich sehr gut aufgenommen und gebilligt.

Ich wurde gebeten, die Folien zu teilen, aber jetzt dachte ich, dass die Folien selbst wenig nützlich und aus dem Zusammenhang gerissen waren: Es fehlen Erklärungen. Deshalb habe ich beschlossen, diesen Artikel zu veröffentlichen. Später haben die Konferenzorganisatoren ein Video hochgeladen.

Nachfolgend sind einige Arten von unproduktivem Verhalten bei der Codeüberprüfung sowie Empfehlungen aufgeführt, wie der Prozess benutzerfreundlicher gestaltet und Toxizität beseitigt werden kann. Alle Verhaltensmodelle wurden entweder von mir oder in einem mir bekannten Unternehmen getestet. In der Vergangenheit wurden solche Sünden auch zu mir gebracht.

Unproduktives Verhalten Nr. 1: Meinungsäußerung als Tatsache

Geben Sie keine Aussagen ab, wenn Sie sich zur Unterstützung dieser Aussagen nicht auf Dokumentation, formalisierte Empfehlungen und Codebeispiele beziehen können. Die Leute sollten wissen, warum sie aufgefordert werden, Änderungen vorzunehmen, und die persönlichen Vorlieben eines anderen Entwicklers sind kein gutes Argument.

Anstatt zu sagen:

Diese Komponente sollte zustandslos gemacht werden.

... es ist besser, einen Kontext bereitzustellen:

Da diese Komponente keine Lebenszyklus- oder Statusmethoden hat, kann sie zustandslos gemacht werden. Dies verbessert die Codeleistung und Lesbarkeit. * Hier * einige Unterlagen.

Die Übertragung von Meinungen als Tatsache findet sich häufig in Diskussionen über Stil und Syntax. Dies sind wirklich wichtige Themen, jedoch nicht für Codeüberprüfungen, da Stil und Syntax nichts mit dem Problem zu tun haben, das der Entwickler zunächst löst.

Es ist besser, solche Diskussionen separat zu führen und den Stil für das gesamte Team zu bestimmen. Implementieren Sie Linter- und automatische Codekorrekturen . Sie werden dann auf diese Stilempfehlungen verweisen, nicht auf Ihre persönliche Meinung.

Es ist besonders wichtig, Ihre Meinung nicht als Tatsache preiszugeben, wenn Sie einen höheren Rang und eine höhere Autorität in einem Team oder Unternehmen haben. Der Entwickler hat den Eindruck, dass er keine andere Wahl hat, als Ihre Anforderungen gehorsam zu erfüllen.

Unproduktives Verhalten # 2: Lawine von Kommentaren

Wenn eine Person einen Fehler macht, besteht eine gute Chance, dass dieser Fehler an mehreren Stellen auftritt. Mir ist aufgefallen, dass Rezensenten manchmal jeden Fall angeben, anstatt eine detaillierte Notiz mit Links zu nützlichen Ressourcen zu hinterlassen.

Durch die Konsolidierung von Kommentaren können Sie dieselbe Nachricht senden, ohne den Autor zu unterdrücken. Eine Lawine doppelter Kommentare zu einem Thema sieht nach Nitpicking aus.

Unproduktiv und überwältigend:



Mehrere Kommentare für einen wiederkehrenden Fehler (Leerzeichen am Ende der Zeile)

Eine nützlichere Option:


Konsolidiertes Feedback

Ich kann verstehen, dass es manchmal nützlich ist, auf jede Stelle des Fehlers hinzuweisen, da der Kommentar verschwindet, wenn er in nachfolgenden Commits korrigiert wird. Wenn der Fehler jedoch häufig auftritt, ist es offensichtlich, dass dem Entwickler ein bestimmter Leitfaden nicht bekannt war, und er sollte nur auf die richtigen Ressourcen hinweisen.

Unproduktives Verhalten Nummer 3: Bitten Sie die Ingenieure, die Probleme anderer zu lösen, "während sie hier sind".

Bitten Sie die Entwickler nicht, sich mit Problemen zu befassen, die nicht direkt mit den Änderungen oder dem Problem zusammenhängen, das dieser Code zu lösen versucht. Bitten Sie ihn nicht, diesen seltsamen Code zu bereinigen und zu reparieren, selbst wenn ein Entwickler schmutzigen Code mit einer Fülle von schlechten Praktiken erweitert oder ändert.

Ich möchte Entwicklern nicht die Verantwortung für den Code entziehen, nur weil sie ihn ursprünglich nicht geschrieben haben. Tatsächlich ist es nicht gut, etwas wie "Der Code eines anderen ist nicht mein Problem" zu sagen. Es ist nur besser, ein separates Ticket zu erstellen und eine Anforderung zum Beheben von fehlerhaftem Code abzurufen. Auf diese Weise vermeiden Sie einen starken Anstieg des Arbeitsvolumens einer Person und lösen das Problem mit der technischen Verschuldung.

TL; DR : Bitten Sie den Entwickler nicht, die Probleme zu beheben, "während sie hier sind". Wenn der Code die im Ticket erforderlichen Anforderungen erfüllt und keine neuen Probleme in die Codebasis einführt, genehmigen Sie ihn und erstellen Sie ein Ticket, um die Codebasis zu löschen.

Unproduktives Verhalten Nr. 4: Stellen Sie verurteilende Fragen

Vermeiden Sie es, verurteilende Fragen wie diese zu stellen:

Warum hast du hier nicht einfach ____ gemacht?

Dies impliziert, dass eine einfache Lösung offensichtlich sein sollte. Dies zwingt den Entwickler, sich zu verteidigen.

Oft sind diese verurteilenden Fragen einfach verschleierte Forderungen. Bieten Sie stattdessen eine Empfehlung (mit Dokumentation und Links) an und lassen Sie dabei harte Worte weg.

Sie können ____ tun, was den Vorteil von ____ hat.

Unproduktives Verhalten Nr. 5: Sarkasmus

In den Bewertungen ist kein Platz für Sarkasmus. Sarkastische Kommentare bieten in der Regel keinen Kontext und kein effektives Feedback. Beschreiben Sie stattdessen das Problem im Detail und geben Sie Empfehlungen, lassen Sie jedoch ätzende Witze beiseite.

Unproduktiv:

Haben Sie diesen Code vor dem Absenden sogar getestet?

Nützlich

Keine negative Zahl eingegeben. Könnten Sie das bitte tun?

Hier ist ein weiterer Beispielkommentar in einer Codeüberprüfung , der weder lustig noch nützlich ist:

Wir sind nicht böse, wir sind gnadenlos. Wie Sie sehen können, schrieb ich "Piepton!" - Beim Importieren jeder Datei, die Sie berühren. Ich dachte an Folgendes: „Ihr Import verstößt gegen unsere Standardkonvention, die eine bestimmte Reihenfolge voraussetzt: zuerst eingebaute Module, dann Drittanbieter und dann die Projektebene“, aber dieser Satz ist zu lang, um jeweils eingegeben zu werden.

Im obigen Beispiel "Piepton!" - völlig nicht nützlich und nicht sinnvoll. Dies ist pedantischer Humor, der dem Autor nicht hilft.

Unproduktives Verhalten # 6: Emoji anstatt das Problem zu beschreiben

Vermeiden Sie Emoticons mit dem Daumen nach unten oder Emoji mit einem krankmachenden kleinen Mann, wenn Sie auf Probleme im Code hinweisen. Es ist aus den gleichen Gründen so nutzlos wie Sarkasmus. Emoji sind mysteriös und leicht falsch zu interpretieren. Die Leute verschwenden Zeit damit, Ihre Gedanken zu verstehen.


Verwenden Sie keine Emojis, um auf Codierungsprobleme hinzuweisen

In jedem Fall sollten Sie nicht emotional auf Programmierfehler reagieren.

Es ist ganz normal, positive Emoticons wie "Daumen hoch" oder "Prost!" Zu verwenden, aber nicht, um Probleme anzuzeigen, sondern als Antwort auf einen guten Code.


Emoticons zu genehmigen ist großartig

Unproduktives Verhalten Nr. 7: Antworten Sie nicht auf alle Kommentare

Die Autoren tragen auch zur Toxizität der Diskussion bei. Wenn Sie den Code kombinieren, ohne alle Kommentare zu beantworten, ist dies für die Person überraschend: Er hat versucht, Ihnen zu helfen, und Sie machen deutlich, dass einige Bewertungen keine Rolle spielen.

Wenn der Kommentar irrelevant ist oder Sie keine Maßnahmen ergreifen, erklären Sie kurz, warum.

Ignorieren Sie keine Kollegen.


Code kombinieren, ohne auf einen Kommentar zu antworten

Unproduktives Verhalten # 8: Toxisches Verhalten ignorieren, wenn es von Top-Profis kommt

Toxisches Verhalten sollte nicht ignoriert oder unterschätzt werden, nur weil der Entwickler ein ausgezeichneter Fachmann und ein äußerst produktiver Mitarbeiter ist. Obwohl er einen fantastischen Job macht, ist es wichtig zu bedenken, dass sein toxisches Verhalten zu Stress und Burnout bei anderen Entwicklern führt.

Erfahrung mit einer Person, die toxisches Verhalten zeigt:

Andere werden feststellen, dass die Arbeit mit dieser Person erschöpft und demotiviert. Sie werden alles tun, um eine Interaktion mit ihm zu vermeiden, auch wenn dies ihre Fähigkeit, Aufgaben auszuführen, negativ beeinflusst. Die Kommunikation im gesamten Unternehmen wird unterbrochen, und die Mitarbeiter werden an anderen Orten nach Arbeitsplätzen suchen. Während Sie mit den Folgen eines Talentabbaus und erfolgloser Projekte konfrontiert sind, wird dieser Entwickler weiterhin ruhig arbeiten, als wäre nichts passiert. - Joseph Gefro

Wenn keine Schritte unternommen werden, um die Situation zu korrigieren, sind schwerwiegende Konsequenzen möglich: Die Entwickler werden überlastet, angegriffen und demotiviert. Sie werden anfangen, das Feedback zu fürchten, was ihnen tatsächlich helfen sollte, zu wachsen.

Ich persönlich war sehr besorgt, wenn ich eine E-Mail mit Kommentaren zu meiner Pull-Anfrage von einem ehemaligen Kollegen erhielt (bekannt für seine giftigen, nicht hilfreichen Bewertungen). Obwohl toxisches Verhalten jeden unterschiedlich betrifft, profitiert definitiv niemand von dieser Toxizität.

Hinweis : Ich möchte klarstellen, dass der Entwickler, wenn er nicht widerstehen konnte und einmal ein solches Verhalten zeigte, ihn nicht „giftig“ macht. Wir sprechen über wiederholte Beleidigungen und ätzende Kommentare.

Nützliche Methoden zur Codeüberprüfung

Im Folgenden finden Sie einige Empfehlungen, die für jede normale Kommunikation gelten, obwohl wir hier im Zusammenhang mit Programmierung und Codeüberprüfungen sprechen.

Nützliches Verhalten Nr. 1: Verwenden Sie Fragen oder Empfehlungen, um einen Dialog aufzubauen

Bitten Sie niemals Personen, Korrekturen vorzunehmen oder missbilligende Fragen zu stellen, da dies den Dialog zwischen Ihnen und der anderen Person stört.

Warum haben Sie diese Konvertierungen nicht einfach in einer Datei mit Konstanten kombiniert?

Formal ist dies eine Frage, aber es entsteht kein Dialog zwischen Ihnen und dem Gesprächspartner. Er bringt ihn nur dazu, sich zu verteidigen. Fragen Sie stattdessen, was die andere Person von Ihrer Entscheidung hält, zum Beispiel:

Was halten Sie davon, diese Konvertierungen in eine konstante Datei zu ziehen? Es gibt ziemlich viele von ihnen, daher kann eine separate Datei im Moment durchaus sinnvoll sein.

... oder eine Empfehlung aussprechen:

In dieser Datei haben Sie viele Übersetzungsaufrufe für die "Funktion x". Es kann sinnvoll sein, eine separate Datei mit ihren Konstanten zu erstellen.

Nützliches Verhalten Nr. 2: Zusammenarbeiten, nicht verstecken

Wenn Sie zusammen programmieren, müssen Sie da sein, Fragen stellen, diskutieren und auf Ressourcen verweisen.

„… Wenn Sie helfen oder zusammenarbeiten möchten, müssen Sie voll involviert sein und nicht nur manchmal eingreifen“ - Recurse Center Guide

Nützliches Verhalten Nr. 3: Antworten Sie auf jeden Kommentar

Wenn Sie als Autor nicht vorhaben, den Rat eines Rezensenten anzuwenden, machen Sie sich einfach eine Notiz, indem Sie ihn melden. Ignorieren Sie nicht diejenigen, die sich die Zeit nehmen, Ihnen zu helfen.

Zum Beispiel:

Person A: - Was halten Sie davon, eine Hilfsfunktion für diesen API-Aufruf zu erstellen? Ansonsten ist alles in Ordnung.

Person B: - Diese Zeile war nicht Teil meines Änderungssatzes. Ich werde den Code kombinieren, ein separates Ticket auf GitHub erstellen und es in den Arbeitsplan für unsere Gruppe schreiben.

Nützliches Verhalten Nr. 4: Wissen, wann ein persönliches Treffen vereinbart werden muss

Nach Dutzenden von Kommentaren und Lösungsvorschlägen sollte klar sein, dass die Online-Kommunikation für das vorliegende Problem unproduktiv geworden ist. Senden Sie eine Besprechungseinladung an alle beteiligten Kollegen.

Auf diese Weise kann die Gruppe schnell eine Entscheidung treffen und diese anwenden.

Probleme, die Stunden und Tonnen von Kommentaren erfordern, können normalerweise in wenigen Minuten produktiver Konversation gelöst werden. - "Ordentliches Java"

Nützliches Verhalten Nr. 5: Lernmöglichkeiten nutzen und nicht angeben

Fragen Sie sich, bevor Sie an einer Codeüberprüfung teilnehmen:

Hilft Ihnen Ihr Kommentar wirklich beim Lernen oder finden Sie Fehler?

Denken Sie an Ihren Kommentar. Denken Sie daran, dass das Ziel einer Codeüberprüfung darin besteht, anderen Entwicklern das Wachstum beizubringen. Dies ist keine Plattform für Aufführungen.

Nützliches Verhalten Nr. 6: Keine Überraschung zeigen

Achten Sie darauf, keine Überraschung zu zeigen, wenn eine Person etwas nicht weiß. Verärgern Sie die Leute nicht, dass sie diese Informationen bereits kennen sollten. Umgekehrt können Sie zugeben, dass Sie keine Erfahrung mit dem Thema haben - dies ist eine großartige Möglichkeit, um Hilfe zu bitten.

Weitere Informationen finden Sie in der Regel „Nicht überraschen“ im Recurse Center-Lernprogramm.

Nützliches Verhalten Nr. 7: Automatisieren Sie alles, was Sie können

Es ist wenig sinnvoll, Fehler zu diskutieren, die von Lintern, Git-Hooks oder automatisierten Tests abgefangen werden können. Dies ist eine Menge zusätzlicher Kommentare, die wie Nitpicking aussehen. Die Leute sind nicht sehr gut darin, solche Fehler zu identifizieren, und deshalb wurden Automatisierungstools erstellt.

Es gibt auch Tools zum automatischen Ausführen von Tests beim Hinzufügen von neuem Code. Sie zeigen Warnungen an, wenn eine Reihe von Änderungen gegen einen der Tests verstößt. Zum Beispiel TeamCity und Jenkins CI.

Verwenden Sie außerdem Git-Hooks, um Tests und Linters für den neuen Code auszuführen. Sie werden das Commit abfangen, wenn sie Fehler finden.

Lassen Sie das Tool Probleme anzeigen, damit die Leute nicht müssen.

Nützliches Verhalten Nr. 8: Überholen Sie kein toxisches Verhalten

Es ist nicht erforderlich, toxisches Verhalten in Ihre Codeüberprüfung aufzunehmen, da dies für neue Entwickler wie Rache oder ein schikanierendes Ritual aussieht.

Finden Sie Kollegen, die Sie unterstützen.

Wenn Sie unproduktive Codeüberprüfungen bemerken, versuchen Sie es einem Kollegen zu sagen, sprechen Sie direkt und ehrlich (wenn Sie sich in Ihrer Position / Ihrem Unternehmen sicher fühlen).

Nützliches Verhalten Nr. 9: Manager, prüfen Sie Kandidaten sorgfältig, hören Sie dem Team zu und nutzen Sie Ihre Autorität

Manager haben großartige Möglichkeiten, eine positive und günstige Atmosphäre im Team zu schaffen.

Wir formulieren die Tipps aus dem Artikel „Schädlich für giftige Entwickler“ neu :

• Verhindern Sie, dass giftige Entwickler im Team erscheinen. Achten Sie bei der Einstellung nicht nur auf die technische Ausbildung. Finden Sie heraus, wie der Kandidat zusammenarbeitet und kommuniziert. Analysieren Sie kritisch seine Arbeit und sehen Sie, wie er reagiert. Stellen Sie sicher, dass jeder Kandidat die Unternehmenskultur verbessert und nicht nur dazu passt.
  
• Wenn ein giftiger Entwickler noch in den Staat gelangt ist oder geerbt wurde, fragen Sie jeden Mitarbeiter in einem persönlichen Gespräch nach einer Meinung dazu. Wenn der Entwickler giftig ist, wird er in Bewertungen über ihn angezeigt.
  
• Sprechen Sie mit einem giftigen Entwickler. Geben Sie in einer Codeüberprüfung spezifische Beispiele für effektive Kommentare an. Arbeiten Sie kontinuierlich mit ihm zusammen und sammeln Sie weiterhin Informationen in persönlichen Gesprächen mit seinen Kollegen und Vorgesetzten.
  
• Isolieren Sie den giftigen Entwickler nicht. (*)
  
• Wiederholen Sie dies den Mitarbeitern über die Notwendigkeit einer freundlichen Umgebung.

(*) Obwohl der Artikel vorschlägt, toxische Entwickler zu isolieren, halte ich es für wichtig, den toxischen Entwickler zu ermutigen, mit dem Team zusammenzuarbeiten, jedoch auf gesündere Weise. Die Isolierung löst das Problem nicht. Wenn Sie ihm einen separaten Job geben, nimmt die Toxizität kurzfristig ab, aber der Entwickler gibt sein unproduktives Verhalten nicht auf. Er wird nur das Podium verlieren, um es zu demonstrieren.

Nützliches Verhalten Nr. 10: Setzen Sie den Standard, während das Team klein ist und wächst

Kleine Teams können neue Ideen annehmen und umsetzen. Auch wenn Sie es nicht für notwendig halten, Standards zu setzen, da es jetzt keine Probleme gibt, ist es wichtig, gute Kooperationspraktiken beizubehalten, wenn Nachschub eintrifft.

Nützliches Verhalten Nr. 11: Verstehen Sie, dass Sie Teil des Problems sein können

Um ein günstigeres Umfeld zu schaffen, ist es wichtig, ehrlich zu sich selbst zu sein und über ineffektives Verhalten nachzudenken.

Als Junior habe ich mehrmals einen Fehler im Code von jemandem bemerkt und war glücklich, weil ich einen Kommentar hinterlassen konnte! Jetzt verstehe ich, dass ich diese Gelegenheit genutzt habe, um zu prahlen und nicht zu helfen. Sie müssen Ihre Handlungen sorgfältig bewerten.

Ich denke, dass es für jeden nützlich ist, sich die Zeit für diese schwierige Selbstbeobachtung zu nehmen.

Und der letzte ...

Wir sprechen nicht über den Inhalt der Bewertungen, sondern nur über den Ton

Ich weiß, dass Bewertungen wichtig sind und wir nicht dagegen ankämpfen. Ich bitte Sie nicht, die Qualität des Codes zu beeinträchtigen. Die wohlwollende Kultur der Codeüberprüfung und die hohe Qualität des Codes sollten sich nicht gegenseitig ausschließen.

Ich hoffe nur, dass die Leute Schritte unternehmen, um konstruktives, effektives Feedback zu geben und günstigere Bedingungen zu schaffen, unter denen sich Entwickler wohl fühlen, lernen, wachsen und keine Angst vor Fehlern haben. Wir können uns alle gemeinsam verbessern.