Bessere PRs | Komentor

Ich habe diesen Artikel im internen Wiki meines derzeitigen Arbeitgebers gepostet

Motivation

Warum möchten wir, dass unsere Änderungen von anderen Mitgliedern unseres Teams überprüft werden?

Es gibt mehrere Gründe, aber für mich sind die wichtigsten:

  • Wissen teilen. Wir möchten, dass mehr Leute die Codebasis verstehen und Änderungen daran vornehmen können.
  • Lösungsvalidierung. Wir möchten, dass mehrere Ingenieure unsere Lösung analysieren und versuchen, Probleme damit zu finden, Alternativen vorzuschlagen usw.
  • Qualität steigern. Wir wollen Fehler, Auslassungen, Inkonsistenzen, Ineffizienzen usw. so früh wie möglich erkennen und beheben, bevor sie die Produktion erreichen.

Vorschlag

Als einzelne Mitwirkende an der Quelle müssen wir diese Ziele fördern, indem wir Zeit/Mühe aufwenden, um unsere PRs zu verbessern und Rezensenten durch sie zu führen!

Möglichkeiten zur Verbesserung von PRs:

  • Halten Sie PRs so klein und in sich geschlossen wie möglich
    • minimieren Sie den Änderungssatz! Z.B. Quellcode nicht neu formatieren, Leerzeichen nicht entfernen, Code nicht verschieben, keine Umgestaltungen vornehmen, sofern nicht relevant usw.
      • All dies ist nützlich, sollte aber in separaten, spezialisierten PRs durchgeführt werden.
    • Dies macht PRs überschaubar und hält die Prüfer konzentriert!
  • Ihre PR-Beschreibung sollte zwei Fragen beantworten:
    • Wieso den? – Was ist die Motivation für diese Arbeit? Welches Problem löst die PR?
    • Wie? – eine kurze Anleitung zu der in der PR implementierten Lösung. Mehr dazu als nächstes.
    • Dadurch wird der Kontext geschaffen, den der Prüfer für seine Arbeit benötigt. Es ist in Ordnung, wenn dies ein Link zum Projektmanagement-Tool ist, solange die Story-Beschreibung diese Fragen beantwortet.
  • kurze, in sich geschlossene Commits mit klaren und prägnanten Commit-Nachrichten.
    • Dies ermutigt die Prüfer, die Commits einzeln durchzugehen, was eine intuitive Reihenfolge zum Überprüfen des Codes darstellt.

Rezensenten führen

  • PRs haben normalerweise eine Kernänderung, alles andere unterstützt diese Änderung – z. neue Dienstprogramme, neue Typen, neue Tests usw. Wenn diese Kernänderung nicht offensichtlich ist, machen Sie sie explizit in der Beschreibung, lassen Sie den Rezensenten damit beginnen!
    • Das gibt der Bewertung Struktur
  • Leiten Sie Prüfer dahin, wo die „kniffligen“ Änderungen liegen. Lassen Sie sie sich auf diese Änderungen konzentrieren, um Ihren Ansatz zu validieren.
    • Gute Kandidaten sind: eine SQL-Abfrage, deren Leistung Sie nicht sicher sind, ein Test, dessen Abdeckung verbessert werden kann, ein von Ihnen implementierter Algorithmus, bei dem Sie sich über die Randfälle nicht sicher sind.
    • Beschreiben Sie bei Bedarf, welche Alternativen es gab, warum Sie sich für diese Option entschieden haben, welche Vor- und Nachteile sie haben usw.

Fazit

Das ist deutlich mehr Arbeit! Ich höre Sie sagen.

Ich stimme zu, aber ich denke, dass sich die Dinge mit Übung beschleunigen werden. Der Vorteil ist, dass wir – als Team – mittel-/langfristig schneller vorankommen und bessere Arbeit leisten werden.

Similar Posts

Leave a Reply

Your email address will not be published. Required fields are marked *