In vielen Jahren des Schreibens und Überprüfens von Code habe ich einige Geheimnisse gelernt, um bessere Pull-Anfragen zu erstellen und Code effizienter zu überprüfen.
All diese Geheimnisse habe ich in mein neues Buch „Pull Requests and Code Review“ einfließen lassen, aber hier finden Sie eine Vorschau mit diesen 13 Tipps, die Sie bereits in Ihrer Entwickleraktivität nutzen können.
Fallen Ihnen weitere Tipps ein? Teile sie in Kommentaren 😉
Ein PR-Entwurf hilft Ihnen, Ihre Ideen zu organisieren und Ihren Fortschritt zu dokumentieren, während Sie noch an Ihrem Feature arbeiten.
Der beste Weg, eine schnelle und effiziente Überprüfung zu erhalten, besteht darin, Ihre PR klein zu halten und gut zu dokumentieren (mit dem gesamten notwendigen Kontext). Sie erhöhen auch Ihre Chancen auf zukünftige PRs, indem Sie jetzt großartigen Code liefern!
Alle diese Tipps und mehr, mit weiteren Beispielen aus der Praxis und umsetzbaren Erkenntnissen finden Sie in meinem kostenlosen Buch „Pull Requests and Code Review: Best Practices for Developers, from Junior to Team Lead“ .
Versetzen Sie sich in die Lage Ihres Rezensenten, antizipieren Sie Fragen und kommentieren Sie Ihren eigenen Code, wenn Sie glauben, dass er ihm helfen kann.
Übertragen Sie Ihre PR nicht auf die ganze Welt. Wählen Sie Ihre Rezensenten sorgfältig aus, um eine relevante Bewertung zu erhalten, ohne zu lange auf die Genehmigung warten zu müssen.
Seien Sie offen für Feedback, bitten Sie um Klarstellung, sagen Sie, wenn Sie anderer Meinung sind (mit Respekt) und antworten Sie immer auf Kommentare.
Jeder hat viele PRs zu überprüfen und wenig freie Zeit dafür. Wenn Sie andere PRs überprüfen, erhöhen Sie die Chancen, dass auch Ihre PRs überprüft werden.
Als Junior-Entwickler können Sie anderen mitteilen, wenn Sie einen Teil des Codes nicht verstehen, da dieser für jeden Entwickler im Team verständlich sein sollte.
Mehr dazu in meinem Beitrag Wie gebe ich als Junior-Entwickler eine Codeüberprüfung ab? .
Das Ziel der Codeüberprüfung besteht darin, nach Fehlern und Grenzfällen zu suchen und die Implementierung zu hinterfragen. Es sollte weder dazu verwendet werden, sich über geringfügige Formatierungs- oder Stilvorlieben lustig zu machen, noch für groß angelegte Architekturdiskussionen.
Verwenden Sie „Warum nicht“ statt „Sie sollten“, seien Sie offen und positiv und schlagen Sie immer eine Alternative vor, wenn Sie um eine Änderung bitten.
Nicht alle Kommentare erfordern eine Änderung und nicht alle gewünschten Änderungen sind für die Genehmigung der PR erforderlich. Machen Sie in Ihrem Kommentar klar, ob die Änderung nicht dringend ist.
Bevor Sie Ihre Bewertung veröffentlichen, lesen Sie jeden Kommentar noch einmal: Überprüfen Sie den Ton, den Sie verwenden, und stellen Sie sicher, dass Sie den gesamten Kontext angeben, um dem PR-Einreicher zu helfen.
Sie möchten nicht, dass der Prüfer zwei Tage, nachdem er alle von Ihnen gewünschten Änderungen vorgenommen hat, auf Ihre Genehmigung wartet. Wenn Sie es überprüfen, gehen Sie davon aus, dass Sie es genehmigen, sobald alle Korrekturen vorgenommen wurden.
Wenn ein Kommentar-Thread zu einer Debatte in Ihrer PR wird, unterbrechen Sie ihn besser und schlagen Sie vor, die Diskussion an anderer Stelle fortzusetzen, z. B. in einem Slack-Thread. Reservieren Sie ggf. eine Besprechung und/oder ziehen Sie einen Dritten hinzu.
Das ist es! Was halten Sie von diesen Tipps? Fällt Ihnen ein Tipp ein, den Sie anderen Entwicklern geben möchten?
Teile sie hier in den Kommentaren 👇
Wenn Ihnen diese Tipps gefallen haben und Sie mehr erfahren möchten, schauen Sie sich mein Buch „Pull Requests and Code Review“ an, es ist kostenlos!
Auch hier veröffentlicht.