Wie gehe ich mit jemandem um, der die Idee der Codeüberprüfung nicht mag?

Wenn das Management Zeit mit Code-Reviews verbringen möchte, muss dies natürlich jeder tun.

Aber es gibt immer die Jungs (oder Mädels), die sich mit jedem Gramm ihres Seins widersetzen.

Wie schaffen Sie es effektiv, mit diesem Szenario umzugehen, wenn Sie als Peer-Reviewer damit umgehen?

Er wehrt sich aus Angst . Diese Konditionierung kann das Ergebnis früherer schlechter Erfahrungen sein, als Kind, in der Schule, bei der Arbeit oder sogar in Ihrem derzeitigen Team überprüft zu werden. In unseren modernen Gesellschaften ist es sehr verbreitet, die Arbeitsergebnisse eines Menschen mit seinem Wert als Mensch zu verwechseln. Das ist der Grund, warum Bewertungen bei der Arbeit nicht gut aufgenommen werden. Das ist auch der Grund, warum in der Öffentlichkeit in einer der am weitesten verbreiteten Phobien gesprochen wird (Angst vor dem Urteil).

Um ein solches Verhalten zu vermeiden, benötigen Sie etwas Psychologie. Sie müssen seinem Echsengehirn beweisen, dass es nicht passieren wird (er wird nicht beurteilt, gedemütigt, getötet, irgendetwas ...), indem Sie ihn für Code-Überprüfungen desensibilisieren .

Eine der effektivsten Methoden, die ich gefunden habe, um jemanden zu entsperren, besteht darin , ihn zu bitten, Ihren Code zu überprüfen , bevor er ihn auffordert, seinen Code zu überprüfen.

Schlagen Sie ihm nach einer Weile vor , seinen Code zu lesen, um daraus zu lernen, und warum nicht Verbesserungen vorschlagen . Wenn Sie etwas zu ändern finden, achten Sie darauf, was Sie schreiben. Er wird verstehen, dass es nichts gibt, wovor er sich fürchten muss, und er wird nur den positiven Teil des Überprüfungsprozesses übernehmen: lernen und sein Wissen erweitern .

Ich würde versuchen, in Paaren zu arbeiten - Team jemand, der die Idee hasst, mit jemandem, der es mag, und lassen Sie sie für ein paar Wochen den Code des anderen überprüfen. Offensichtlich kann dies helfen oder auch nicht, aber wenn Sie sich an beiden Enden der Überprüfung befinden, erhalten Sie zumindest einen umfassenderen Überblick über den Prozess. Wenn ein Paar zusammenarbeitet, können sie sich mit dem Stil und den häufigsten Fehlern des anderen vertraut machen und haben Zeit, sich gegenseitig dabei zu helfen, besser zu werden, anstatt sich gegenseitig den Stempel aufzudrücken. Dies kann Ihnen auch dabei helfen, die Paarbildung in Ihrer Arbeitsumgebung voranzutreiben, da Sie möglicherweise die Tendenz sehen, nicht nur zu überprüfen, sondern auch neu zu codieren oder sogar von Grund auf neu zu planen und zu codieren.

Solange die desinteressierten Parteien bereit sind, es zu versuchen, könnte dies helfen. Wenn sie sich weigern, darüber nachzudenken, können Sie nicht viel tun, solange sie im Team sind.

Die Antwort von @ Pierre ist genau richtig für jemanden, der eine Codeüberprüfung fürchtet. Ich kann mir eine andere Situation vorstellen. Ein Star-Programmierer, der eine Codeüberprüfung empfindet, ist Zeitverschwendung, da dort ein akzeptabler Qualitäts- und Korrektheitsstandard erreicht wird. In diesem Fall könnte eine Codeüberprüfung eine Zeitverschwendung und eine Hexenjagd sein. (Das ist eine Suche nach einem Problem, wenn es keines gibt.)

In diesem Fall würde ich das Ziel der Überprüfung neu ausrichten. Bei der Codeüberprüfung geht es nicht darum, "Probleme" im Code zu finden, sondern darum, nach Re-Factoring-Zielen, möglichen zukünftigen Verbesserungen oder zusätzlichen Design-Features zu suchen. Auf diese Weise sind sowohl der Codierer als auch der Prüfer in den Prozess involviert, und hoffentlich fühlt sich dieser fähige Codierer an, als würde die Zeit sinnvoll genutzt.

Ehrlich gesagt macht diese Frage keinen Sinn, wenn Sie einen gut geführten Shop haben:

1) Wenn es Teil des Jobs ist, müssen Sie es tun, oder Sie sind unhöflich. Jemand, der sich strikt weigert, einen Teil der Arbeit zu verrichten, die er zu erledigen hat, sollte konserviert werden. Programmieren ist ein Handwerk und ein Beruf - Prüfer und Manager sind da, um die Arbeit zu erledigen, und nicht um verwöhnte Kinder (jeden Alters).

2) Wenn Sie über ein gut verwaltetes Quellcodeverwaltungssystem verfügen (ein Muss in jedem professionellen Softwarehaus), kann der Code überprüft werden, ob er Ihnen gefällt oder nicht. So überprüfen Sie ihren Code:

• Wenn es gut ist, benachrichtige sie und klopfe ihnen auf den Rücken - das wird zur Teilnahme anregen.

• Wenn es nicht gut ist, lass es sie auch wissen. Dies soll sie zur Teilnahme motivieren, um sich zu verteidigen. Wenn dies nicht der Fall ist, können Sie Strafmaßnahmen ergreifen: Finanzielle Sanktionen, Herabstufungen des Status usw. Wenn dieser Mitarbeiter trotz Ihrer Bemühungen nicht vorbeikommt, haben Sie IMO einen schlechten Mitarbeiter, dem die Tür gezeigt werden sollte.

Haben sie einige negative Erfahrungen an Orten, an denen Codeüberprüfungen nicht ordnungsgemäß durchgeführt wurden? Sie können berechtigte Bedenken haben.

Wenn sie absolut keinen Nutzen für die Übung sehen, bitten Sie sie, geduldig zu sein und zu sehen, was mit ihrem Code und insbesondere mit dem Code anderer geschieht (wenn sie der Meinung sind, dass er perfekt ist).

Code Review "sollte" die Entwicklung verbessern, aber bis Sie ein System haben, das tatsächlich funktioniert, warum sollte es jemand tun wollen?

Ich persönlich bin der Meinung, dass es einige Kämpfe gibt, die mit 100% der Bevölkerung einfach nicht zu gewinnen sind.

Ich kann genug Gründe sehen, warum die Paarprogrammierung nicht funktioniert, wenn jemand dazu gezwungen wird.

Aber Code Reviews sind anders - sie ändern Ihre Produktivität, nicht unbedingt Ihre Arbeitsgewohnheiten.

Das Management kann verschiedene Maßnahmen ergreifen, um den Widerstand aufgrund der Produktivität zu verringern: 1) Akzeptieren Sie die Geschwindigkeitsreduzierung für alle Entwickler. 2) Bereitstellung geeigneter Tools für die Verwaltung und Zusammenführung mehrerer Versionen aufgrund von Überprüfungszyklen (z. B. Bereitstellung eines lokalen Git-Repositorys für Entwickler) von Bewertungen.

Wenn sie das tun, ist es legitim, jeden zur Teilnahme zu verpflichten, IMHO. Das Unternehmen, für das ich jetzt weltweit arbeite, ist ohne die Zustimmung eines Eigentümers einfach nicht einzureichen. Und während dies die Dinge verlangsamt, verhindert es viele Unfälle.

Wir haben technische Maßnahmen ergriffen, um die Überprüfung des Codes zu erzwingen.

Die Art und Weise, wie wir die Codeüberprüfung eingeführt haben, ist, dass es in unserer Quellcodeverwaltung unmöglich ist, Code zusammenzuführen, der nicht von jemand anderem signiert wurde, als demjenigen, der ihn gepusht hat.

Feuern Sie sie ab

So einfach ist das - entweder bekommen sie ein Einzelprojekt oder sie müssen gehen. Holen Sie sie von Ihrem Team weg. Sie leisten nicht nur keinen Beitrag, sie untergraben auch die Moral und die Praktiken des Teams.

Nun, wenn es scheint, dass Sie 50% Ihres Teams feuern müssen, dann ...

Verstehen

Warum lehnen manche ab? Haben sie keine zeit Sind sie ausgebrannt? Gibt es Rezensionen zu etwas, mit dem sie keine Erfahrung haben? Halten sie es für Zeitverschwendung, wenn ja, warum?

Hier hilft eine agile Methodik - ich gehe davon aus, dass Sie ständig gegen Silos vorgehen (dh, um den Busfaktor zu reduzieren), und Einzelpersonen in Ihrem Team sind an dem beteiligt, was andere tun.

Der Aufwand, um sicherzustellen, dass einzelne Zusammenführungsanforderungen relativ gering sind. Wenn es sich um mehr als einen Bildschirm mit Änderungen handelt, ist ein Stand-up- oder Blitzgespräch erforderlich, um zu erklären, was getan wird. Bei 10 Seiten ist eine Präsentation mit Folien und Architekturdiagrammen erforderlich.

Arbeiten alle Beteiligten am selben Projekt?

Ist das Projekt bereits unter einem Berg technischer Schulden begraben?

Glauben sie an das Projekt und die kontinuierliche Verbesserung?