it-swarm.com.de

Wie finde ich positive Dinge in einer Codeüberprüfung?

Nach einigen schwerwiegenden Qualitätsproblemen im letzten Jahr hat mein Unternehmen kürzlich Codeüberprüfungen eingeführt. Der Codeüberprüfungsprozess wurde schnell eingeführt, ohne Richtlinien oder Checklisten.

Ein anderer Entwickler und ich wurden ausgewählt, um alle an den Systemen vorgenommenen Änderungen zu überprüfen, bevor sie in den Trunk integriert werden.

Wir wurden auch als "Technischer Leiter" ausgewählt. Dies bedeutet, dass wir für die Codequalität verantwortlich sind, aber keine Berechtigung haben, Änderungen im Prozess zu implementieren, Entwickler neu zuzuweisen oder Projekte zurückzuhalten.

Technisch können wir die Zusammenführung ablehnen und sie der Entwicklung zurückgeben. In Wirklichkeit endet dies fast immer damit, dass unser Chef verlangt, dass es pünktlich geliefert wird.

Unser Manager ist ein MBA, der sich hauptsächlich mit der Erstellung eines Zeitplans für anstehende Projekte befasst. Während er es versucht, hat er fast keine Ahnung, was unsere Software aus geschäftlicher Sicht tut, und hat Schwierigkeiten, selbst die grundlegendsten Kundenanforderungen ohne Erklärung eines Entwicklers zu verstehen.

Derzeit erfolgt die Entwicklung in Entwicklungsniederlassungen in SVN. Nachdem der Entwickler glaubt, bereit zu sein, weist er das Ticket in unserem Ticketsystem unserem Manager neu zu. Der Manager weist es uns dann zu.

Die Codeüberprüfungen haben zu Spannungen in unserem Team geführt. Besonders einige der älteren Mitglieder stellen die Änderungen in Frage (d. H. "Wir haben es immer so gemacht" oder "Warum sollte die Methode einen vernünftigen Namen haben, ich weiß, was sie tut?").

Nach den ersten Wochen begann meine Kollegin, die Dinge laufen zu lassen, um keine Probleme mit den Mitarbeitern zu verursachen (sie sagte mir selbst, dass sie nach Einreichung eines Fehlerberichts durch einen Kunden von dem Fehler wusste, aber befürchtete, dass der Entwickler wäre sauer auf sie, wenn sie darauf hinweist).

Andererseits bin ich jetzt dafür bekannt, ein Arsch zu sein, der auf Probleme mit dem festgeschriebenen Code hinweist.

Ich denke nicht, dass meine Standards zu hoch sind.

Meine Checkliste im Moment ist:

  • Der Code wird kompiliert.
  • Es gibt mindestens eine Möglichkeit, wie der Code funktioniert.
  • Der Code funktioniert in den meisten normalen Fällen.
  • Der Code funktioniert mit den meisten Edge-Fällen.
  • Der Code löst eine angemessene Ausnahme aus, wenn eingefügte Daten ungültig sind.

Aber ich übernehme die Verantwortung für die Art und Weise, wie ich Feedback gebe. Ich gebe bereits umsetzbare Punkte, die erklären, warum etwas geändert werden sollte, und manchmal sogar nur die Frage, warum etwas auf eine bestimmte Weise implementiert wurde. Wenn ich es für schlecht halte, weise ich darauf hin, dass ich es anders entwickelt hätte.

Was mir fehlt, ist die Fähigkeit, etwas zu finden, das als "gut" bezeichnet werden kann. Ich habe gelesen, dass man versuchen sollte, schlechte Nachrichten in gute Nachrichten zu stecken.

Aber es fällt mir schwer, etwas Gutes zu finden. "Hey, diesmal hast du tatsächlich alles begangen, was du getan hast" ist herablassender als nett oder hilfreich.

Beispiel für eine Codeüberprüfung

Hallo Joe,

Ich habe einige Fragen zu Ihren Änderungen in der Library\ACME\ExtractOrderMail-Klasse.

Ich habe nicht verstanden, warum Sie "TempFilesToDelete" als statisch markiert haben. Im Moment würde ein zweiter Aufruf von "GetMails" eine Ausnahme auslösen, da Sie Dateien hinzufügen, diese aber niemals entfernen, nachdem Sie sie gelöscht haben. Ich weiß, dass die Funktion nur einmal pro Lauf aufgerufen wird, aber in Zukunft könnte sich dies ändern. Könnten Sie es einfach zu einer Instanzvariablen machen, dann könnten wir mehrere Objekte parallel haben.

... (Einige andere Punkte, die nicht funktionieren)

Kleinere Punkte:

  • Warum nimmt "GetErrorMailBody" eine Ausnahme als Parameter? Habe ich etwas verpasst? Sie lösen die Ausnahme nicht aus, sondern geben sie einfach weiter und rufen "ToString" auf. Warum ist das so?
  • SaveAndSend ist kein guter Name für die Methode. Diese Methode sendet Fehler-Mails, wenn die Verarbeitung einer Mail fehlgeschlagen ist. Könnten Sie es in "SendErrorMail" oder ähnliches umbenennen?
  • Bitte kommentieren Sie nicht nur alten Code, sondern löschen Sie ihn sofort. Wir haben es immer noch in Subversion.
190
RobMMurdock

Wie finde ich positive Dinge in einer Codeüberprüfung?

Nach einigen schwerwiegenden Qualitätsproblemen im letzten Jahr hat mein Unternehmen kürzlich Codeüberprüfungen eingeführt.

Großartig, Sie haben eine echte Chance, Wert für Ihr Unternehmen zu schaffen.

Nach den ersten Wochen begann meine Kollegin, die Dinge laufen zu lassen, um keine Probleme mit den Mitarbeitern zu verursachen (sie sagte mir selbst, dass sie nach Einreichung eines Fehlerberichts durch einen Kunden von dem Fehler wusste, aber befürchtete, dass der Entwickler wäre sauer auf sie, wenn sie darauf hinweist).

Ihre Mitarbeiterin sollte keine Codeüberprüfung durchführen, wenn sie Entwicklern nicht mitteilen kann, was mit ihrem Code nicht stimmt. Es ist Ihre Aufgabe Probleme zu finden und zu beheben vorher sie betreffen Kunden.

Ebenso bittet ein Entwickler, der Mitarbeiter einschüchtert, entlassen zu werden. Ich habe mich nach einer Codeüberprüfung eingeschüchtert gefühlt - ich habe es meinem Chef gesagt, und es wurde gehandhabt. Außerdem mag ich meinen Job, also habe ich das positive und negative Feedback beibehalten. Als Rezensent liegt das an mir, nicht an jemand anderem.

Andererseits bin ich jetzt dafür bekannt, ein Arsch zu sein, der auf Probleme mit dem festgeschriebenen Code hinweist.

Nun, das ist bedauerlich, du sagst, du bist taktvoll. Sie können mehr zu loben finden, wenn Sie mehr suchen müssen.

Kritisieren Sie den Code, nicht den Autor

Sie geben ein Beispiel:

Ich habe einige Fragen zu Ihren Änderungen in

Vermeiden Sie es, stattdessen die Wörter "Sie" und "Ihr" zu verwenden, sagen Sie "die" Änderungen.

Habe ich etwas verpasst? [...] Warum ist das so?

Fügen Sie Ihrer Kritik keine rhetorischen Schnörkel hinzu. Mach auch keine Witze. Ich habe eine Regel gehört: "Wenn Sie sich gut fühlen, sagen Sie es nicht, es ist nicht gut."

Vielleicht polierst du dein eigenes Ego auf Kosten eines anderen. Halten Sie es nur auf die Fakten.

Erhöhen Sie die Messlatte durch positives Feedback

Es legt die Messlatte höher, Ihre Entwicklerkollegen zu loben, wenn sie höhere Standards erfüllen. Das bedeutet also die Frage:

Wie finde ich positive Dinge in einer Codeüberprüfung?

ist gut und es lohnt sich, darauf einzugehen.

Sie können darauf hinweisen, wo der Code den Idealen höherer Codierungspraktiken entspricht.

Suchen Sie nach ihnen, um Best Practices zu befolgen und die Messlatte immer höher zu legen. Nachdem die einfacheren Ideale von allen erwartet werden, sollten Sie aufhören, diese zu loben, und nach noch besseren Codierungspraktiken für Lob suchen.

Sprachspezifische Best Practices

Wenn die Sprache Dokumentation in Code, Namespaces, objektorientierten oder funktionalen Programmierfunktionen unterstützt, können Sie diese aufrufen und dem Autor gegebenenfalls zur Verwendung gratulieren. Diese Angelegenheiten fallen normalerweise unter Style-Guides:

  • Entspricht es den internen Standards für Sprachstilrichtlinien?
  • Entspricht es dem maßgeblichsten Styleguide für die Sprache (der wahrscheinlich strenger als der interne Stil ist - und somit immer noch dem internen Stil entspricht)?

Allgemeine Best Practices

Unter verschiedenen Paradigmen finden Sie Punkte, die Sie für generische Codierungsprinzipien loben sollten. Haben sie zum Beispiel gute Unittests? Decken die Unittests den größten Teil des Codes ab?

Suchen:

  • unit-Tests, die nur die Funktionalität des Probanden testen - verspotten teure Funktionen, die nicht getestet werden sollen.
  • hohe Codeabdeckung mit vollständigem Testen von APIs und semantisch öffentlichen Funktionen.
  • abnahmetests und Rauchtests, die End-to-End-Funktionen testen, einschließlich Funktionen, die für Unit-Tests verspottet werden.
  • gute Benennung, kanonische Datenpunkte, daher ist der Code DRY (Wiederholen Sie sich nicht)), keine magischen Zeichenfolgen oder Zahlen.
  • die Benennung von Variablen ist so gut gelungen, dass Kommentare weitgehend überflüssig sind.
  • bereinigungen, objektive Verbesserungen (ohne Kompromisse) und geeignete Umgestaltungen, die Codezeilen und technische Schulden reduzieren, ohne den Code den ursprünglichen Autoren völlig fremd zu machen.

Funktionale Programmierung

Wenn die Sprache funktional ist oder das funktionale Paradigma unterstützt, suchen Sie nach folgenden Idealen:

  • vermeidung von globalen und globalen Staaten
  • mit Verschlüssen und Teilfunktionen
  • kleine Funktionen mit lesbaren, korrekten und beschreibenden Namen
  • einzelne Austrittspunkte, wodurch die Anzahl der Argumente minimiert wird

Objektorientierte Programmierung (OOP)

Wenn die Sprache OOP unterstützt, können Sie die angemessene Verwendung dieser Funktionen loben:

  • kapselung - Bietet eine sauber definierte und kleine öffentliche Schnittstelle und verbirgt die Details.
  • vererbung - Code wird angemessen wiederverwendet, möglicherweise durch Mixins.
  • polymorphismus - Schnittstellen sind definierte, möglicherweise abstrakte Basisklassen, Funktionen, die zur Unterstützung des parametrischen Polymorphismus geschrieben wurden.

unter OOP gibt es auch SOLIDE Prinzipien (möglicherweise Redundanz zu OOP Funktionen):

  • einzelverantwortung - Jedes Objekt hat einen Stakeholder/Eigentümer
  • offen/geschlossen - die Schnittstelle etablierter Objekte wird nicht geändert
  • Liskov-Substitution - Unterklassen können Instanzen von Eltern ersetzen
  • schnittstellentrennung - Schnittstellen, die durch die Zusammensetzung bereitgestellt werden, möglicherweise Mixins
  • abhängigkeitsinversion - definierte Schnittstellen - Polymorphismus ...

Unix-Programmierung Prinzipien :

Unix-Prinzipien sind Modularität, Klarheit, Zusammensetzung, Trennung, Einfachheit, Sparsamkeit, Transparenz, Robustheit, Repräsentation, geringste Überraschung, Stille, Reparatur, Wirtschaftlichkeit, Generierung, Optimierung, Vielfalt und Erweiterbarkeit.

Im Allgemeinen können diese Prinzipien unter vielen Paradigmen angewendet werden.

Ihre Kriterien

Diese sind viel zu trivial - ich würde mich herablassen, wenn ich dafür gelobt würde:

  • Der Code wird kompiliert.
  • Es gibt mindestens eine Möglichkeit, wie der Code funktioniert.
  • Der Code funktioniert in den meisten normalen Fällen.

Auf der anderen Seite sind diese ziemlich hoch gelobt, wenn man bedenkt, womit Sie es zu tun scheinen, und ich würde nicht zögern, Entwickler dafür zu loben:

  • Der Code funktioniert mit den meisten Edge-Fällen.
  • Der Code löst eine angemessene Ausnahme aus, wenn eingefügte Daten ungültig sind.

Regeln für das Bestehen der Codeüberprüfung aufschreiben?

Theoretisch ist das eine großartige Idee. Obwohl ich Code normalerweise nicht wegen schlechter Benennung ablehnen würde, habe ich eine so schlechte Benennung gesehen, dass ich den Code mit Anweisungen zur Behebung ablehnen würde. Sie müssen in der Lage sein, den Code aus irgendeinem Grund abzulehnen.

Die einzige Regel, die ich mir vorstellen kann, um Code abzulehnen, ist, dass nichts so ungeheuerlich ist, dass ich es aus der Produktion heraushalten würde. Ein wirklich schlechter Name ist etwas, das ich gerne aus der Produktion heraushalten würde - aber das kann man nicht zur Regel machen.

Fazit

Sie können Best Practices loben, die unter mehreren Paradigmen befolgt werden, und wahrscheinlich unter allen, wenn die Sprache sie unterstützt.

124
Aaron Hall

Wählen Sie nichts Gutes aus, es sei denn, es ist ein solides, prägnantes Beispiel und steht in direktem Zusammenhang mit dem fokussierten Thema.

Ich werde es nicht beschönigen - nach den Geräuschen haben Sie es mit mindestens einer Person zu tun, die mit ihren Fähigkeiten unsicher ist und unreif damit umgeht, über ihre Arbeit herausgefordert zu werden. Sie sind wahrscheinlich auch schlecht in ihrer Arbeit - ein guter Entwickler sollte immer bereit sein, sich selbst zu reflektieren, konstruktive Kritik zu üben und offen dafür zu sein, ihre Verhaltensweisen zu ändern.

Jetzt, wo das in der Luft liegt, können wir über Sie sprechen. Unabhängig davon, ob Sie denken, dass Sie vernünftig sind, müssen Sie mit solchen Leuten besonders vorsichtig sein, um den Ball ins Rollen zu bringen. Ich habe herausgefunden, dass der beste Weg, mit diesen Menschen umzugehen, darin besteht, sehr vorsichtig damit umzugehen, wie Sie Dinge formulieren.

Stellen Sie sicher, dass Sie den Code und nicht den Autor beschuldigen. Konzentrieren Sie sich eher auf das eine Problem als auf den Poo-Mountain, der Ihre Codebasis darstellt, an dessen Erstellung sie möglicherweise maßgeblich beteiligt waren und der als weiterer persönlicher Angriff angesehen wird. Wählen Sie Ihre Schlachten zunächst aus und konzentrieren Sie sich auf kritische Themen, die sich für Ihre Benutzer manifestieren, damit Sie nicht die ganze Person kritisieren, die sie dazu bringt, alles, was Sie sagen, abzulehnen.

Körpersprache und Ton sind wichtig, wenn Sie persönlich mit ihnen sprechen, klar sagen, was Sie sagen, und sicherstellen, dass Sie nicht mit ihnen sprechen oder ihre technischen Fähigkeiten ablehnen. Sie werden höchstwahrscheinlich sofort in der Defensive sein, also müssen Sie ihre Sorgen regeln, anstatt sie zu bestätigen. Sie müssen sich dieses Gesprächs bewusst sein, ohne zu offensichtlich zu sein, damit sie unbewusst glauben, Sie seien auf ihrer Seite, und hoffentlich akzeptieren sie, dass sie die Änderungen vornehmen müssen, auf die aufmerksam gemacht wurde.

Wenn dies nicht funktioniert, können Sie etwas aggressiver werden. Wenn das Produkt von einem Konferenzraum aus ausgeführt werden kann, rufen Sie es während der Codeüberprüfung auf dem Projektor auf und zeigen Sie den Fehler aus erster Hand. Es ist besser, wenn ein Manager genau dort ist, damit die Person nicht zurücktreten kann. Dies soll sie nicht beschämen, sondern sie zwingen zu akzeptieren, dass das Problem für den Benutzer real ist und behoben werden muss, anstatt nur einen Kritikpunkt an ihrem Code zu haben.

Wenn Sie nicht weiterkommen, es satt haben, die Person wie einen Kindergartenschüler zu behandeln, ist sich das Management des Problems überhaupt nicht bewusst, und es spiegelt entweder Ihre Leistung als Code-Prüfer schlecht wider oder Sie kümmern sich um das Wohlergehen Ihrer Person Unternehmen und/oder Produkt müssen Sie mit Ihrem Chef über deren Verhalten sprechen. Seien Sie so spezifisch und unpersönlich wie möglich - machen Sie ein Geschäftsmodell, bei dem Produktivität und Qualität darunter leiden.

105
plast1k

Codeüberprüfungen können giftig, zeitraubend und lebensnotwendig sein. Schauen Sie sich nur die Meinungsverschiedenheiten in Bezug auf Dinge wie sauberen Code und Kommentare, Namenskonventionen, Unit- und Integrationstests, Check-in-Strategien, RESTfulness usw. usw. an.

Die einzige Möglichkeit, dies zu vermeiden, besteht darin, die Regeln für das Bestehen einer Codeüberprüfung aufzuschreiben.

Dann ist es keine Person, die das Einchecken nicht besteht oder genehmigt. Sie überprüfen lediglich, ob die Regeln eingehalten wurden.

Und weil sie im Voraus aufgeschrieben werden, können Sie beim Schreiben Ihres Codes die Regeln befolgen und müssen Ihre Argumentation nicht erklären oder später Argumente haben.

Wenn Ihnen die Regeln nicht gefallen, haben Sie eine Besprechung, um sie zu ändern.

95
Ewan

Ich würde Ihr Feedback nicht beschönigen, da es als bevormundend angesehen werden kann.

Meiner Meinung nach ist es die beste Vorgehensweise, sich immer auf den Code und niemals auf den Autor zu konzentrieren.

Es ist eine Code Bewertung, keine Entwickler Bewertung, also:

  • "Diese while-Schleife wird möglicherweise nie beendet", nicht "Ihre Schleife wird möglicherweise nie beendet"
  • "Für Szenario X wird ein Testfall benötigt", nicht "Sie haben den Test nicht geschrieben, um dieses Szenario abzudecken".

Es ist auch sehr wichtig, dieselbe Regel anzuwenden, wenn Sie mit anderen über die Überprüfung sprechen:

  • "Anne, was denkst du über diesen Code?", Nicht "Anne, was denkst du über Jons Code?"

Die Codeüberprüfung ist nicht die Zeit für eine Leistungsüberprüfung - sie sollte separat durchgeführt werden.

25
tymtam

Ich bin überrascht, dass es bisher in keiner Antwort erwähnt wurde, und vielleicht ist meine Erfahrung mit Codeüberprüfungen ungewöhnlich, aber:

Warum überprüfen Sie die gesamte Zusammenführungsanforderung in einer einzelnen Nachricht?

Meine Erfahrung mit Codeüberprüfungen erfolgt über GitLab. Ich habe mir immer vorgestellt, dass andere Tools zur Codeüberprüfung ähnlich funktionieren würden.

Wenn ich eine Codeüberprüfung gebe, kommentiere ich spezifische, einzelne Zeilen des Diff. Es ist äußerst unwahrscheinlich, dass dies als persönliche Kritik aufgenommen wird , da es sich um einen Kommentar zum Code handelt - und tatsächlich angezeigt wird als Kommentar zum Code, direkt unter dem Code, zu dem es sich um einen Kommentar handelt.

Ich kann auch die gesamte Zusammenführungsanforderung kommentieren und tue dies häufig. Auf bestimmte Punkte des Diff können jedoch bestimmte Punkte hingewiesen werden. (Wenn ein neues Commit hinzugefügt wird, sodass sich das Diff ändert, werden die Kommentare zum "veralteten Diff" standardmäßig ausgeblendet.)

Mit diesem Workflow werden Codeüberprüfungen viel modularer und weniger zusammenhängend. Eine Zeile aus einer Codeüberprüfung kann einfach sagen:

Netter Ansatz, der dies in eine spezielle Funktion einwickelt!

Oder es könnte sagen,

Dieser Objektname entspricht nicht wirklich dem Zweck des Objekts. Vielleicht könnten wir stattdessen einen Namen wie 'XYZ' verwenden?

Oder wenn es große Probleme mit einem Abschnitt gibt, könnte ich schreiben:

Ich sehe, dass dieser Code funktioniert (und ich sehe warum es funktioniert) Aber es erfordert ein gezieltes Studium, um es zu verstehen. Könnten Sie es bitte in separate Funktionen umgestalten, damit es in Zukunft einfacher zu warten ist?

(Beispiel: Funktion ABC macht hier tatsächlich drei Dinge: das foo bazzing, das boz sperren und das zorf frippen. Das können alles separate Funktionen sein.)

Nachdem ich alle oben genannten Punkte geschrieben habe, kann ich einen zusammenfassenden Kommentar zur gesamten Zusammenführungsanforderung abgeben, etwa:

Dies ist eine großartige neue Funktion, die nach dem Zusammenführen sehr nützlich sein wird. Können Sie bitte die Funktionsbezeichnung bereinigen und das in den einzelnen Kommentaren erwähnte Refactoring durchführen und mich dann wissen lassen, ob ich es mir noch einmal ansehen soll? :) :)


Auch wenn es sich bei der Zusammenführungsanforderung um ein komplettes Hundefrühstück handelt Die einzelnen Kommentare können jeweils einfach sein. Es wird einfach mehr davon geben. Dann könnte der zusammenfassende Kommentar sagen:

Es tut mir leid, aber dieser Code entspricht nicht wirklich dem Schnupftabak. Es gibt sehr viele Edge-Fälle (wie in einzelnen Kommentaren beschrieben), die falsch behandelt werden und eine schlechte Benutzererfahrung oder in einem Fall sogar Datenbeschädigung verursachen. (Siehe Kommentar zu Commit 438a95fb734.) Selbst einige normale Anwendungsfälle führen zu einer extrem schlechten Anwendungsleistung (Einzelheiten in einzelnen Kommentaren zum Diff für somefile.c).

Um produktionsbereit zu sein, muss diese Funktion vollständig neu geschrieben werden, wobei stärker darauf zu achten ist, welche Annahmen an jedem Punkt des Ablaufs sicher getroffen werden können. (Hinweis: Keine Annahmen sind sicher, wenn sie nicht überprüft wurden.)

Ich schließe die Zusammenführungsanforderung, bis eine vollständige Neufassung vorliegt.


Zusammenfassung : Überprüfen Sie die technischen Aspekte des Codes als Kommentare zu einzelnen Codezeilen. Dann fasse diese Kommentare in einem Gesamtkommentar zur Zusammenführungsanforderung zusammen. Werden Sie nicht persönlich - beschäftigen Sie sich nur mit den Fakten und Ihrer Meinung nach mit dem Code , nicht mit dem Codierer. Und stützen Sie Ihre Meinung auf Fakten, genaue Beobachtung und Verständnis.

15
Wildcard

Ich bin wirklich überrascht, dass niemand das aufgegriffen hat, aber mit der veröffentlichten Beispielbewertung stimmt etwas nicht.

Es gibt einfach keinen Grund, sich direkt an Joe zu wenden. Dass Joe seine Fehler behebt, geht Sie nichts an. Das jemand tut, ist deine Sache. Ihr Anliegen ist die Codequalität. Also, anstatt Anfragen/Befehle/Forderungen zu schreiben (die ich, wenn ich Joe wäre, einfach ablehnen könnte, weil Sie dafür nicht legitim sind), bleiben Sie in Ihrer Rolle und schreiben Sie eine einfache anonyme Aufgabenliste.

Der Versuch, faire und schlechte Punkte zu geben, ist nicht nur unmöglich, sondern liegt völlig außerhalb Ihrer Rolle.

Hier ein Beispiel für eine Neuformulierung mit Inhalten aus Ihrer Bewertung:

  • Bevor wir Änderungen in der Library\ACME\ExtractOrderMail-Klasse vornehmen, müssen wir einige Probleme beheben.
  • Sofern ich nichts verpasst habe, sollte "TempFilesToDelete" nicht statisch sein.
  • In Zukunft können wir die Funktion mehr als einmal pro Lauf aufrufen, deshalb brauchen wir (was hier zu tun ist).
  • Ich muss verstehen, warum "GetErrorMailBody" eine Ausnahme als Parameter akzeptiert. (und ich bin hier grenzwertig, weil du jetzt schon eine Schlussfolgerung haben solltest)
  • SaveAndSend sollte umbenannt werden, um besser zu seinem Verhalten zu passen, wie zum Beispiel "SendErrorMail".
  • Auskommentierter Code sollte aus Gründen der Lesbarkeit gelöscht werden. Wir verwenden Subversion für eventuelle Rollbacks.

Wenn Sie die Rezension so formulieren, egal wie sehr der Leser Sie persönlich hasst, kann er hier nur Hinweise zu Verbesserungen sehen, die jemand später fortsetzen muss. WHO ? Wann ? Niemanden interessierts. Was? Warum ? DAS solltest du sagen.

Jetzt werden Sie genau den Grund ansprechen, warum Codeüberprüfungen die Spannung erhöhen, indem Sie den menschlichen Faktor aus der Gleichung herausnehmen.

12
Arthur Havlicek

Bei der Codeüberprüfung geht es darum, Probleme zu finden. Wenn der Fehler any vorliegt, können Sie am besten einen fehlgeschlagenen Testfall schreiben.

Ihr Team (Manager) sollte mitteilen, dass das Produzieren von Fehlern Teil des Spiels ist, aber das Finden und Beheben von Fehlern spart jedermanns Job.

Es kann hilfreich sein, regelmäßige Besprechungen (entweder Team oder Paar) abzuhalten und einige der Probleme durchzugehen. Der ursprüngliche Programmierer hat nicht absichtlich Probleme eingeführt, und manchmal könnte er denken, dass es gut genug ist (und manchmal sogar). Aber dieses zweite Augenpaar zu haben, gibt eine völlig neue Sicht, und er könnte viel lernen, wenn er sich die Probleme ansieht.

Es ist wirklich eine kulturelle Sache und es braucht viel Vertrauen und Kommunikation. Und Zeit, mit den Ergebnissen zu arbeiten.

8
Eiko

Ich denke, das Positive wäre, vor der Überprüfung einen Konsens über die Kodierungsstandards zu erzielen. Andere neigen dazu, sich mehr für etwas einzukaufen, wenn sie Input haben.

Fragen Sie andere nach Namenskonventionen, ob dies wichtig ist. Die meisten Entwickler werden besonders unter ihren Kollegen zustimmen. Wer möchte die Person sein, die nicht mit etwas übereinstimmen möchte, das in der Programmierwelt so verbreitet ist? Wenn Sie den Prozess starten, indem Sie den Code einer Person auswählen und auf den Fehler hinweisen, wird diese Person sehr defensiv. Wenn Standards festgelegt sind, wird es Meinungsverschiedenheiten über die Interpretation oder das geben, was als "gut genug" angesehen wird, aber Sie sind besser dran als jetzt.

Ein weiterer Teil dieses Prozesses besteht darin, zu bestimmen, wie Codeüberprüfungen mit Einwänden umgehen. Dies kann keine endlose Debatte werden. Irgendwann muss jemand die Entscheidung treffen. Vielleicht kann es einen Dritten geben, der der Richter ist, oder der Rezensent erhält die ganze Macht. Sachen, die erledigt werden müssen, sollten das Ziel sein.

Das letzte Stück davon ist, alle wissen zu lassen, dass Code Reviews nicht Ihre Idee waren, sie werden bleiben, also sollte sich jeder bemühen, das Beste daraus zu machen. Wenn sich jeder machtlos fühlt, kann er vielleicht Ihren Code überprüfen?

Hoffentlich besteht ein messbares Ergebnis für das Management darin, Fehler, Kundenbeschwerden, Verzögerungen usw. zu begrenzen. Andernfalls hat jemand gerade das Schlagwort "Codeüberprüfung" gehört und herausgefunden, dass Wunder ohne viel Zeit und Energie geschehen, wenn er es nur zu Ihrem Prozess hinzufügt und Mühe in diese.

6
JeffO

Dies mag hart sein, aber machen Sie sich keine Sorgen über ein gutes Feedback, wenn es nichts Gutes zu messen gibt.

Wenn Ihre Entwickler jedoch in Zukunft beginnen, ihren Code zu verbessern, möchten Sie ihnen ein gutes Feedback geben. Sie möchten auf die Verbesserungen im Code hinweisen und auf die Vorteile für das gesamte Team hinweisen. Wenn Sie anfangen, Verbesserungen zu sehen, werden sie dies auch tun, und die Dinge sollten langsam beginnen, sich zu entwickeln.

Etwas anderes; Es kann eine defensive Atmosphäre geben, weil sie das Gefühl haben, kein Mitspracherecht zu haben. Warum lassen Sie sie nicht den Code des anderen überprüfen? Stellen Sie ihnen spezifische Fragen und versuchen Sie, sie einzubeziehen. Du solltest nicht gegen sie sein; Es sollte eine Teamleistung sein.

  1. Was würden Sie an diesem Code ändern, wenn Sie Zeit hätten?
  2. Wie würden Sie diesen Bereich der Codebasis verbessern?

Fragen Sie das jetzt und fragen Sie das in sechs Monaten. Hier gibt es eine Lernerfahrung.

Der Hauptpunkt - loben Sie den Code nicht, wenn dies nicht gerechtfertigt ist, sondern erkennen Sie den Aufwand und erkennen Sie definitiv Verbesserungen. Versuchen Sie, Bewertungen zu einer Teamübung zu machen, anstatt zu einer gegnerischen.

4
lunchmeat317

Qualität ohne Spannung

Sie haben gefragt, wie Sie positive Aussagen zu Code finden können, aber Ihre eigentliche Frage ist, wie Sie "Spannungen in [Ihrem] Team" vermeiden und gleichzeitig "ernsthafte Qualitätsprobleme" angehen können.

Der alte Trick, „schlechte Nachrichten in gute Nachrichten“ zu stecken, kann nach hinten losgehen. Entwickler werden es wahrscheinlich als das sehen, was es ist: eine Erfindung.

Top-Down-Probleme Ihrer Organisation

Ihre Chefs haben Sie beauftragt, die Qualität sicherzustellen. Sie haben eine Liste mit Kriterien für die Codequalität erstellt. Jetzt möchten Sie Ihrem Team Ideen für eine positive Verstärkung geben.

Warum fragen Sie uns, was Sie tun müssen, um Ihr Team glücklich zu machen? Haben Sie darüber nachgedacht, Ihr Team zu fragen?

Es hört sich so an, als würden Sie Ihr Bestes geben, um nett zu sein. Das Problem ist nicht, wie Sie Ihre Nachricht übermitteln. Das Problem ist, dass die Kommunikation in eine Richtung erfolgt ist.

Aufbau einer Kultur der Qualität

Eine Kultur der Qualität muss gepflegt werden, um von unten nach oben zu wachsen.

Lassen Sie Ihren Chef wissen, dass Sie besorgt sind, dass sich die Qualität nicht schnell genug verbessert, und Sie möchten versuchen, einige Ratschläge von The Harvard Business Review anzuwenden.

Treffen Sie sich mit Ihrem Team. Modellieren Sie die Verhaltensweisen, die Sie in Ihrem Team sehen möchten: Demut, Respekt und die Verpflichtung zur Verbesserung.

Sagen Sie etwas wie: "Wie Sie wissen, wurden [Mitarbeiter] und ich beauftragt, die Codequalität sicherzustellen, um die Art von Produktionsproblemen zu vermeiden, unter denen wir in letzter Zeit gelitten haben. Ich persönlich glaube nicht, dass ich dieses Problem gelöst habe. Ich denke, mein größter Fehler war, dass ich Sie am Anfang nicht mehr involviert habe. [Mitarbeiter] und ich sind immer noch rechenschaftspflichtig gegenüber dem Management für Codequalität, aber in Zukunft sind wir alle gemeinsam in der Qualitätsanstrengung. “

Holen Sie sich vom Team Ideen zur Codequalität. (Ein Whiteboard würde helfen.) Stellen Sie sicher, dass Ihre Anforderungen bis zum Ende erfüllt sind. Bieten Sie Ihre Erkenntnisse auf respektvolle Weise an und stellen Sie gegebenenfalls Fragen. Seien Sie bereit, überrascht zu sein, was Ihr Team für wichtig hält. Seien Sie flexibel, ohne die Geschäftsanforderungen zu beeinträchtigen.

(Wenn Sie einen alten Code haben, der Ihnen peinlich ist, können Sie ihn ausprobieren und alle dazu ermutigen, offen zu sein. Lassen Sie die Leute am Ende wissen, dass Sie ihn geschrieben haben. Modellieren Sie die ausgereifte Reaktion, auf die Sie hoffen, wenn andere Baukritik erhalten. )

Kollaborative Codeüberprüfungen

Ich habe nicht an einem Ort gearbeitet, wie Sie ihn beschrieben haben, an dem einige erfahrene Programmierer den gesamten Code überprüfen und Korrekturen vornehmen. Kein Wunder, dass die Leute antworten, als wären Sie ein Lehrer, der rote Markierungen auf ihren Papieren macht.

Wenn Sie die Idee an das Management verkaufen können, beginnen Sie mit Peer-Code-Überprüfungen . Dies geschieht am besten in kleinen Gruppen, einschließlich Ihnen oder dem anderen verantwortlichen Entwickler. Stellen Sie sicher, dass jeder mit Respekt behandelt wird.

Ein wichtiges Ziel der Peer-Review-Code ist es, sicherzustellen, dass der Code von allen Mitgliedern des Teams verstanden werden kann. Betrachten Sie Ihr Beispiel für unklare Funktionsnamen: Wenn Sie von einem jüngeren Entwickler hören, dass der Funktionsname verwirrend ist, kann dies leichter akzeptiert werden als eine andere „Korrektur“ des älteren Entwicklers.

Qualität ist eine Reise

Eine andere Sache, die zu tun ist, ist, jede Vorstellung zu verwerfen, dass eine Codeüberprüfung eine Art Pass/Fail-Sache ist. Jeder sollte damit rechnen, nach einer Codeüberprüfung einige Änderungen vorzunehmen. (Und Ihre Aufgabe ist es, sicherzustellen, dass sie passieren.)

Aber wenn das nicht funktioniert ...

Nehmen wir an, Sie machen einige Fortschritte beim Aufbau einer Qualitätskultur. Möglicherweise bringen Sie immer noch nicht alle an Bord. Wenn jemand immer noch nicht mit dem Qualitätsprogramm beschäftigt ist, besteht das Problem jetzt darin, dass er nicht in das Team passt, anstatt dass es ein Problem zwischen Ihnen beiden gibt. Wenn sie aus dem Team entlassen werden müssen, wird der Rest des Teams die Gründe besser verstehen.

4
Tim Grant

Entschuldigen Sie die weitere lange Antwort, aber ich glaube nicht, dass die anderen das menschliche Element dieses Problems vollständig angesprochen haben.

manchmal sogar nur fragen, warum etwas auf eine bestimmte Weise implementiert wurde. Wenn ich es für schlecht halte, weise ich darauf hin, dass ich es anders entwickelt hätte.

Das Problem mit "Warum haben Sie es so implementiert?" ist, dass Sie den Entwickler sofort in die Defensive bringen. Die Frage selbst kann je nach Kontext alle möglichen Dinge implizieren: Sind Sie zu dumm, um sich eine bessere Lösung auszudenken? Ist das das Beste, was du tun kannst? Versuchen Sie dieses Projekt zu ruinieren? Interessiert Sie überhaupt die Qualität Ihrer Arbeit? usw. Die Frage, warum der Code auf eine bestimmte Weise entwickelt wurde, wird nur konfrontativ sein, und dies untergräbt jede pädagogische Absicht, die Ihr Kommentar möglicherweise hatte.

In ähnlicher Weise ist "Ich hätte das anders gemacht ..." auch konfrontativ, weil der unmittelbare Gedanke, den der Entwickler haben wird, " ist. Nun, ich habe es so gemacht ... Hast du ein Problem damit? "Und wieder ist es konfrontativer als es sein muss und dreht die Diskussion um weg von der Verbesserung des Codes.

Beispiel:

Anstatt zu fragen, warum Sie die Konstantenvariable für diesen Wert nicht verwendet haben, geben Sie einfach an: "Dieser fest codierte Wert sollte durch die Konstante XYZ in der Datei Constants.h Ersetzt werden." Die Frage legt nahe, dass der Entwickler aktiv nicht gewählt hat, um die bereits definierte Konstante zu verwenden, aber es ist durchaus möglich, dass er nicht einmal wusste, dass sie existiert. Mit einer ausreichend großen Codebasis wird es eine Menge Dinge geben, die jeder Entwickler nicht weiß. Dies ist einfach eine gute Lernmöglichkeit für diesen Entwickler, um sich mit den Konstanten des Projekts vertraut zu machen.

Es gibt eine feine Linie, um mit Code-Überprüfungen zu gehen: Sie müssen nicht alles, was Sie sagen, mit Zucker überziehen, Sie müssen keine schlechten Nachrichten mit guten Nachrichten verbinden und Sie müssen den Schlag nicht mildern. Es könnte die Kultur sein, in der ich mich befinde, aber meine Mitarbeiter und ich machen uns bei Codeüberprüfungen nie ein Kompliment - die Teile des Codes, die wir entwickeln und die fehlerfrei sind, sind ein Kompliment genug. Was Sie tun müssen, ist, den Fehler zu identifizieren, den Sie sehen, und vielleicht einen Grund dafür anzugeben (das Warum ist weniger nützlich, wenn es offensichtlich/einfach ist).

Gut:

  • "Der Name dieser Variablen muss geändert werden, um unserem Codierungsstandard zu entsprechen."

  • "Das 'b' in diesem Funktionsnamen muss groß geschrieben werden, um PascalCase zu sein."

  • "Der Code dieser Funktion wird nicht richtig eingerückt."

  • "Dieser Code ist ein Duplikat des Codes in ABC::XYZ() und sollte stattdessen diese Funktion verwenden."

  • "Sie sollten try-with-resources verwenden, damit die Dinge in dieser Funktion garantiert ordnungsgemäß geschlossen werden, auch wenn Fehler auftreten." [Ich habe hier nur einen Link hinzugefügt, damit Nicht-Java-Benutzer wissen, was Try-with-Resources bedeutet.]

  • "Diese Funktion muss überarbeitet werden, um unsere n-Pfad-Komplexitätsstandards zu erfüllen."

Schlecht:

  • "Ich denke , Sie könnten diesen Code verbessern, indem Sie den Variablennamen so ändern, dass er unserem Standard entspricht."

  • " Vielleicht wäre es besser, try-with-resource zu verwenden, um die Dinge in dieser Funktion richtig zu schließen."

  • "Es könnte wünschenswert sein , alle Bedingungen in dieser Funktion noch einmal genauer zu betrachten. Die Komplexität des N-Pfades liegt über der maximal zulässigen Komplexität unseres Standards."

  • "Warum sind die Einrückungen hier 2 Leerzeichen anstelle der 4 unseres Standards?"

  • "Warum haben Sie eine Funktion geschrieben, die unseren n-Pfad-Komplexitätsstandard verletzt?"

In den schlechten Aussagen sind die kursiv geschriebenen Teile Dinge, die Menschen normalerweise verwenden, wenn sie den Schlag mildern möchten, aber alles, was sie bei einer Codeüberprüfung wirklich tun, ist, dass Sie sich unsicher klingen. Wenn Sie als Prüfer nicht sicher sind, wie Sie den Code verbessern können, warum sollte Ihnen dann jemand zuhören?

Die 'guten' Aussagen sind unverblümt, aber sie beschuldigen den Entwickler nicht, sie greifen den Entwickler nicht an, sie sind nicht konfrontativ und sie hinterfragen nicht, warum der Fehler vorliegt. Es existiert; Hier ist die Lösung. Sie sind sicherlich nicht so konfrontativ wie diese letzte "Warum" -Frage.

4
Shaz

Das Problem, das Sie sehen, ist: Entwickler sind unglücklich darüber, dass ihr Code kritisiert wird. Das ist aber nicht das Problem. Das Problem ist, dass ihr Code nicht gut ist (vorausgesetzt offensichtlich, dass Ihre Codeüberprüfungen gut sind).

Wenn die Entwickler nicht möchten, dass ihr Code Kritik hervorruft, ist die Lösung einfach: Schreiben Sie besseren Code. Sie sagen, Sie hatten ernsthafte Probleme mit der Codequalität. Das bedeutet, dass besserer Code benötigt wird.

"Warum sollte die Methode einen vernünftigen Namen haben, ich weiß was sie tut?" ist etwas, das mich besonders stört. Er weiß, was es tut, oder zumindest sagt er es, aber ich nicht. Jede Methode sollte nicht nur einen vernünftigen Namen haben, sondern auch einen Namen, der dem Leser des Codes sofort klar macht, was sie tut. Vielleicht möchten Sie auf der Apple-Website nach einem WWDC-Video über die Änderungen von Swift 2 bis Swift 3 - eine große Anzahl von Änderungen, die nur an vorgenommen wurden) suchen Machen Sie alles besser lesbar. Vielleicht könnte diese Art von Video Ihre Entwickler davon überzeugen, dass Entwickler, die viel schlauer sind als sie, intuitive Methodennamen für sehr, sehr wichtig halten.

Ein weiterer beunruhigender Punkt war Ihre Kollegin, die sagte: "Sie hat mir selbst gesagt, dass sie nach Einreichung eines Fehlerberichts durch einen Kunden von dem Fehler wusste, aber befürchtete, dass der Entwickler sauer auf sie sein würde, wenn er darauf hinweist." Es besteht die Möglichkeit, dass es ein Missverständnis gibt, aber wenn ein Entwickler wütend wird, wenn Sie ihn auf einen Fehler hinweisen, ist das schlecht.

3
gnasher729

Ich würde der von Ihnen beschriebenen Methode der Codeüberprüfung mit Respekt widersprechen. Zwei Mitarbeiter gehen in einen 'geschlossenen Raum' und kritisieren institutionalisiert die Art von kontroverser Vorstellung, dass gute Codeüberprüfungen vermeiden sein sollten.

Es ist wichtig, dass die Codeüberprüfung so weit wie möglich zu einer positiven Erfahrung wird, um erfolgreich zu sein. Schritt eins besteht darin, den kontroversen Begriff der Überprüfung zu entfernen. Machen Sie es zu einem wöchentlichen oder zweiwöchentlichen Gruppe Ereignis; Stellen Sie sicher, dass jeder weiß, dass er zur Teilnahme eingeladen ist. Bestellen Sie in Pizza oder Sandwiches oder was auch immer. Nennen Sie es nicht einmal eine "Codeüberprüfung", wenn dies negative Konnotationen hervorruft. Finden Sie etwas zum Feiern, Ermutigen, Teilen - auch wenn es nichts anderes ist, als den aktuellen Sprint oder die aktuelle Iteration zu durchlaufen. Wechseln Sie abwechselnd die Führung über die Überprüfung.

Machen Sie den Prozess zu einem Bestreben, dem Produkt und den Menschen zu dienen. Wenn sie konstruktiv und positiv durchgeführt werden, wobei gute Techniken oder Muster geteilt und gefördert werden, ebenso wie schlechte entmutigt werden, profitieren alle. Jeder wird in der Öffentlichkeit gecoacht. Wenn Sie einen Problemprogrammierer haben, der es nicht "versteht", sollten diese privat und separat angesprochen werden - niemals vor der breiteren Gruppe. Das ist getrennt von der Codeüberprüfung.

Wenn Sie Probleme haben, etwas "Gutes" zu finden, das ich ansprechen kann, stellt sich für mich die Frage: Wenn im Projekt Fortschritte erzielt werden und die Menschen arbeiten, ist dieser Fortschritt an und für sich etwas zu feiern. Wenn Sie wirklich nichts gut finden, bedeutet dies, dass alles, was seit der letzten Überprüfung getan wurde, entweder schlecht oder nicht besser als neutral ist. Ist das wirklich der Fall?

Für die Details sind gemeinsame Standards unerlässlich. Geben Sie allen einen Anteil an dem, was getan wird. Und ermöglichen, dass neuere, bessere Techniken in Ihre Codebasis integriert werden. Das Versäumnis, dies zu tun, garantiert alte Gewohnheiten, wird niemals unter dem Deckmantel "Wir haben es immer so gemacht" herausgeschnitten.

Der Punkt bei all dem ist, dass Codeüberprüfungen einen schlechten Ruf bekommen, weil sie schlecht implementiert sind, als Hämmer verwendet werden, um weniger erfahrene oder weniger qualifizierte Programmierer herabzusetzen, und das ist für niemanden von Nutzen. Manager, die sie auf diese Weise verwenden, sind wahrscheinlich auch keine sehr effektiven Manager. Gute Codeüberprüfungen, bei denen jeder Teilnehmer ist, dienen jedem - dem Produkt, den Mitarbeitern und dem Unternehmen.

Entschuldigung für die Länge des Beitrags, aber in einer Gruppe, in der die Codeüberprüfung weitgehend ignoriert wurde, führte dies zu einem Vermächtnis von nicht wartbarem Code und nur einer begrenzten Anzahl von Entwicklern, die in der Lage waren, Änderungen an einer jahrelangen Codebasis vorzunehmen. Es war ein Weg, den ich nicht noch einmal beschreiten wollte.

3
David W

Das Paradox eines guten Codes ist, dass er überhaupt nicht auffällt und anscheinend sehr einfach und leicht zu schreiben war. Ich mag das Beispiel eines Poolspielers von diese Antwort sehr. Bei Codeüberprüfungen ist das wirklich einfach zu beschönigen, es sei denn, es handelt sich um einen Refactor für schlechten Code.

Ich lege Wert darauf, danach zu suchen. Wenn ich Code überprüfe und eine Datei durchgesehen habe, die so einfach zu lesen war, dass sie täuschend einfach zu schreiben scheint, gebe ich einfach ein kurzes "Ich mag, wie kurz und sauber die Methoden hier sind" oder was auch immer angemessen ist .

Sie sollten auch mit gutem Beispiel vorangehen. Sie sollten darauf bestehen, dass auch Ihr Code überprüft wird, und Sie sollten modellieren, wie sich Ihr Team beim Erhalt der Korrektur verhalten soll. Am wichtigsten ist, dass Sie den Menschen aufrichtig für das Feedback danken. Dies macht mehr Unterschied als jedes einseitige Feedback, das Sie geben können.

3
Karl Bielefeldt

Es klingt so, als ob das eigentliche Problem darin besteht, dass nur zwei Personen alle Codeüberprüfungen durchführen, von denen nur Sie sie ernst nehmen, was Sie in eine unglückliche Situation mit viel Verantwortung und viel gebracht hat Druck von den anderen Teammitgliedern.

Ein besserer Weg wäre, die Verantwortung für die Codeüberprüfungen auf das Team zu verteilen und alle daran teilnehmen zu lassen, indem beispielsweise die Entwickler auswählen, wen sie ihren Code überprüfen möchten. Dies sollte von Ihrem Codeüberprüfungstool unterstützt werden.

1
HelloGoodbye

Ich habe dies aus erster Hand gesehen und möchte Sie vor den emotionale Intelligenz herausgeforderten Antworten warnen - sie können ganze Teams töten. Wenn Sie nicht jedes Jahr neue Entwickler einstellen, schulen und normalisieren möchten, ist es wichtig, eine positive Beziehung zu Ihren Kollegen aufzubauen. Ist es nicht der springende Punkt, diese Überprüfungen durchzuführen, um die Codequalität zu verbessern und eine Kultur zu fördern, in der die Codequalität an erster Stelle höher ist? Ich würde argumentieren, dass es in der Tat Teil Ihrer Aufgabe ist, eine positive Verstärkung bereitzustellen, um dieses Codeüberprüfungssystem in die Teamkultur zu integrieren.

Klingt jedenfalls so, als müssten Sie Ihr Code Review-System überprüfen. Im Moment ist oder kann alles in Ihrem Überprüfungsprozess eher subjektiv als objektiv interpretiert werden. Es ist leicht, verletzte Gefühle zu bekommen, wenn es sich anfühlt, als würde jemand Ihren Code nur auseinander nehmen, weil er ihn nicht mag, anstatt einen Grund zu haben, den er zitieren kann, wenn etwas nicht den Richtlinien entspricht. Auf diese Weise ist es einfach, positive Verbesserungen der Codequalität (in Bezug auf Ihr Überprüfungssystem) zu verfolgen und zu "feiern", wie es für Ihre Bürokultur angemessen ist.

Die technischen Leiter müssen sich außerhalb einer Überprüfungssitzung treffen und eine Codierungsrichtlinie/Codeüberprüfungs-Checkliste erstellen, die während der Überprüfung eingehalten und beachtet werden muss. Dies sollte ein lebendiges Dokument sein, das im Verlauf des Prozesses aktualisiert und verfeinert werden kann. Diese Tech Lead-Meetings sollten auch stattfinden, wenn die Diskussion „Wie wir immer Dinge getan haben“ oder „Neue und verbesserte Wege, Dinge zu tun“ stattfinden sollte, ohne dass der Entwickler das Gefühl hat, dass die Meinungsverschiedenheit auf seinen Code zurückzuführen ist. Sobald die anfängliche Richtlinie mehr oder weniger geglättet wurde, besteht eine andere Möglichkeit, die Entwickler positiv zu stärken, darin, um ihr Feedback zu bitten und dann tatsächlich Maßnahmen zu ergreifen Wenn Sie den Prozess als Team weiterentwickeln, ist dies ein Wunder, um sie auf den neuesten Stand zu bringen und damit zu beginnen, Code für Onboards zu überprüfen, damit Sie erst nach Ihrer Pensionierung Überprüfungen durchführen müssen.

1
navigator_

Lokal...

Programmierer sind Problemlöser. Wir sind konditioniert, um mit dem Debuggen zu beginnen, wenn ein Problem oder ein Fehler auftritt.

Code ist ein Medium im Umrissformat. Das Wechseln zu einer Erzählung im Absatzformat für Feedback führt zu einer Unterbrechung, die übersetzt werden muss. Unweigerlich geht etwas verloren oder wird missverstanden. Es ist unvermeidlich, dass der Rezensent nicht in der Sprache des Programmierers spricht.

Computergenerierte Fehlermeldungen werden selten in Frage gestellt und niemals als persönliche Beleidigung angesehen.

Codeüberprüfungselemente sind vom Menschen erzeugte Fehlermeldungen. Sie sollen die Edge-Fälle erfassen, die Programmierer und automatisierte Tools übersehen, sowie die unvermeidlichen Nebenwirkungen auf andere Programme und Daten.

Schlussfolgerungen ...

Je mehr Codeüberprüfungselemente in automatisierte Tools integriert werden können, desto besser werden sie empfangen.

Die Einschränkung besteht darin, dass solche Tools, um unbestritten zu bleiben, kontinuierlich aktualisiert werden müssen, normalerweise täglich oder wöchentlich, um jeder Änderung von Verfahren, Standards und Praktiken gerecht zu werden. Wenn ein Manager oder Entwicklerteam eine Änderung vornimmt, müssen die Tools geändert werden, um dies durchzusetzen. Ein Großteil der Arbeit des Code-Reviewers besteht dann darin, die Regeln in den Tools beizubehalten.

Beispiel Code Review Feedback ...

Eine Umschreibung des gegebenen Beispiels unter Einbeziehung dieser Techniken:

  • Gegenstand:

    • Library\ACME\ExtractOrderMail-Klasse.
  • Grundsatzfrage ...

    • TempFilesToDelete ist statisch
      • Nachfolgende Aufrufe von GetMails lösen eine Ausnahme aus, da Dateien hinzugefügt, aber nach dem Löschen nie entfernt werden. Obwohl es derzeit nur einen Anruf gibt, könnte die Leistung in Zukunft mit einer gewissen Parallelität verbessert werden.
      • TempFilesToDelete als Instanzvariable würde die parallele Verwendung mehrerer Objekte ermöglichen.
  • Nebenfragen ...
    • GetErrorMailBody hat einen Ausnahmeparameter
      • Ist es notwendig, da es selbst keine Ausnahme auslöst und diese nur an ToString weitergibt?
    • SaveAndSend Name
      • E-Mail kann verwendet werden oder nicht, um dies in Zukunft zu melden, und dieser Code enthält die allgemeine Logik zum Speichern einer dauerhaften Kopie und zum Melden von Fehlern. Ein allgemeinerer Name würde solche erwarteten Änderungen ermöglichen, ohne die abhängigen Methoden zu ändern. Eine Möglichkeit ist StoreAndReport.
    • Alten Code auskommentieren
      • Das Hinterlassen einer kommentierten und mit OBSOLETE gekennzeichneten Zeile kann beim Debuggen sehr hilfreich sein, aber eine "Wand aus Kommentaren" kann auch Fehler im benachbarten Code verschleiern. Wir haben es immer noch in Subversion. Vielleicht nur ein Kommentar, der genau darauf verweist, wo in Subversion?
1
DocSalvager

Wenn Sie nichts Nettes zu dem vorhandenen Code zu sagen haben (was verständlich klingt), versuchen Sie, den Entwickler in die Verbesserung einzubeziehen.

In einem Patch für eine Funktionsänderung oder einen Bugfix ist es nicht hilfreich, andere Änderungen (Umbenennen, Refactoring usw.) in demselben Patch zu bündeln. Es sollte die Änderung vornehmen, die den Fehler behebt oder die Funktion hinzufügt, sonst nichts.

Wenn Umbenennen, Umgestalten und andere Änderungen angezeigt werden , führen Sie diese vorher oder nachher in einem separaten Patch durch.

  • Das ist ziemlich hässlich, aber ich denke, es stimmt mit all unserem anderen bösen Code überein. Lassen Sie uns das später bereinigen (in einem Patch mit im Idealfall ohne funktionale Änderungen).

    Es hilft auch, wenn Sie sich am Refactoring beteiligen und sie überprüfen lassen Ihre Code. Es gibt Ihnen die Möglichkeit zu sagen, warum Sie etwas für gut und nicht für schlecht halten, und ein Beispiel dafür zu zeigen, wie man konstruktive Kritik gut aufnimmt.

Wenn Sie einer neuen Funktion Komponententests hinzufügen müssen, werden diese im Haupt-Patch angezeigt. Wenn Sie jedoch einen Fehler beheben, sollten die Tests in einem früheren Patch durchgeführt und nicht bestanden werden , damit Sie nachweisen können, dass der Fehler tatsächlich behoben wurde.

Idealerweise sollte der Plan (wie Sie einen Fix testen können oder was umgestaltet werden muss und wann) besprochen werden, bevor die Arbeit abgeschlossen ist, damit sie nicht viel Aufwand in etwas gesteckt haben, bevor sie herausgefunden haben, dass Sie ein Problem damit haben.

Wenn Sie feststellen, dass Code nicht mit Eingaben zurechtkommt, die Sie für erforderlich halten, kann dies auch zu einer Nichtübereinstimmung mit dem führen, was der Entwickler als vernünftige Eingabe ansieht. Stimmen Sie dem nach Möglichkeit auch im Voraus zu. Besprechen Sie zumindest, was es bewältigen sollte und wie schlimm es sein kann, dass es versagt.

0
Useless

Ich halte es für einen Fehler anzunehmen, dass es eine technische oder einfache Lösung gibt für: "Meine Mitarbeiter sind verärgert, wenn ich ihre Arbeit nach meinen Maßstäben beurteile und die Befugnis habe, sie durchzusetzen.".

Denken Sie daran, dass Codeüberprüfungen nicht nur eine Diskussion darüber sind, was gut oder schlecht ist. Sie sind implizit ein "Wer ist der Maßstab, den wir verwenden", ein "Wer trifft die Entscheidung" und daher - höchst heimtückisch - ein Rang.

Wenn Sie diese Punkte nicht ansprechen, wird es schwierig sein, Codeüberprüfungen so durchzuführen, dass die Probleme, auf die Sie stoßen, nicht auftreten. Hier gibt es einige gute Ratschläge, aber Sie haben sich eine schwierige Aufgabe gestellt.

Wenn Sie Recht haben, ohne Spielraum, ist es ein Angriff, darauf hinzuweisen: Jemand hat es vermasselt. Wenn nicht: Ihr anderer MBA, der es nicht bekommt. In jedem Fall wirst du der Böse sein.

Wenn jedoch klar und vereinbart ist, wie die Bewertung aussieht und warum, haben Sie eine gute Chance, nicht der Böse zu sein. Sie sind nicht der Torhüter, nur ein Korrektor. Diese Vereinbarung zu erhalten ist ein schwer zu lösendes Problem [1]. Ich würde Ihnen gerne einen Rat geben, aber ich habe selbst noch nicht den Dreh raus ...

[1] Es ist nicht gelöst, nur weil die Leute "ok" gesagt haben oder aufgehört haben, darüber zu streiten. Keiner möchte der Typ sein, der sagt, dass X für unsere {Intelligenz, Erfahrung, Arbeitskraft, Fristen usw.} einfach nicht praktisch ist, aber das bedeutet nicht, wenn es tatsächlich um eine bestimmte Instanz von X geht ...

0
drjpizzle