In Codeüberprüfungen – Überarbeitungen gegenüber dem Korrekturlesen priorisieren | von William Dvorak | Mittel

Es gibt zwei unterschiedliche Formen des Feedbacks bei Code-Reviews: Überarbeiten und Korrekturlesen.

Als ich bei Google war, habe ich in jedem Team, zu dem ich beigetragen habe, eine Überbetonung des Korrekturlesens erlebt. Es ist auch in vielen anderen Ingenieurkulturen deutlich.

Ich habe festgestellt, dass die aussagekräftigsten Namen dieser beiden Konzepte aus dem Journalismus stammen: Überarbeiten und Korrekturlesen. Es gibt keine wirklich guten Begriffe in der Software-Engineering-Kultur. Struktur vs. Stil könnte eine Möglichkeit sein, aber ich glaube nicht, dass es die wichtigen Teile ganz erfasst. Ich behaupte, dass das Korrigieren viel wichtiger ist und dass viele Ingenieurkulturen zu viel Wert auf das Korrekturlesen legen.

Überarbeitendes Feedback kommt aggregiert und bezieht sich nicht auf eine einzelne Zeile und normalerweise nicht einmal auf eine Methode. Die Bitte um Überarbeitung ist ein Aufruf zur Änderung des Ansatzes und der Gesamtstruktur. Es könnte “dieses Tupel in seine eigene Klasse abstrahieren”, “diese API auf weniger Methoden vereinfachen” oder “diese Indirektion entfernen, hier ist keine zusätzliche Abstraktionsebene erforderlich” enthalten. Das Überarbeiten erfordert normalerweise, dass der Autor über das Problem nachdenkt, während er nicht an einer Tastatur tippt.

Feedback zum Korrekturlesen hingegen bezieht sich in der Regel auf eine oder wenige Zeilen. Dazu gehört es, Variablennamen aussagekräftiger zu machen, Hilfsfunktionen herauszuarbeiten oder von do-while zu for zu wechseln. Das Beheben dieser Änderungen wird mühsam und ist sehr lokalisiert. Das Befolgen von Styleguides ist eine große Quelle für Feedback zum Korrekturlesen, da Styleguides oft strenge Angaben zur Zeilenlänge und zur Groß- und Kleinschreibung von Variablen und Methoden machen.

Nehmen Sie zum Beispiel diesen Commit:

Das Überarbeiten von Feedback könnte Folgendes beinhalten:
– Ziehen Sie vergangene Benutzer in einen dauerhaften Speicher wie Cloud SQL.
– Fehlerpfad für API-Aufrufe hinzugefügt.
Feedback zum Korrekturlesen könnte sein:
-Entfernen Sie past_users von Benutzern, bevor Sie in Zeile 44 iterieren.
-Verwenden Sie die richtigen Leerzeichen zwischen kommagetrennten Variablen in Zeile 24.
-tokens, atoken und atokens (Zeile 24) können verwirrend sein. Wählen Sie aussagekräftigere Namen.
Dieses Beispiel ist klein, daher ist es schwierig, aussagekräftiges Überarbeitungsfeedback zu zeigen.

Das Überarbeiten Ihres Codes ist aus vielen Gründen wichtig. Die Art von Fehlern, die auf hoher Ebene passieren, sind dauerhafter und kostspieliger als die, die auf eine einzelne Methode beschränkt sind. Wenn Ihr Datenbankschema das Ziel verfehlt oder die API schlampig ist, ist der Aufwand für die Behebung enorm. Es wird möglicherweise erst Wochen oder Monate, nachdem der fehlerhafte Code eingegangen ist, behoben. Bis zu diesem Zeitpunkt wurden viele weitere Module auf den falschen Abstraktionen aufgebaut. Es ist ein umfangreiches Refactoring erforderlich, um den ursprünglichen Code neu zu erstellen. Oft wird mit den Fehlern gelebt und der Benutzer erhält eine suboptimale Erfahrung. Die Arbeit, jede Schicht des Stapels zu reparieren, wird zu kostspielig.

Fehler bei der Benennung von Variablen oder andere Probleme beim Korrekturlesen werden im Allgemeinen auf eine einzelne Datei beschränkt. Das bedeutet, dass sie später leicht behoben werden können, aber was noch wichtiger ist, sie beeinträchtigen nicht das System als Ganzes. Wenn der Fehler wichtig ist, lässt er sich leicht beheben. Wenn es keine Rolle spielt, bleibt es für immer, und niemand kümmert sich darum. Junior-Ingenieure können eine Methode mit Einzelbuchstabenvariablen durchdenken. Sie können über zwei for-Schleifen nachdenken, die in eine integriert werden könnten. Diese Probleme befinden sich in so wenigen Codezeilen, dass es einige Sekunden dauert, um festzustellen, was passiert.

Umgekehrt wird korrekturgelesener Code in der falschen Abstraktion beim Refactoring verworfen. Der Korrekturleseaufwand geht verloren, da der Code nun gelöscht ist. Wäre es stattdessen überarbeitet worden, wäre es nur einmal geschrieben worden, und Schlampereien, die behoben werden müssen, können in der Freizeit behoben werden. Da Ingenieure es fast immer vorziehen, neuen Code zu schreiben, anstatt alten zu bearbeiten (selbst in einer Kultur des Korrekturlesens), ist es wichtig, dass wir auf einer soliden Grundlage gut durchdachter Abstraktionen stehen.

Bei Google habe ich die erfahrensten Ingenieure beobachtet, und ihr Denken konzentrierte sich darauf, die großen, übermäßig komplexen Systeme zu verstehen – Wege zu finden, sie korrekter zu abstrahieren, um den jüngeren Ingenieuren ein klareres Denken zu ermöglichen. Vereinfachungen großer Abstraktionen waren Futter für Werbeaktionen. Dies unterstreicht die relative Unternehmenspriorität. Die Notwendigkeit für diese großen Refactors hätte jedoch von vornherein durch eine gute Überarbeitung des Codes kurzgeschlossen werden können.

Die Auswirkungen des Feedbacks auf die Wartbarkeit des Codes können Sie in unserem Beispiel sehen. Wenn wir nur die Revisionen korrigieren würden, hätten wir eine funktionalere und robustere Codebasis. Durch das Korrigieren der Änderungen beim Korrekturlesen hätten wir jedoch etwas besser lesbaren Code, was uns 10 Sekunden sparen würde, wenn wir den Code in Zukunft überprüfen.
Subtile Fehler können durch nachlässige Benennung und schlechte Code-Hygiene entstehen, daher ist Proofing nicht ohne Wert. Beides schließt sich auch nicht aus. Aber ich denke, es ist wichtiger, sich auf die Überarbeitung zu konzentrieren.

Mein Argument hier ist ähnlich dem Befürworten von „das Richtige tun“ statt „das Richtige tun“. Es scheint mir, dass Ingenieure die Details um Größenordnungen überpriorisieren, während sie das Ziel verfehlen, etwas Nützliches zu schaffen.

Tun Sie das Richtige, wenn Sie Code überprüfen. Hinterlassen Sie Revisionsfeedback und ignorieren Sie die Nitpicks. Als Ergebnis werden wir alle nützlichere Produkte haben. Und wenn Sie nicht gesehen haben, dass „essential“ in meinem Header-Bild falsch geschrieben ist, habe ich meinen Standpunkt bewiesen.

Originalartikel veröffentlicht unter:

Similar Posts

Leave a Reply

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