Das Team nimmt meine Codeüberprüfungskommentare nicht ernst

Ihre Einstellung beginnt mich zu nerven und stresst mich fast. Diese Einstellung ist auf allen Ebenen gleich, sei es ein Junior-Entwickler oder ein Senior-Entwickler als ich.

Ich weiß nicht, ob es die Kultur ist oder ob ich eine Frau in einem männlich dominierten Team bin, die die Reibung verursacht.

Für mich scheint dies ein kulturelles Missverhältnis zu sein.

Sie kamen aus einem großen Unternehmen, in dem sich die Leute im Allgemeinen an die Regeln hielten. Sie befinden sich jetzt in einem kleineren, freizügigeren Unternehmen. Und es stört dich.

Ich habe bereits mit meinem Manager (der auch ihr Manager ist) über all dies gesprochen, aber aus seiner Antwort klang für mich, als hätte er keine Kontrolle über sie (er hat ein paar Wochen nach mir angefangen), also ist er relativ neu.

Wenn Sie in meiner Situation wären, was würden Sie tun?

Zuerst würde ich wahrscheinlich darum bitten, aus dem Code-Review-Team entfernt zu werden, da dies der Kern Ihres Stresses zu sein scheint.

Dann würde ich entweder lernen, die Kultur so zu akzeptieren, wie sie ist, während ich immer noch hervorragende Arbeit leiste, oder ich würde ein neues Unternehmen finden (vielleicht ein größeres, strengeres Unternehmen, das formelleren Regeln folgt) und dieses verlassen.

Würdest du deine Einstellung dahingehend ändern, dass es dir egal ist?

Absolut nicht.

Ich habe mich immer gekümmert. Wenn die Kultur um mich herum so wäre, dass ich aufhören müsste, mich zu kümmern, um miteinander auszukommen, bin ich gegangen.

Um die Frage zusammenzufassen, wie sie jetzt lautet:

1. Ich möchte Konsistenz im Code erreichen und dumme Fehler in der Produktion vermeiden
2. Ein Teil meiner Arbeit ist Code-Reviewer
3. Ich muss sie ständig daran erinnern, die vereinbarten Kodexstandards einzuhalten
4. Ich kann die grundlegenden Fehler nicht einfach ignorieren
5. Mein Vorgesetzter hat keine Kontrolle über das Team

Fragen Sie Ihren Vorgesetzten, was genau Ihre Aufgabe ist. Ist es „Code Quality Advocate“ oder „Code Reviewer“? Es ist wahrscheinlich letzteres, also lassen Sie das (3)-Verhalten fallen.

Was ist der Prozess der Codeüberprüfung? Ist es commit->review->comment/accept? Dann tun Sie genau das. Leiten Sie alle Trauer des Teams an Ihren Vorgesetzten weiter. Sie haben Sie mit einer wichtigen Aufgabe beauftragt, Sie scheinen über einen angemessenen Hintergrund zu verfügen. Ihre Aufgabe ist es, Ihnen bei diesen Aufgaben zu helfen.

Es besteht die Möglichkeit, dass Sie Ihre Arbeit nicht sehr gut machen, z. B. hängen Sie an Einrückungen, Namenskonventionen oder etwas anderem, das für den aktuellen Stand des Projekts oder Produkts ungeeignet ist. Aber das ist das Problem, das Ihnen Ihr Vorgesetzter erklären muss. Wenn es schriftliche Dokumente gibt, versuchen Sie, diese in Ihren Kommentaren zu verlinken, und gehen Sie gemeinsam mit dem Vorgesetzten die Richtlinien durch, um herauszufinden, wie Sie Ihre Arbeit besser machen können .

Ein technischer Code-Reviewer erlangt Autorität, indem er im Wesentlichen weise und richtig ist und erklären kann, warum er weise und richtig ist. Nicht durch Managementbefehl.

Sie müssen also Herzen und Köpfe gewinnen.

Als erfahrener Code-Reviewer habe ich eine starke Meinung zu richtig und falsch, wenn es um Code geht. ("Die Hölle ist der Code anderer Leute", um Sartre falsch zu zitieren).

NICHTSDESTOTROTZ:

Ich achte sehr darauf, „Sie müssen das beheben, weil der Code nicht funktioniert“ von „Ich würde einen anderen Stil bevorzugen“ zu unterscheiden (die jeweils in unterschiedlichen Graden der Beharrlichkeit auftreten). Konzentrieren Sie sich auf das, was kaputt ist. Mit der Zeit nehmen Leute freiwillig meine Vorlieben auf - weil sie gut sind, nicht weil ich es sage (ich bin nicht allwissend, ich habe gerade genug Mist erlebt, um Vorschläge zu haben, wie man es vermeiden kann).

„Mach das, weil es der Codierungsstandard ist“ wird niemanden überzeugen. Konsistenz ist eine gute Sache, aber dennoch ist die Begründung für die jeweilige Konvention erforderlich. Andernfalls bedeutet Beständigkeit nur, weiterhin Dinge falsch zu machen, weil Sie sie immer falsch gemacht haben.

Ich kann die grundlegenden Fehler, die in den Reviews gemacht werden, nicht einfach ignorieren und diesen Code in die Produktion gehen lassen.

Dann nicht. Wenn Sie einen Fehler gefunden haben, schreiben Sie ihn als Ticket auf und akzeptieren Sie den Code nicht, bis er behoben wurde. Ich habe Artikel unter Mängeln geschrieben, bis es behoben wurde.

Ich bin nicht in der Position, sie ausdrücklich darum zu bitten

Dann machst du keine Codeüberprüfung.

Wenn Sie nicht ihr Vorgesetzter sind, hört Ihnen niemand zu – es ist ein grundlegendes menschliches Verhalten, auf das die meisten Menschen sogar stolz sind. Vor allem in kleinen Unternehmen. Wie Sie sagten, ignorieren sie sogar Ihren (männlichen) Vorgesetzten. Da muss man sich keinen Stress machen.

Wenn mir jedoch einige Details fehlen und Sie sicher sind, dass Sie aufgrund Ihres Geschlechts diskriminiert wurden, dann haben sie kein Recht, Sie aufgrund Ihres Geschlechts zu stressen, und hier ist das Muster, dem Sie folgen sollten:

1. Erstellen Sie ein Ticket oder eine Dokumentation für den Fehler, den Sie gefunden haben, und dokumentieren Sie, dass er von anderen ignoriert wurde.
2. Dokumentieren Sie dann einen Fehler, der von einem männlichen Entwickler gefunden wurde, und stellen Sie fest, dass er wie gewünscht behoben wurde. (Wenn es mehrere Rezensenten gibt, wie Sie sagten, ist es besser - sammeln Sie die Tickets, die gelöst und ignoriert werden.)
3. Stellen Sie sich Ihrem Vorgesetzten mit dem Ausdruck dieser 2 Beweise und fragen Sie nach dem Grund, warum Ihr Fehler ignoriert wurde und Sie sich anders verhalten haben.

Diskriminierung aufgrund des Geschlechts ist ein ernstes Problem, das nicht auf die leichte Schulter genommen werden sollte. Sie sagten, Sie seien „gestresst“, was bedeutet, dass etwas nicht stimmt – und zögern Sie nicht, das Problem zu eskalieren, bis Sie vollkommen zufrieden sind.

Fragen Sie Ihren Vorgesetzten, was in Code-Reviews von Ihnen erwartet wird (möglicherweise mit einigen anonymisierten Beispielen aus Ihren Reviews), lassen Sie es öffentlich und konkret dokumentieren und folgen Sie dem so gut Sie können. Wenn sie diese Standards weiterhin nicht einhalten, liegt es an Ihrem Vorgesetzten, die Regeln durchzusetzen, nicht an Ihrem Problem.

Wenn Ihre Standards höher sind als die Ihres Vorgesetzten, müssen Sie Ihre Standards lockern. Es ist eine Schande, aber das Wichtigste ist, dass Ihnen das Thema aus den Händen genommen wird. Unklare Erwartungen verursachen bei der Arbeit übermäßigen Stress. Sie sollten Druck auf Ihren Vorgesetzten ausüben, um das Problem zu lösen.

Ich denke, der Fokus darauf, was Ihre Autorität ist und wie Sie die Leute dazu bringen, sich daran zu halten, ist falsch.

Der Zweck der Codeüberprüfung besteht darin, Fehler zu finden und die Codequalität zu verbessern, nicht darin, perfekten Code zu produzieren. Darauf zu bestehen, dass der Code perfekt ist, bevor Sie sich von der Codeüberprüfung abmelden, ist der beste Weg, um schlechte Gefühle zu schüren und eine Pattsituation zu schaffen, in der Sie den Code nicht abmelden und die Entwickler sich weigern, Ihnen zuzuhören.

Code Review ist vor allem ein kollaborativer Teamprozess. Es muss auf eine Weise erfolgen, die die Teamentwicklung und Beziehungen fördert oder zumindest keinen Schaden anrichtet. Sonst haben Sie am Ende ein Team, das sich hasst, und dann wird keine Software entwickelt, guter Code hin oder her. Wenn Sie also Code überprüfen, müssen Sie sich immer zuerst an den Menschen erinnern:

Erhöhen Sie den Code um ein oder zwei Buchstaben, nicht von einem F auf ein A

Leute, die Code in F-Qualität produzieren, tun das nicht absichtlich. Entweder sind sie unerfahren oder wissen es einfach nicht besser. Sie können nicht von einem Junior-Entwickler (oder einem Senior-Entwickler mit lebenslangen schlechten Gewohnheiten) erwarten, dass er all seine Gewohnheiten an einem Tag ändert. Darüber hinaus ist dies ein unvernünftiger Standard, da kein Code jemals wirklich perfekt ist: Selbst Sie machen Fehler und verpassen Dinge. Konzentrieren Sie sich auf zwei oder drei Hauptmängel und beheben Sie diese in Ihrer Codeüberprüfung, sodass der Code von einem F zu einem C wird. Vertrauen Sie darauf, dass Ihre Entwickler mit der Zeit besser werden, und sobald sie C-Level-Code produzieren, können Sie sich Sorgen machen zu einem B oder A gehen.

Binden Sie Feedback an Prinzipien, nicht an Meinungen

Die Leute haben unterschiedliche Meinungen darüber, wie man Code erstellt – das ist in Ordnung. Wenn Sie darauf bestehen, dass Dinge geändert werden, nur weil Sie die Dinge anders gemacht hätten, dann wirkt Ihr Feedback willkürlich und bedeutungslos. Binden Sie das Feedback stattdessen an bestimmte Prinzipien: „Das ist nicht skalierbar“, „Das ist nicht modular“, „Es passiert zu viel in dieser einen Klasse oder Funktion“, „Der Styleguide sagt, es soll so gemacht werden.“

Formulieren Sie Feedback als Anfragen, nicht als Befehle

Du würdest deinem Kollegen nicht sagen, dass er dir einen Kaffee holen soll. Verwenden Sie inklusive Sprache, "Wir sollten hier eine Fehlerprüfung hinzufügen."

Teilen Sie große Rezensionen in kleine Rezensionen auf

Ermutigen Sie Ihre Entwickler, kleine Änderungssätze einzureichen und sie schnell zu überprüfen. Wenn Sie 500 oder 1000 Codezeilen erhalten und eine Woche später mit fünf Seiten voller Änderungen zurückkommen, ist das unglaublich demoralisierend. Wenn Ihre Entwickler wissen, dass kleine Änderungen an diesem Nachmittag oder am nächsten Tag genehmigt werden, erhalten Sie kleine Änderungssätze und Ihr Feedback wird automatisch klein und überschaubar sein.

Halten Sie die Zustimmung nicht wegen trivialer Änderungen auf

Ihre Kollegen sind Profis. Vertrauen Sie auf ihre Professionalität. Wenn Sie nur ein paar Kommentare haben, sagen Sie "X, Y und Z sind geringfügige Änderungen, die die Dinge verbessern würden, aber ich stimme dieser Änderung vorerst zu."

Loben Sie nach Möglichkeit aufrichtig

Aber nur, wenn es wirklich aufrichtig ist. Du willst nicht die Person sein, die nur Schlechtes zu sagen hat. Diese Person sucht nur nach Gründen, andere Leute niederzuschießen. Du möchtest Mentor werden.

Sie versuchen, eine eingebettete Vorgehensweise zu ändern, die wahrscheinlich aufgrund der Anreizstruktur des Unternehmens entstanden ist

Mein Unternehmen hat technisch gesehen Codierungsstandards, Codeüberprüfungen, Dokumentationspläne usw. Ob jemand sie befolgt, hängt davon ab, wie nahe wir dem Ende des Sprints sind. Bis zum Ende der ersten 5 Tage werden Unit-Tests, Code-Reviews und SQLs in ihren Tickets organisiert. Bei der verbleibenden Sprintzeit wird es brenzlig. Fehler im Frontend sind im Allgemeinen von größerer Bedeutung als Fehler im Backend.

Warum das? Die Entscheidungsträger sind nicht technisch versiert und priorisieren im Allgemeinen das, was der Kunde sieht und die Funktionen aus der Tür kommen. Wir haben auch externe Kunden, die wir zufriedenstellen müssen. Ich hatte noch keine formelle Leistungsbeurteilung, aber das Unternehmensziel in Bezug auf Software scheint sehr darin zu bestehen, Funktionen in die Produktion zu bringen. Wir haben alle Arten von älterer Software, die ständige Unterstützung durch Softwareentwickler erfordern, also war dies lange Zeit die Einstellung.

Die Herausforderung besteht darin, dass Dinge wie Codeüberprüfung und -tests keine institutionellen Ziele sind, sondern nur Teamziele und die Institution Vorrang hat.

Unabhängig davon, ob das Management in Ihrem Unternehmen dies erkennt oder nicht, sind es wahrscheinlich diejenigen, die dieses Verhalten fördern, indem sie belohnen, worüber sie sich beschweren und was sie priorisieren.

Es gibt sehr wenig, was Sie dagegen tun können, da Sie hier im Wesentlichen gegen das Management vorgehen.

Ich mag Joes Antwort sehr, aber ich werde auf ein paar sehr alarmierende Anzeichen für mich eingehen.

Ich muss sie ständig daran erinnern, die vereinbarten Code-Standards zu befolgen, Dinge zu dokumentieren und einfach die Verantwortung zu übernehmen.

Wenn Entwickler Codierungsstandards ignorieren, dann nur selten, weil sie schelmisch finster wirken wollen, sondern fast immer, weil die Codierungsstandards für ihren Zweck ungeeignet sind. Was haben Sie getan, um das Problem zu lösen oder zumindest zu versuchen, den Kern des Problems herauszufinden, außer die Leute ständig daran zu erinnern, ihnen zu folgen?

Ich bin nicht in der Lage, sie ausdrücklich darum zu bitten, und daher scheinen sie zu denken, dass ich die Mutter bin, die sie einfach ignorieren können, wenn sie schreit.

Code-Reviews in Teams sind keine Seminare, in denen einer dem anderen sagt, wie es geht. Es ist eine Zusammenarbeit, um eine bessere Qualität zu erreichen, indem eine offene Diskussion zwischen den Personen geführt wird, die an dem Projekt arbeiten. Wenn Sie sich wie eine nörgelnde Mutter verhalten, anstatt sich die Zeit zu nehmen, es zu erklären und mit den anderen Entwicklern einen Konsens zu suchen, warum sollten Sie überrascht sein, dass sie einfach anfangen, Ihr Feedback zu ignorieren?

Wie Sie selbst betonen, sind Sie nicht ihr Chef, Sie sind nur ein weiterer Entwickler, also handeln Sie so und wenn Sie jemanden davon überzeugen wollen, etwas auf Ihre Art zu tun, verwenden Sie Logik, Charme und Vernunft, anstatt den Stock, der Sie nie waren gegeben.

Ich kann die grundlegenden Fehler, die in den Reviews gemacht werden, nicht einfach ignorieren und diesen Code in die Produktion gehen lassen. Ein schlechter Programmierer, aber Senior-Entwickler, kam zu mir, um mich zu bitten, mit Code-Reviews aufzuhören.

Das ist ein Zeichen dafür, dass Sie zumindest teilweise das Problem sind. Ignorieren Sie es nicht, wenn sich ein leitender Mitarbeiter des Teams die Zeit nimmt, Ihnen so ein heftiges Feedback zu geben. Es stimmt eindeutig etwas nicht mit der Art und Weise, wie Sie rüberkommen, zumindest im Kontext dieses Teams.

Ich weiß nicht, ob es die Kultur ist oder ob ich eine Frau in einem männlich dominierten Team bin, die die Reibung verursacht.

Ich weiß nicht, woher du diese Idee überhaupt hast. Nur weil du eine Frau bist, bedeutet das nicht, dass dir deswegen immer wieder weniger als perfekte Interaktionen passieren.

Codequalität spielt keine Rolle. Verkäufe tun. Die Herstellung eines neuen Produkts tut es, weil es den Umsatz ankurbelt. Schreiben Sie den Code hundertmal neu, und Ihre Verkäufe werden nicht steigen.

Wenn Sie diese Idee im Hinterkopf gefeiert haben, müssen Sie auch wissen, dass Codequalität einen Wert hat. Dadurch können neue Produkte schneller entwickelt und Fehler früher behoben werden. Eine gewisse Codequalität ist also nützlich.

Ich argumentiere, dass die Menge an Codequalität so sein sollte, dass die Zeit, die für die Codequalität aufgewendet wurde, etwas weniger war als die Zeit, die beim Hinzufügen neuer Funktionen eingespart wurde (aufgrund der verbesserten Codequalität).

In einem kleinen Unternehmen müssen Sie ein wenig darüber nachdenken, ob Ihre Argumente zur Codequalität dem Wachstum schaden. Einer kleinen, aber schlechten Codebasis können ziemlich schnell Dinge hinzugefügt werden, bis sie einen Punkt erreicht, an dem sie nicht mehr klein ist und Dinge nicht mehr schnell hinzugefügt werden. An diesem Punkt kommt es auf die Codequalität an – denn die Codequalität hat ein eindeutiges Ergebnis (weniger Zeit zum Hinzufügen neuer Dinge).

Aber bis zu diesem Zeitpunkt, während die Codebasis relativ klein ist, trägt die Codequalität nur zu einem marginalen Wert bei. Um Ihre Argumente zur Codequalität vorzubringen, sollten Sie sich überlegen, welche Geschäftsziele/Bugs jetzt und im nächsten Jahr am dringendsten sind, und in diesen Fällen für eine bestimmte Codequalität (Wiederverwendung, Benennung, Klarheit usw.) argumentieren Bereiche. Sie können dies dann Ihrem Vorgesetzten vorlegen - "Hey, die xyz-Komponente wird als das große Ding für unser Produkt angesehen, wir sollten jetzt proaktiv sein, um sie sauber zu halten, damit sie später keine Probleme verursacht".

Sie werden nicht in der Lage sein, überall Codequalität zu erstellen, aber wenn die Idee einsinkt, wird es einfacher zu warten.

Es wird immer schlampigen Code geben (und deshalb sind vollständige Integrationstests so nützlich - weil Sie ihn bereinigen können), aber er kann im Allgemeinen bereinigt werden. Code-Qualitätsargumente sollten im Kontext der Umsatzsteigerung bestehen, ansonsten sind sie rein theoretischer Natur.