Code-Reviews sind ein wichtiger Bestandteil der Softwareentwicklung, besonders wenn man in einem Team arbeitet. Es ist wichtig, dass es eine vereinbarte Etikette für die Durchführung von Code-Reviews innerhalb eines Teams gibt. Eine Code-Review ist eine Kritik, und eine Kritik kann sich oft persönlicher anfühlen als das Schreiben des Codes selbst. Eine schlampige, schlecht recherchierte oder unsensible Code-Kritik kann zu Schwierigkeiten zwischen Teammitgliedern führen, die allgemeine Teamproduktivität verringern und die Codequalität im Laufe der Zeit mindern. Dieser Beitrag definiert kurz Code-Reviews, beschreibt einige häufige Fehler und gibt einige schnelle Tipps zur Verbesserung des Code-Review-Prozesses.
Was sind Code-Reviews?
Code-Reviews sind der Prozess des Teilens von Code, damit andere Ingenieure ihn überprüfen können. Code-Reviews können mündlich während Pair-Programming-Sitzungen oder durch das Überprüfen von Code auf Websites wie CodePen und GitHub erfolgen. Hauptsächlich finden Code-Reviews in Tools wie GitHub statt, wenn Ingenieure Pull-Requests einreichen.
Kritiken sind äußerst vorteilhaft. Die Zusammenführung von Ingenieuren zu Diskussionen über Code stellt sicher, dass sie auf dem gleichen Stand sind, unabhängig davon, ob dies persönlich geschieht oder durch den Austausch von Kommentaren. Außerdem kann eine Überprüfung helfen, kleine Fehler im Code oder in den Kommentaren – wie z. B. Rechtschreibfehler – zu erkennen, und sie kann neueren oder jüngeren Codern helfen, die Codebasis kennenzulernen. Wenn sie gut durchgeführt werden, haben regelmäßige Code-Reviews nur Vorteile für alle Beteiligten.
Ein häufiges Ziel von Code-Reviews ist es, Codeänderungen so minimal und klar wie möglich zu gestalten, damit der Prüfer leicht versteht, was sich geändert hat und was im Code vor sich geht. Wenn Code-Reviews kleiner sind, sind sie häufiger – potenziell mehrmals täglich – und besser zu handhaben.
Das Überprüfen von Code sollte Teil des Workflows jedes Entwicklers sein. Erfahrenen Prüfern wird die Möglichkeit gegeben, zu lehren/zu mentoren und manchmal sogar etwas Neues zu lernen. Junge Prüfer können wachsen und durch ihre Fragen oft zur Lesbarkeit des Codes beitragen. Tatsächlich sind junge Ingenieure in der Regel die besten Teammitglieder, um die Lesbarkeit des Codes sicherzustellen.
Für einen Ingenieur, der allein arbeitet, kann das Einholen von Feedback von Außenstehenden – auf Meet-ups, GitHub, Open-Source-Slack-Kanälen, Reddit, Twitter usw. – dem Solo-Coder die Möglichkeit geben, am Code-Review-Prozess teilzunehmen.
Wenn wir uns alle auf einen etablierten Prozess und eine Sprache für die Überprüfung von Code einigen könnten, wäre die Aufrechterhaltung einer positiven Umgebung für kreative und produktive Ingenieurarbeit einfacher. Eine Etikette für Code-Reviews nützt jedem – ob allein oder im Team.
Harte Code-Reviews können Gefühle verletzen
Das Sehen von Fehlern und Problemen, die immer wieder auftauchen, und die geistige Unfähigkeit, sie zu beheben, hat zu Gefühlen des Versagens und der Depression geführt. Als ich auf das Projekt Moment schaute, sah ich nur die Negativität. Die Fehler und falschen Bezeichnungen und Fehler, die ich gemacht hatte. Es führte zu einem Kreislauf, in dem ich zu deprimiert war, um beizutragen, was dazu führte, dass ich deprimiert war, weil ich nicht beitrug.
- Tim Wood, Erfinder von Momentjs
Es gibt viele Online-Kommentare, Beiträge und Tweets von produktiven Ingenieuren, die ausdrücken, dass ihre Gefühle durch Code-Reviews verletzt wurden. Das bedeutet nicht direkt, dass die Prüfer böse Absichten haben. Sich verteidigend zu fühlen, ist eine normale, ziemlich *menschliche* Reaktion auf eine Kritik oder ein Feedback. Ein Prüfer sollte sich bewusst sein, wie die Darstellung, der Ton oder die Stimmung seiner Kommentare vom Rezensenten interpretiert werden könnten – siehe Ockhams Rasiermesser.
Es ist, als ob diese Kommentatoren Maintainer nicht als Menschen betrachten, wir machen Fehler. https://#/tBa8kzymU4
- Henry Zhu @SF (@left_pad) 18. September 2017
Obwohl die Überprüfung von Code sehr vorteilhaft ist, kann eine schlechte oder schlampige Überprüfung das Gegenteil bewirken. Vermeiden Sie Kritik, ohne Kontext zu geben. Mit anderen Worten, nehmen Sie sich die Zeit, zu erklären, warum etwas falsch ist, wo es falsch gelaufen ist und wie der Fehler in Zukunft vermieden werden kann. Diese Art von Respekt gegenüber dem Rezensierten stärkt das Team, verbessert das technische Bewusstsein und hilft, vereinbarte technische Definitionen zu schaffen.
Schnelle Tipps zur Verbesserung der Code-Review-Etikette
Code ist von Natur aus logisch. Es ist leicht, Code zu erkennen, der falsch ist oder verbessert werden könnte, so wie es leicht ist, Rechtschreibfehler (*Misteaks*) zu bemerken. Die menschliche Natur, wenn sie logische Dinge (wie Code) betrachtet und diskutiert, neigt dazu, die Gefühle anderer Menschen zu ignorieren. Das führt dazu, dass Gefühle verletzt werden und der Fokus auf Lernen und Zusammenarbeit verloren geht.
Die Verbesserung der *Code-Review-Etikette* ist aufgrund der menschlichen Natur schwierig! Hier ist eine kurze Liste von Dingen, die ich getan, gesagt, gesehen oder erhalten habe und die einfache Erfolge in der Kunst der Code-Review-Etikette darstellen.
Entfernen Sie die Person
Ohne es zu merken, können Ingenieure den Unterschied zwischen aufschlussreicher Kritik und reiner Kritik aufgrund von persönlichen Beziehungen in der Kommunikation vernachlässigen.
Die folgenden Zeilen zerlegen einen theoretischen Code-Review-Kommentar einer function, in dem vorgeschlagen wird, dass die Möglichkeit besteht, frühzeitig aus der Funktion zurückzukehren.
Sie und ich: Die Verwendung von *Sie* oder *Ich* ist wahrscheinlich nicht absichtlich beleidigend, also machen Sie sich keine Sorgen. Mit der Zeit kann die Einbeziehung der Person jedoch weniger positiv wirken – besonders wenn jemals verbale Töne hinzugefügt werden.
Sie sollten frühzeitig aus dieser Funktion zurückkehren
Wir: Die Verwendung von wir ist inklusiv und eine sichere Methode, etwas direkter zu sagen, ohne dass sich jemand verteidigen muss. Wenn die sprechende Person jedoch wir sagt und überhaupt nicht am Code gearbeitet hat, kann dies fälschlicherweise inklusiv und unsensibel erscheinen.
Wir sollten frühzeitig aus dieser Funktion zurückkehren
Keine persönliche Bezugnahme: Ohne persönliche Bezugnahme werden Konversation oder Überprüfung das Problem, die Idee oder das Anliegen klar kommunizieren.
Frühzeitig aus dieser Funktion zurückkehren
Beachten Sie, wie die Menge an Text, die benötigt wird, um dasselbe ohne persönliche Bezugnahme zu kommunizieren, weniger Wörter erfordert und eine größere Klarheit aufweist. Dies hilft bei der menschlichen Interaktion, trennt die Code-Diskussion von der persönlichen Diskussion und es werden weniger Wörter benötigt, um die gleiche Idee zu kommunizieren.
Halten Sie leidenschaftliche Gespräche ruhig
Leidenschaft ist ein wichtiger Motivator für Verbesserungen. Leidenschaft, die kritischer Natur ist, kann sehr rücksichtsvoll und motivierend sein. Feedback, das kritischer Natur ist, ist am nützlichsten, wenn die Person, die die Kritik erhält, engagiert ist. Diese Art der Kommunikation kommt oft bei Architekturdiskussionen oder bei der Besprechung neuer Produkte vor.
Feedback, das kritischer Natur ist, ist am nützlichsten, wenn die Person, die die Kritik erhält, engagiert ist. Hinweis: Die Person, die die Informationen erhält, muss sich mit der Kritik auseinandersetzen.
Stellen Sie sich diesen Kommentar vor, wenn er mit übertriebener Körpersprache, einem aufgeregteren Stimmton und höherer Lautstärke vorgetragen wird.
In diesem Mock werden 8 Web-Fonts verwendet, was die Seitenladegeschwindigkeit oder bestimmte Tracking-Metriken beeinträchtigen kann, die durch neue Race Conditions verursacht werden könnten!
Stellen Sie sich dann einen ähnlichen Kommentar vor, der noch knapper ist, aber mit ruhiger Gelassenheit, langsamerer Darbietung und normaler Stimmlautstärke vorgetragen wird – gefolgt von einer Frage.
In diesem Mock werden 8 Web-Fonts verwendet. Dies beeinträchtigt die Seitenladegeschwindigkeit und mögliche Tracking-Metriken aufgrund potenzieller Race Conditions. Wie kann dies verbessert werden?
Beachten Sie, wie die obigen Kommentare fast gleich sind. Der zweite Kommentar ist noch direkter. Er nennt ein Problem als Tatsache und bittet dann um Feedback.
Eine wichtige Sache, die man bei Leidenschaft beachten sollte, ist die Annahme eines ruhigeren Tons. Dies ist eine physische Entscheidung – keine soziale. Leidenschaftliche Sprache kann dieselbe sein und ganz anders wahrgenommen werden, je nach Ausrichtung des Tons des Kommunikators. Wenn der physische Ton (Körpersprache), der Stimmton, die Stimmlage und die Stimmlautstärke sanft bleiben, wird beobachtet, dass ein Publikum eher engagiert bleibt – auch wenn die Kritik kritischer Natur ist.
Wenn der Ton aggressiv ist (übertriebene Körpersprache, aufgeregterer Stimmton, höhere Lautstärke), kann die tatsächliche Sprache sanft sein, aber das Publikum kann sich ganz anders fühlen. Diese Kommunikation kann zu Verlegenheit, einem desinteressierten Publikum und sogar zum Verlust von Respekt führen.
Aggressive Kommunikation ist bei leidenschaftlicher Kommunikation üblich, weil der menschliche Zustand Ideen schützen möchte, für die wir leidenschaftlich sind. Machen Sie sich also nicht *zu* viele Sorgen, wenn Sie feststellen, dass Ihr Publikum desinteressiert ist, wenn Sie über etwas diskutieren, das Sie leidenschaftlich beschäftigt. Der Schlüssel ist, sich daran zu erinnern, dass Sie, wenn Sie eine wahrgenommene sanfte Kommunikation schaffen können, leichter ein engagiertes Publikum haben werden – auch wenn es zunächst nicht zustimmt.
Überprüfen Sie nicht den Autor, überprüfen Sie den Code
Nach dem obigen Gespräch ist das Zeigen, sowohl in geschriebener Konversation als auch in tatsächlicher Körpersprache, in fast jeder Situation nicht optimal für eine gute Kommunikation. Es verlagert den Fokus des Gesprächs vom Kontext des Gesprächs auf eine Person oder eine Sache.
Die folgende Antwort enthält einen Kommentar und dann einen Link. Im Kontext der Code-Review führt der zweite Teil des Kommentars und Links den Leser aus dem Kontext der Code-Review heraus, was verwirrend ist.
// Return out of this function earlier
// You need to learn about functional programmingDer Kommentar unten liefert einen Kommentar und dann einen Pseudo-Code-Vorschlag.
/*
return early like this:
*/
const calculateStuff = (stuff) => {
if (noStuff) return
// calculate stuff
return calculatedStuff
}In den beiden obigen Beispielen führt das erste Beispiel dazu, dass der Leser weit über das Problem hinausgeht. Die Konversation ist abstrakter – sogar existentiell. Das zweite Beispiel bezieht sich direkt auf das Problem und liefert dann einen Pseudo-Code-Schnipsel, der sich direkt auf den Kommentar bezieht.
Es ist am besten, bei der Überprüfung von Code nur kontextspezifische Elemente zu kommentieren. Breite Kommentare führen zu einem Verlust des Kontexts. Wenn breitere Diskussionen stattfinden müssen, sollten sie außerhalb von Code-Reviews stattfinden. Dies hält die Code-Review klar und auf den zu überprüfenden Code beschränkt.
Richtig und falsch können sich ändern
Entwickler wollen Dinge fast immer neu schreiben. Es ist natürlich, Probleme in Echtzeit in Aufgaben aufzuteilen, um die aktuelle Situation zu bewältigen. Es ist jedoch wichtig, sich auf das *Wer* und *Warum* der Geschichte eines Produkts zu konzentrieren, um es zu konzeptualisieren, da dadurch großer Kontext gewonnen wird. „Die Geschichte wiederholt sich“ ist ein wichtiger Satz, den man sich merken sollte, wenn man Produkte kritisiert oder wenn ein Produkt, das man geschrieben hat, kritisiert wird. Es gibt immer viel Wissen, das aus dem historischen Kontext gewonnen werden kann.
JavaScript wurde in einer Woche erstellt, als eine hackelige Skriptsprache angesehen und wurde dann zur meistverwendeten Programmiersprache der Welt. Scalable Vector Graphics (SVGs) wurden 1999 unterstützt, fast vergessen und heute gewinnen sie weiter an Popularität, aufgrund der neuen Möglichkeiten, die sie bieten. Selbst das World Wide Web (das Internet) war für den Dokumentenaustausch gedacht, mit wenig Vorahnung auf das heutige Ergebnis. All diese Technologien sind wichtig, wenn man Software und Ingenieurwesen betrachtet – so logisch und vorhersehbar Ergebnisse auch sein mögen, Erfolg leitet sich oft aus unerwarteten Ergebnissen ab! Seien Sie offen!
Einige Ressourcen und Werkzeuge, die bei der Code-Review-Etikette helfen können
- Alexjs: ein Werkzeug zum Erkennen von unsensibler, rücksichtsloser Sprache von Titus Wormer
- Grammarly: eine Erweiterung zur Verbesserung der Kommunikation in Browsern
- Write Good: ein CLI- und Texteditor-Plugin von Brian Ford zur Verbesserung der Kommunikation in Texteditoren und Shells
- Awesome Writing Tools: eine Awesome List von Werkzeugen zur Verbesserung des Schreibens.
Fazit
Die obige Liste enthält allgemeine, übergeordnete Dinge, die bei positivem Engagement helfen können, wenn über Code gesprochen, dieser überprüft oder gelesen wird – *Code-Review-Etikette*.
Ich bin ein Heuchler. Ich habe alle Fehler gemacht, von denen ich in diesem Artikel abrate. Ich bin menschlich. Mein Ziel ist es hier, anderen zu helfen, die Fehler zu vermeiden, die ich gemacht habe, und vielleicht einige Verhaltensstandards für die Überprüfung von Code zu fördern, damit Ingenieure Code offener diskutieren können, mit weniger Sorge, verletzt zu werden oder andere zu verletzen.
Toller Artikel – danke. Vieles hier, womit ich übereinstimme. Ähnlich habe ich https://capgemini.github.io/learning/better-learning-code-reviews/ geschrieben – bitte schauen Sie es sich an
Großartige Sache, Malcolm.
Ich habe Ihren Artikel sehr genossen! Ich habe ihn sofort gelesen und war glücklich, dass mehr Leute über ähnliche Dinge nachdachten. Insbesondere für mich führte der Abschnitt über Werkzeuge dazu, dass ich auf Dinge klickte, die meinen Prozess verbessern könnten.
Danke fürs Teilen!
Ein paar weitere Vorschläge, die ich verwende
1) Ich führe die Code-Review so durch, dass sie das Gute, das Schlechte und das Hässliche abdeckt.
2) Ich stelle mir die Frage: „Wenn ich diesen Code warten müsste, was würde ich wissen wollen?“
3) Ich bitte andere, sich zu äußern, wenn sie etwas in meinen Algorithmen oder meiner Struktur sehen, das ich falsch mache.
4) Ich präsentiere oft alternative Implementierungen mit Vor- und Nachteilen (z. B. Verwendung von Metadaten und Reflexion vs. imperativem Code, Verwendung von LINQ vs. „altmodischem“ Code).
5) Und am wichtigsten ist, dass ich keine Code-Reviews für den Code anderer Leute leite, sondern sie bitte, eine Code-Review ihres eigenen Codes zu leiten.
#5 Tolle Idee, Marc.
Das ist phänomenal. Wirklich schöne Erklärungen. Ein paar Ergänzungen basierend auf meinen Erfahrungen
Code-Reviews können auf Managementprinzipien basieren, die dem Team bekannt sind. Andernfalls können Ingenieure leicht aus dem Takt geraten.
Das Konzentrieren auf den Inhalt statt auf den Stil hat mir geholfen, die Botschaft zu verstehen, die die Person vermitteln wollte. Ich gehe normalerweise zuerst davon aus, dass die kommentierende Person die besten Absichten hat, zu helfen.
Oft führen Code-Reviews immer noch zu viel Streit. Die Zuweisung einer glaubwürdigen Person zur Beilegung von Meinungsverschiedenheiten kann helfen. Oft führen emotionale Prozesse wie „Ich will meinen PR einfach reinbekommen“ oder die Rechtfertigung, warum man etwas nicht gemäß den Teamprinzipien getan hat, sofort zu Streit. Wenn jemand, der gezeigt hat, dass er ähnliche Probleme konsequent löst und seinen Prozess gut erklären kann, beauftragt wird, Fragen in einem PR zu klären, fühlt es sich an, als würden Meinungsverschiedenheiten dazu führen, dass sich Mitglieder annähern, anstatt sich zu trennen.
Sehr schöner Artikel. Ich habe jedoch eine Frage.
Wenn man mit einem Team arbeitet und ständig Pushes/PRs macht, ist es dann nicht umständlich, jeden Pull-Request zu überprüfen? Wie würden Sie das lösen?
Wie Malcom erwähnt, toller Artikel! Etwas, das ich mit meinem Team geteilt habe.
Ich kommentiere nur, um Ihnen mitzuteilen, dass ich diesen Artikel schätzte und das Teilen von weniger „glamourösen“ Inhalten als der neuesten technischen bling schätze.
Ich finde es komisch, dass es mit meiner eigenen Familie viel schwieriger ist, cool zu bleiben und objektiv zu sein. Aber da ich so viel unnötig persönliche Kritik erhalten habe, versuche ich sehr vorsichtig zu sein, meine eigenen Kritiken an anderen auf reiner Logik basieren zu lassen.
Das hilft mir, Lösungen von anderen Leuten zu akzeptieren, mit denen ich normalerweise nicht umgehen möchte, da ich gelernt habe, andere Leute wertzuschätzen, die einfach Dinge erledigt bekommen, und wenn sie Basecamp benutzen wollen *seufz*, werden wir Basecamp benutzen. Es ist besser als schlechte Kommunikation und ständige Fehler. Tatsächlich bin ich froh, Basecamp für einen bestimmten Kunden zu verwenden, da dieser Kunde sofort eine klare Kommunikation eingeführt hat. Insbesondere in E-Mails war der Ton gesprächig, aber in Projektmanagement-Software ergibt ein gesprächiger Stil keinen Sinn.
Nachdem ich das jetzt aufgeschrieben habe, frage ich mich, wie sehr Umgebung und vielleicht sogar ein Kritikformular (mit tatsächlich dokumentierten Anforderungen) das Feedback von Benutzern beeinflussen würden.
Ich habe dies nicht getan, aber ich bin kurz davor, meine eigenen Formulare speziell zum Zwecke der Kritik zu erstellen. Dazu gehören Dinge wie „HINWEIS: Achten Sie darauf, in Ihren Kritiken kein „Ich/wir/sie“ einzufügen.“ Code könnte sogar verwendet werden, um zu erzwingen, dass bestimmte Felder diese Wörter nicht zulassen. :) Draconisch? Vielleicht, aber es würde den Punkt auf den Punkt bringen: Sei kein Idiot.
Und ich habe festgestellt, dass diejenigen, die gerne mit anderen zusammenarbeiten, soziale Regeln leicht befolgen, und diejenigen, die es nicht tun, werden wütend sein, gezwungen zu werden, sich zu verhalten, egal was passiert. Vielleicht ein Win-Win-Win.
Ich möchte hier eine Ergänzung vorschlagen, die weniger mit dem Ton als vielmehr mit dem Inhalt zu tun hat: Vermeiden Sie die Anforderung von lintbaren Änderungen.
Zu oft habe ich gesehen, wie Leute Code mit Vorschlägen wie „Abhängigkeiten sollten alphabetisch sortiert werden“, „Dies könnte ein Ternary sein“, „Verwenden Sie Tabs/Leerzeichen statt Leerzeichen/Tabs“ usw. überprüft haben. Die Verwendung eines Linters, um dies in einem Projekt durchzusetzen, ermöglicht es dem Prüfer, sich mehr auf die Absicht des Codes und nicht auf die Struktur zu konzentrieren.
Ein so wichtiger Punkt! Danke für die durchdachte Ergänzung.
Schrecklich. Sie haben einen schrecklichen Artikel geschrieben. Versuchen Sie es noch einmal.
Nur ein Scherz… Ich hatte jedoch schon Code-Reviews wie die oben genannten, leider. Danke für diese tollen Tipps!
Dieser Artikel ist auf dem richtigen Weg, aber meiner Meinung nach kann man das Persönliche aus Gruppen-Code-Reviews nie eliminieren.
Selbst wenn man die anklagende Sprache eliminiert, liegt es in der menschlichen Natur, die guten Teile des Codes zu ignorieren und sich auf Dinge zu konzentrieren, die schlecht gemacht wurden, entweder weil die Person nicht wusste, wie sie sie besser machen kann, oder weil sie keine Zeit dafür hatte (meistens letzteres, da die meisten Ingenieure versuchen, tiefer einzudringen, wenn sie Zeit haben).
Zu oft degenerieren selbst die am besten gemeinten Code-Reviews zu dem „Rockstar“ des Teams, der anderen Teammitgliedern sagt, wie sie ihren Code verbessern können.
Dies zementiert eine Hierarchie im Team und behindert die Teamarbeit.
Rock beginnt sich frustriert zu fühlen, weil er immer anderen seinen Wissensschatz gibt und sie es scheinbar nicht zu schätzen wissen.
Es macht die Leute auch nervös, wenn sie einchecken, wenn sie wissen, dass Rock ihnen erzählen wird, wie sie es mit dem neuesten und besten Feature aus der neuesten C#-Version besser hätten machen können. Also fangen sie an, Dinge doppelt zu überprüfen und herauszufinden, ob es einen besseren Weg gibt, dies zu tun, was sie langsamer macht und Rocks Position als Star des Teams festigt, weil er (und ich habe noch nie eine weibliche Rock getroffen) der schnellste und kompetenteste im Team ist.
Dies wird immer mit der Entschuldigung gerechtfertigt, dass „es die Codebasis besser macht (unausgesprochen: und die Leute einfach lernen müssen, nicht so empfindlich zu sein.)“
Aber am Ende wird Code immer noch von Menschen geschrieben. Leider müssen ihre Gefühle und Bedürfnisse berücksichtigt werden. Wenn Sie dieser Aussage nicht zustimmen, wiederholen Sie mit mir: Nicht jeder ist wie ich
Aber ich würde vermuten, dass es in den meisten Softwareteams mehr „sensible“ Leute als „Rocks“ gibt.
Deshalb bin ich immer noch gegen Code-Reviews und ich vermeide aktiv Stellenanzeigen, die in der Anzeige angeben, dass sie Team-Code-Reviews durchführen.
Ich hatte in meiner Firma noch nie Code-Reviews, aber aus anderen Gründen als denen, die Sie darlegen, ist meine Erfahrung, dass Kritiken jeglicher Art in dieselben Probleme zu fallen scheinen.
Ob es sich um Design, Fotografie, Schreiben, Redigieren, Programmieren usw. handelt… Ob von einem Teammitglied, Programmierer, Angestellten, Kunden usw. – die Auswirkung ist dieselbe. Deshalb schätze ich, was dieses Thema hervorgebracht hat.
Ich möchte nicht mehr beschuldigt werden, schlechte Qualität geliefert zu haben, als jeder andere, noch möchte ich, dass ein Kunde einen Angestellten herablassend behandelt oder diese einander herablassend behandeln.
Man kann dem Feedback nicht entkommen, Code-Reviews scheinen nur eine erzwungene Kritik zu sein. Und vielleicht ist die Frage, ob Code-Reviews durchgeführt werden sollten, ein ganz neues Thema?
Eine weitere nette Art, Beobachtungen in einem Review zu formulieren, sind Fragen – wie z.B.
„Könnten wir …?“
„Was wäre, wenn wir …?“
„Würde es funktionieren, wenn wir …“
Die schöne Folge davon ist, dass man anstatt eine Änderung vorzuschreiben, einen Dialog führt. Anstatt überlegenes Wissen zu behaupten (trotz unterlegener kontextueller Wahrnehmung!), gibt man dem ursprünglichen Autor die Möglichkeit, seine Begründung zu erklären, und eröffnet ein kollaboratives Gespräch über Alternativen.