🙆 🈹 👩🏾‍🤝‍👩🏼 Codeüberprüfung Terminator. Bewertung, für die Sie gedankt werden 🔗 🛬 🕎

^{Ingwer hilft mir, den Code zu überprüfen. Und wenn er etwas nicht mag - auch einen echten Terminator,}

"Code Review Terminator", rief mich ein Kollege nach einer besonders produktiven Überprüfung einmal an. Einerseits unterhielt es die Tschechische Republik und war angenehm. Auf der anderen Seite hat ein Kollege wirklich etwas Neues gelernt, und so konnte er besseren Code schreiben. Also Win-Win.

Nach dem Arbeitswechsel wechselten auch die Kollegen. Aber auch an einem neuen Ort begannen sie, sich für die Bewertung zu bedanken. Ich beschloss herauszufinden, warum und stellte es in die Regale. Es stellte sich 11 Empfehlungen heraus.

1. Behandeln Sie die Überprüfung als eine der Hauptaktivitäten

Ein paar Kommentare wie "Und dann gibt es nicht genug Nullprüfung" zu hinterlassen, reicht nicht aus. Es ist notwendig:

Finden Sie heraus, was getan werden musste
Verstehe, wie es gemacht wurde
. ( , , )?
, , . — , .

2.

Es ist eine Sache, neben einem Kollegen zu sitzen und etwas zu besprechen und auf einen Bildschirm zu schauen. Eine andere Sache ist, den Code auf dem Github oder Bitbucket zu überprüfen. Es ist leicht, die Absichten eines Kollegen zu missverstehen, wenn die Kommunikation im Text erfolgt. Nehmen Sie den Satz "Es gibt einen Fehler in dieser Zeile". Ja, es ist klar, dass der Satz besagt, dass der Artikel einen Fehler aufweist. Aber man konnte ihr mit verschiedenen Emotionen sagen: Wut, Überraschung, Freude, dass der Käfer gefangen wurde und nicht in Produktion ging. Oder vielleicht gleichgültig.

Ihr Kollege kann Ihre Absichten missverstehen - und dies führt zu Ressentiments, Spannungen im Team und ist im Allgemeinen scheiße.

Machen Sie sich das Leben leichter: Machen Sie den Satz weicher, verwandeln Sie ihn in eine Frage oder fügen Sie vielleicht ein Smiley hinzu.

3. Zeit zuweisen

Um sicherzustellen, dass der Code korrekt und gut funktioniert, müssen Sie ihn vollständig verstehen. Und es braucht Zeit; Stellen Sie sicher, dass Sie es ausreichend hervorheben. Denken Sie daran, dass das Überprüfen von Teilen der Anwendung, die Sie nicht kennen, noch länger dauert.

Im Allgemeinen ist dies die Kehrseite guter Bewertungen: Es ist zeitaufwändig. Wenn Sie keine Zeit haben, es gut zu machen, versuchen Sie, eine andere Person zu verschieben oder zu ernennen (klingt wie der Rat eines Zauderer, aber die Situationen sind anders). Wenn dies keine Option ist, Sie jedoch eine Überprüfung durchführen müssen, denken Sie daran, dass Sie die Qualität opfern. Obwohl notwendig, aber ein Kompromiss. Wenn Sie es sich zur Gewohnheit machen, werden Sie in Zukunft mehr technische Schulden bekommen.

4. Machen Sie keine Annahmen; Fragen

Wenn Sie auf einen seltsamen Code oder eine übermäßig komplexe Lösung für eine scheinbar einfache Aufgabe stoßen, gehen Sie nicht standardmäßig davon aus, dass ein Kollege einen Fehler oder eine schlechte Wahl getroffen hat. Vielleicht sind ihm einige Umstände bekannt, von denen Sie nichts wissen. Sie können das Risiko unangenehmer und stressiger Situationen einfach klären und vermeiden, wenn Sie jemandem zu Unrecht die Schuld geben. Zum Beispiel: „Vielleicht können Sie hier eine solche Klasse verwenden? Soweit ich weiß, würde er hier gut passen, und das wäre einfacher als die vorgeschlagene Implementierung. “

5. Erfassen Sie Situationen, in denen Sie direkt Kontakt aufnehmen müssen

In der Regel werden Überprüfungen asynchron durchgeführt. So können Sie in den Code eintauchen und Ihren Kollegen weniger ablenken. In einigen Situationen ist es jedoch besser, direkt Kontakt aufzunehmen (indem Sie nach oben gehen oder anrufen):

Wenn die Fristen ablaufen. Schnelles Feedback beschleunigt Entscheidungen. Aber ordentlich: Mit Fristen und so weiter ist alles gespannt, und Ablenkungen werden nerven und die Konzentration verringern.
Grobe Fehler. Sie öffentlich zu diskutieren kann für jemanden sehr peinlich und frustrierend sein. Es ist besser, persönlich zu sprechen und das Problem zu erklären. Vielleicht ist es nur ein Versehen oder vielleicht eine Wissenslücke - die jetzt gefüllt ist.
Völlig falscher Ansatz gewählt. Um einer Person zu sagen, dass Sie ihre Arbeit wegwerfen müssen, müssen Sie vorsichtig sein. Es ist besser, Körpersprache und Intonation zu verwenden, um Klarstellungen ohne Beleidigung zu vermitteln.

Es ist eine gute Idee, dem Überprüfungssystem eine Konversationszusammenfassung hinzuzufügen.

6. Lesen Sie zuerst das Ticket

Einige der Anforderungen werden möglicherweise nicht in einer scheinbar korrekten Pull-Anforderung abgedeckt. Um dies zu vermeiden, lesen Sie zuerst die Problemstellung. Gleichzeitig hilft dies, zu verstehen, was im Allgemeinen in den Änderungen geschieht.

7. Begründen Sie Ihre Vorschläge

Einige Fehler (z. B. Tippfehler) müssen nicht erklärt werden. Wenn Sie jedoch eine alternative Architekturlösung oder einen anderen Namen anbieten, erläutern Sie die Vor- und Nachteile beider Optionen. Was Ihnen offensichtlich erscheint, ist für andere Menschen möglicherweise nicht ganz offensichtlich.

Außerdem gibt es ein Sprichwort: „Gib einem Mann einen Fisch und du fütterst ihn einen Tag. Bringe ihm das Fischen bei und du fütterst ihn fürs Leben. “ Wenn Sie einem Kollegen einen neuen Ansatz beigebracht haben, kann er ihn in Zukunft verwenden und Code besser schreiben. Gleichzeitig wird sich die Qualität des Projekts als Bonus verbessern.

8. Loben Sie gute Entscheidungen

Eine Überprüfung muss keine Auflistung von Fehlern sein. Wenn Sie einen guten Ort gesehen haben, eine interessante Lösung, eine nützliche Methode - erzählen Sie mir davon. Ein kurzer Kommentar „Coole Entscheidung“ kann die Stimmung einer Person für den ganzen Tag verbessern. Ja, und loben Sie nicht die schlechten Pull-Anfragen: Es ist angespannt und zerstört die Bedeutung der Idee.

9. Sei höflich

Hinweis: Ein Satz wie „ Können wir bitte den gehirngeschädigten, dummen Syntaxstil für Netzwerkkommentare loswerden? “ Ist nicht höflich (entschuldigen Sie das Englisch hier, aber dies ist eine direkte Rede von Linus Torvalds und es wäre dumm zu übersetzen; er besteht farbenfroh darauf, ihn nicht zu verwenden eine bestimmte Art von Kommentaren, aus Höflichkeitsgründen, mit dem Zusatz „Bitte“).

10. Hilfe

Wenn Sie während des Überprüfungsprozesses mehrere Dateien analysiert und als Ergebnis eine alternative Lösung gefunden haben, verwerfen Sie die Links des Kollegen zu diesen Dateien. Sie können sogar mit Zeilennummern, es ist noch bequemer. Es wird nicht viel von Ihrer Anstrengung erfordern, aber ein Kollege kann viel Zeit sparen.

11. Schlagen Sie vor, geben Sie nicht an

Wenn Sie einen anderen Ansatz für die Überprüfung vorschlagen, weisen Sie Ihren Kollegen nicht auf Bestellung an, Ihre Option zu verwenden. Argumentieren Sie und lassen Sie Ihren Kollegen entscheiden. Höchstwahrscheinlich wird er Ihren Rat befolgen. Und wenn nicht, was könnte der Grund sein?

Beide Ansätze sind ungefähr gleich. Wenn es keine objektiven Gründe für die Wahl eines neuen Ansatzes gibt, gibt es keinen Grund, Zeit zu verschwenden und anzuwenden. Haftungsausschluss: Die Einheitlichkeit des Codes ist ein objektiver Grund.
Es gibt einen objektiven Grund, warum Ihr Ansatz besser ist. Aber aus irgendeinem Grund versteht der Autor des Codes ihn nicht. Überprüfen Sie Ihre Argumentation, erklären Sie sie erneut - und prüfen Sie gleichzeitig, ob Sie sich irren.
Persönliche Konflikte. Dies ist rutschiges Eis und Sie müssen hier vorsichtig handeln. Und das geht bereits über den Rahmen des Überprüfungsthemas hinaus.

Das ist alles. Zusammenfassend:

Machen Sie die Welt um Sie herum ein bisschen besser. Gute Bewertungen abgeben.

UPD. Dieser Artikel ist eine kostenlose Übersetzung meines Originals in Englisch . Von "Übersetzung" zu "Artikel" konvertiert, um die Leser nicht zu verwirren.

Codeüberprüfung Terminator. Bewertung, für die Sie gedankt werden