Ich verpflichte mich ständig zu Open Source-Projekten (Red Hat usw.). Und er bemerkte, dass negative Codeüberprüfungen, die im Wesentlichen subjektiv sind, die meiste Zeit in Anspruch nehmen. Meistens geschieht dies bei Commits, bei denen der Betreuer Ihre Änderung aus irgendeinem Grund nicht mag. Im besten Fall führt eine solche Strategie zur Überprüfung des Codes zu Zeitverschwendung bei bedeutungslosen Debatten. im schlimmsten Fall rät es aktiv vom Engagement ab und schafft ein feindliches und elitäres Umfeld.

Die Codeüberprüfung sollte objektiv und präzise sein und nach Möglichkeit nur bestimmte Fakten enthalten. Dies ist keine politische oder emotionale Debatte, sondern eine technische. Sein Ziel ist es, voranzukommen, das Projekt und alle Teilnehmer weiterzuentwickeln. Jedes Commit sollte nur in der Sache und nicht in einer subjektiven Meinung bewertet werden.

Strategien zur Codeüberprüfung

Hier sind einige Strategien, die Sie berücksichtigen sollten, wenn Sie Code in Betracht ziehen, den Sie (als Betreuer) aus irgendeinem Grund nicht mögen:

1. Formulieren Sie den Einwand als Frage neu

• Schlecht: "Diese Änderung wird XXX unmöglich machen" (Dies ist eine Übertreibung; ist es wirklich unmöglich?)
  
• Gut: "Wie machen wir XXX nach Ihrem Wechsel?"

2. Übertreibung vermeiden

Bringen Sie einfach Ihre Bedenken zum Ausdruck und stellen Sie Fragen, um das gewünschte Ergebnis zu erzielen.

• Schlecht: "Diese Änderung wird die Produktivität zerstören."
  
• Gut: „Es scheint, dass X langsamer ist als das vorhandene Y; "Haben Sie Messungen durchgeführt / Daten gesammelt, um zu zeigen, dass dies nicht der Fall ist?"
  
• Besser (wenn Sie Zeit haben): „Im Moment sammle ich Daten. Ich werde versuchen zu überprüfen, ob X nicht langsamer als Y ist. "
  
• Ebenfalls gut: „Diese Änderung ändert einen einzelnen O (n) -Zyklus in einen doppelt verschachtelten O (n²) -Zyklus. Wird es die Leistung beeinträchtigen? “

3. Hinterlassen Sie sich böswillige Kommentare

Einige Gedanken bleiben am besten bei Ihnen. Wenn Sie nicht höflich sagen können, schweigen Sie besser.

• Schlecht: "Ich denke, das ist eine schlechte Veränderung, die alles ruinieren wird."
  
• Schlecht: "Sind Sie sicher, dass Softwareentwicklung die richtige Berufswahl für Sie ist?"

4. Positiv handeln

Vielleicht hatten Sie eine andere Idee, wie Sie das Problem lösen können? Wenn Sie positiv handeln, werden Sie letztendlich eine Lösung finden, die besser ist als alle ursprünglichen Optionen.

• Schlecht: "Diese Änderung ist scheiße, meine Version ist besser."
  
• Gut: "Ich habe auch eine Änderung für diesen Ort: Vielleicht können wir Ideen vergleichen und / oder kombinieren."
  
• Es ist auch gut. “Ich habe eine ähnliche Änderung in meiner Arbeit, aber ich habe mich für X entschieden, weil ZZZ; Warum hast du Y gewählt? "

5. Denken Sie daran, dass jeder eine andere Erfahrung hat.

Im Übrigen kennt ein absolut kompetenter Ingenieur möglicherweise einige Jahre lang einige Fakten nicht, die Sie als gesunden Menschenverstand ansehen. Es ist nichts Falsches daran, das Offensichtliche zu sagen, es sei denn, Sie bevormunden oder böswillig.

• Schlecht: "Kannst du nicht sehen, dass das eindeutig falsch ist?"
  
• Gut: "Dies ist nicht wahr, da es eine Nullzeigerausnahme auslöst, wenn X Y ist."

6. Spielen Sie die Komplexität dessen, was nicht offensichtlich ist, nicht herunter

Denken Sie daran, dass Dinge, die für Sie offensichtlich sind, möglicherweise nicht für alle offensichtlich sind. Indem Sie alternative Ansätze vorschlagen und nützliche Beispiele aufzeigen, können Sie allen bei der Synchronisierung helfen.

• Schlecht: "Warum nicht einfach die Gnosis zerquetschen?"
  
• Gut: "Wenn Sie die Gnosis zerquetschen, kann dieser Teil einfacher werden (siehe XXX für ein Beispiel)."

7. Respekt

Manchmal entspricht ein Commit einfach nicht dem Mindestqualitätsstandard. Es ist normal, dies zu sagen, aber Respekt zu zeigen erfordert keine zusätzlichen Anstrengungen.

• Schlecht: "Dies ist dummer Code, der von einer dummen Person geschrieben wurde."
  
• Gut: „Vielen Dank für Ihre Eingabe. Es kann jedoch nicht in seiner jetzigen Form übernommen werden. Es gibt viele Probleme (wie oben angegeben). “
  
• Ebenfalls gut: „Wie oben erwähnt, gibt es bei diesem Commit mehrere Probleme. Vielleicht einen Schritt zurücktreten und über Nutzungsszenarien sprechen? Dies wird helfen, den Weg zu finden. "

8. Verwalten Sie Ihre Erwartungen (und Ihre Zeit)

Wenn das Commit zu groß ist und nicht schnell berücksichtigt werden kann, ist es normal, dies sofort zu sagen. Dann suchen Sie nach einer Lösung.

• Schlecht: "Ich akzeptiere es nicht, es ist zu groß."
  
• Ebenfalls schlecht: Ignorieren Sie das Commit, bis es verschwindet.
  
• Gut: „Könnten Sie es in kleinere Commits aufteilen? Ich habe nicht zu viel Zeit für eine Codeüberprüfung, aber es ist einfach zu groß / kompliziert für eine Überprüfung. "

9. Sagen Sie "bitte" (mit freundlicher Genehmigung)

Wenn Sie nur „Bitte“ sagen, zeigen Sie, dass Sie die Zeit des Absenders respektieren, insbesondere wenn Sie die Formatierung oder den Stil ändern möchten, was wie eine geringfügige Änderung erscheinen kann. Beispiele:

• "Könnten Sie die Änderungen in den Lücken in einer anderen Poolanforderung dokumentieren?"
  
• "Könnten Sie diese Variablendefinitionen ausrichten, um sie leichter lesbar zu machen?"

10. Starten Sie ein Gespräch

Wenn Ihnen nach all dem etwas immer noch nicht gefällt, Sie sich aber nicht sicher sind, warum, müssen Sie sich möglicherweise nur damit abfinden. Oder sagen Sie: "Ich mag es nicht, aber ich bin mir nicht sicher warum, können wir darüber sprechen?" Dies ist eine vernünftige Frage, und obwohl es einige Zeit dauern kann, lohnt es sich oft, weil Sie jetzt zwei Personen haben und beide lernen (erklären und zuhören) und nicht zwei Personen, die sich gegenüberstehen.

Selbst qualifizierte und erfahrene Ingenieure sollten sagen können: "Ich verstehe nicht, warum es mir nicht gefällt." Dies ist keine Einladung, die Position des Rezensenten anzugreifen, sondern eine ehrliche Suche nach Wissen.

Zusammenfassung

Vermeiden Sie hyperbolische oder pompöse Aussagen, vermeiden Sie Streitigkeiten, elitäre oder erniedrigende Ausdrücke und Konstruktionen wie "offensichtlich" und "warum nicht einfach ...". Verwenden Sie klare, sachliche Aussagen und unterstützende Sprache, stellen Sie Fragen und gehen Sie weiter. Denken Sie daran, dass Kollegen und Mitwirkende auch Menschen sind. Ihre Zeit verdient den gleichen Respekt wie Ihre.