Was sind übliche Codeüberprüfungsprozesse und was wird als schlecht angesehen?

Mein Unternehmen hat kürzlich mit der Überprüfung von formalisiertem Code begonnen. Der Prozess läuft wie folgt ab: Sie senden einen Code an einen Github, fordern einen Pull-Request an, der Code wird von ungefähr drei Personen überprüft. Wenn alle erfolgreich sind, wird Ihr Code eingegeben.

Der Prozess scheint fair zu sein, aber die drei Personen, die die Codeüberprüfungen durchführen, scheinen nicht fair zu sein. Ich stelle fest, dass ich bei der Eingabe meines Codes zur Überprüfung zwischen 100 und 200 Kommentare erhalte. Die Top-Nummer für mich war 300 Kommentare einmal. Natürlich würden Sie denken, dass es große Änderungen sind, aber dies können auch sehr kleine Änderungen mit weniger als 50 Codezeilen sein (einschließlich Komponententests). Alle Kommentare gelten als "Muss" und ohne Argument.

In diesem Sinne ist mein Hauptproblem hier, dass es ein bisschen übertrieben erscheint. Ich sprach mit der Gruppe und sie sagten mir im Grunde, dass nur, weil ich so viele Jahre in PHP entwickelt habe, ich kein "Entwickler" bin. Natürlich scheint das schmerzhafter als nicht. Außerdem stelle ich fest, dass sie in der Gruppe nicht so viele Kommentare produzieren und die meiste Zeit andere Kommentare oder Vorschläge ignorieren oder auf andere Weise ignorieren, die sie selten als gültigen Punkt akzeptieren, selbst wenn etwas kaputt ist.

Meine Frage ist also, ob das fair ist? Oder gemeinsam?

Alle Kommentare gelten als "Muss" und ohne Argument.

IMHO, das ist das eigentliche Problem, da es darin keine Priorisierung gibt. Wenn Sie 100-300 Kommentare erhalten, müssen einige von ihnen eine Priorität A (echte Bugs) haben, einige von ihnen Prio B (wahrscheinlich später zu Bugs führen) und einige von ihnen Prio C (alles andere). Sagen Sie Ihren Kollegen, dass Sie bereit sind, alle ihre Wünsche zu respektieren, aber Änderungen wirksam zu machen, und dass Ihre Zeit begrenzt ist, bestehen Sie auf einer Priorisierung. Beginnen Sie dann mit der Korrektur von Prio A, und wenn Sie danach wirklich Zeit für mehr haben, können Sie mit B beginnen (wenn Sie Glück haben, wird Ihr Chef verstehen, dass die Korrektur von Prio B und C nicht so wichtig ist, und geben Sie einige wichtigere Aufgaben, anstatt Ihre Zeit zu verschwenden).

Codeüberprüfungen können ein spaltender Prozess sein.

Sie befinden sich jedoch an einer wichtigen Kreuzung. Machen Sie eine durchdachte Analyse über ihre Überprüfung. Identifizieren sie Probleme mit der Fehlentscheidung oder heben sie schwerwiegende Fehler in Ihrem Stil und Ihrer Logik hervor?

In diesem Fall würde ich empfehlen, auf eine Lösung hinzuarbeiten (neuer Job oder neue Codeüberprüfungsprozesse).

In letzterem Fall empfehle ich, viel Code zu lesen und zu studieren, um Ihren Code auf professionelle Qualität zu bringen.

Ihren Kommentaren zufolge verwenden Ihre Kollegen den Codeüberprüfungsprozess, um eine Methodik zu vereinbaren oder den Code zu verbessern. Ich habe gerade angefangen, Code-Reviews wie Sie durchzuführen, und mir ist aufgefallen, dass wir manchmal viel über Dinge diskutieren, die nur Implementierungsansätze oder Verbesserungen sind. Dies ist überhaupt nicht schlecht, soweit es vernünftig ist (300 Kommentare sehen für mich zu viel aus, das muss wie ein roter Faden aussehen)

Möglicherweise müssen Sie einige Architekturentscheidungen zum Code treffen, bevor Sie mit der Implementierung beginnen, oder Sie stimmen nur mit der Benennung von Konventionen, Mustern und bewährten Methoden überein, damit Sie alle wissen, was als "guter Code" bezeichnet wird.

Wenn Sie Ihre Codestandards einhalten, wie Sie sagen, und der Code wie beabsichtigt funktioniert, sollte es nicht so viele Kommentare geben. Entweder verwenden sie Ihren Code als Forum oder sie belästigen Sie, weil Sie anscheinend darauf hinweisen.

Ich würde versuchen, mit mir selbst Kritik zu üben, würde versuchen, an den Gesprächen teilzunehmen und den Grund all dieser Kommentare zu sehen und vielleicht auf konstruktive Weise mit ihnen darüber zu sprechen, um zu sehen, warum sie mit Ihrem Code so unzufrieden sind und wenn Sie können Code auf eine Weise, die alle glücklich macht und die Arbeit nicht in der Codeüberprüfung hängen bleibt.

Ich habe gerade Ihre letzten Kommentare gelesen. Manchmal, wenn Sie mit dem Code nicht einverstanden sind, können Sie ihn hundert Mal durchgehen und überall Änderungen vorschlagen, die Sie nicht glücklich machen, da der wahre Grund darin besteht, dass Sie eine andere architektonische Entscheidung getroffen hätten und Sie mögen diesen Code einfach nicht, egal wie oft Sie ihn umgestalten. Wie ich oben schon sagte, müssen Sie sich vielleicht vorher auf die Herangehensweise an den Code einigen. Wenn Sie ihn schreiben, wissen Sie, was sie von ihm erwarten, und daher ist Ihr Code für sie vernünftiger.

Nach dem, was Sie sagen, scheint es mir, dass sie eine Vorurteile gegenüber PHP-Entwicklern haben und daher versuchen sie, jedes einzelne Problem zu finden, das mit Ihrem Code nicht in Ordnung ist, um ihre Aussage zu belegen

In Bezug auf die Codeüberprüfung selbst bin ich, wie Sie bereits sagten, der Meinung, dass eine so große Anzahl kleinerer Kommentare weniger hilfreich ist als ein paar gute und berechtigte Kritikpunkte. Und obwohl ich nur begrenzte Erfahrung mit Code-Überprüfungen habe, hat die folgende Technik für die Teams, in denen ich in der Vergangenheit gearbeitet habe, gut funktioniert.

• Zunächst sollte ein statischer Code-Analysator verwendet werden, um die meisten Probleme zu identifizieren, bevor die Codeüberprüfung stattfindet. ZB: Wenn Sie Ihren Code über Sonar, Lint oder einen anderen guten Code-Analyzer ausführen, können Sie die meisten kleineren Probleme beheben. Zumal Ihre Prüfer benutzerdefinierte Profile definieren können, um sicherzustellen, dass alle Elemente wie Klammern, Leerzeichen, Kommentare, die richtige Benennung von Variablen und vieles mehr vorhanden sind.
• Zweitens scheint es mir gut zu funktionieren, wenn Sie die Kommentare in verschiedene Kategorien einteilen. Zum Beispiel zwei Kategorien, in denen eine Gruppe kleine Dinge enthält, die Sie zur Kenntnis nehmen und in Zukunft anwenden sollten. Und eine zweite Gruppe für diejenigen Kommentare, die eine sofortige Änderung Ihres Codes erfordern, die ein erneutes Festschreiben und eine anschließende Überprüfung erfordern würden. Natürlich sollte die Anzahl der Kommentare in letzterer Gruppe kleiner sein.

Außerdem muss ich sagen, dass meine ersten echten Code-Reviews auch mehr Kommentare enthielten, als ich ursprünglich erwartet hatte. Allerdings habe ich das nie als schlecht empfunden. Wenn Sie weiterhin aus ihren Kommentaren lernen² und bereit sind, diese neu erlernten Techniken / Best Practices in Ihren zukünftigen Code-Einsendungen anzuwenden, sollten die Kommentare geringer werden. Das war bei mir sicher so ;-)

¹ Nach meiner Erfahrung passiert dies häufig, da viele Programmierer behaupten, PHP sei die bösartigste Programmiersprache, da sie von den unerfahrensten Programmierern verwendet wird. Ich distanziere mich von dieser Aussage, da ich glaube, dass großartige Software in jeder Sprache geschrieben werden kann!

² Angenommen, die Kommentare sind zu umfangreich, enthalten jedoch einen gewissen Wert

Ist es üblich, dass jemand routinemäßig über 100 Kommentare in seinen Codeprüfungen erhält? Würde ich nicht sagen Ist es üblich, dass Leute, deren Codequalität "zu wünschen übrig lässt", auf jeden Fall viele Kommentare bekommen.

Dies hängt jedoch auch von den "Regeln" des Codeüberprüfungsprozesses ab. JEDER hat seine eigenen Vorstellungen, wie etwas hätte getan werden sollen. Wenn Ihre Codeüberprüfung zulässt, dass Kommentare die Form "Sie sollten es auf diese Weise anstatt auf diese Weise tun" haben, werden Sie wahrscheinlich VIELE Kommentare erhalten, selbst für angemessenen Code. Wenn Ihr Prozess "Fehler" finden soll, sollte die Anzahl der Kommentare viel geringer sein.

Meiner Erfahrung nach sind Bewertungen, die "Vorschläge" für alternative Methoden zulassen, Zeitverschwender. Diese "Vorschläge" sollten einzeln außerhalb des Überprüfungsprozesses behandelt werden. Fehlerberichte sind nützlicher, da sie die Leute dazu bringen, sich auf Fehler zu konzentrieren, anstatt auf "Warum haben Sie es nicht so gemacht, wie ich es getan hätte?". Es ist auch nützlicher, weil es keinen Fehler leugnet, wenn jemand einen findet. Daher gibt es keine verletzten Gefühle, sondern wahrscheinlich Dankbarkeit.

UPDATE: Nach alledem ist ein Teil des Codes einfach nur schlecht, auch wenn er fehlerfrei ist. In diesem Fall sollte der Überprüfungskommentar ein einzelner Kommentar sein, der ungefähr so ​​aussagt. "Dieser Code muss bereinigt werden. Bitte verschieben Sie die Überprüfung, bis der Code mit [Ihrem Namen hier] besprochen wird." In diesem Fall sollte die weitere Überprüfung des Codes eingestellt werden, bis der Kommentar korrigiert ist.

UPDATE2: @Benutzer: Besprechen Sie Ihren Code / Entwurf mit einem von ihnen, während Sie ihn entwickeln, damit Sie implementieren können, wonach sie suchen, bevor Sie es auf Ihre Weise weit bringen? Ändern Sie etwas daran, wie Sie Code auf der Grundlage ihrer Vorschläge entwickeln, oder denken Sie, dass Ihr Weg in Ordnung ist? Lernst du etwas aus ihren Kommentaren?

Wenn ich der SW-Leiter eines Projekts bin, ist es meine Aufgabe, für ALLE Arbeitsprodukte verantwortlich zu sein. Wenn ich ein Arbeitsprodukt genehmige, behaupte ich, dass das Produkt akzeptabel ist. Ich möchte den Ruf haben, qualitativ hochwertige Produkte herzustellen. Ich habe also Erwartungen und werde nicht weniger als befriedigend akzeptieren. Gleichzeitig versuche ich, die Gründe für meine Vorlieben zu lehren und zu erklären. Diese Präferenzen mögen nicht immer ideal sein (besonders in den Augen anderer), aber die meisten dieser Präferenzen sind aus Erfahrung entstanden. Normalerweise eine Reaktion, um das Wiederholen der schlechten zu vermeiden. Daher gibt es einige meiner persönlichen "Stickler", die notwendig sind, um meine Zustimmung zu erhalten, ungeachtet des Pushbacks.

Auf der anderen Seite müssen Sie die Erwartungen kennen, die für die Zulassung Ihrer Arbeitsprodukte erforderlich sind. Sie können anderer Meinung sein, aber da Sie anscheinend nicht die Befugnis haben, zu herrschen, erfahren Sie, was erwartet wird. Ich bezweifle, dass das Team versucht, Sie zum Scheitern zu bringen. Wie das sie auch schlecht aussehen lässt. Zeigen Sie in diesem Zusammenhang einfach, dass Sie lernbegierig sind (auch wenn Sie es nicht sind), nehmen Sie das, was sie sagen, und tun Sie Ihr Bestes, um sich an ihre Vorlieben anzupassen. Vielleicht finden Sie die, die Sie zumindest tolerieren können, und sehen Sie, ob sie ein bisschen Handarbeit leisten, um Ihnen ihre Methoden beizubringen. Wer weiß, vielleicht lernst du dabei etwas, das deine Fähigkeiten auf die nächste Stufe hebt.

Einige wichtige Unterschiede zu unserem Team-Inspektionsprozess:

• Grundlage einer Inspektion ist eine Checkliste, die vom gesamten Team erstellt wird.
• Der Fokus liegt auf Defekten (Gegenwart und Zukunft), nicht auf Stil.
• Die 3 Inspektoren (einschließlich des Autors) sitzen zusammen, um die Kommentare durchzugehen. Es bleiben nur Kommentare mit Stimmenmehrheit.

Für 50 LOC scheinen 300 Kommentare etwas übertrieben und - wow - 3 Gutachter für jede Pull-Anfrage? Ihr Unternehmen muss über viele Ressourcen verfügen.

Meiner Erfahrung nach müssen für einen nützlichen Codeüberprüfungsprozess einige Regeln und / oder Richtlinien gelten:

• Priorität der Kommentare
• Klassifizierung von Kommentaren (Bug, Code Style, etc.)
• Vereinbarte Architektur / Design folgen
• Vereinbarter Codestil

Wenn Sie von den Reviewern keine Priorität erhalten, fragen Sie Ihren zuständigen Projektmanager / Teamleiter. Die verantwortliche Person für die Kosten sollte eine Meinung zu den Prioritäten haben.

Wenn Sie eine definierte Architektur, ein allgemeines Verständnis für die in Ihrem Projekt verwendeten Entwurfsmuster und einen vereinbarten Codestil haben, sollten sich die Überprüfungskommentare nur auf "echte Probleme" wie Sicherheitsprobleme, unbeabsichtigte Fehler und Eckfälle beziehen, die von den angegebenen nicht abgedeckt werden Architektur usw.

Wenn sich Ihr Entwicklungsteam nicht auf "Geschmacksprobleme" geeinigt hat (z. B. sollte eine Mitgliedsvariable mit "m_" beginnen), zwingt Sie jeder Prüfer, seinem Stil zu folgen, was nur Zeit- / Geldverschwendung ist.

Das klingt für mich wirklich nach einem Kommunikationsproblem. Sie haben die Erwartung, dass Ihr Code nicht schlecht genug ist, um 300 Kommentare zu verdienen. Die Rezensenten scheinen zu glauben, dass Sie viel Feedback benötigen. Das asynchrone Hin- und Herstreiten kostet viel Zeit. Zum Teufel, 300 Kommentare zu schreiben ist eine enorme Zeitverschwendung. Wenn dies nicht alle Mängel sind, ist es als neues Teammitglied möglich, dass Sie den Stil des Teams noch nicht kennen. Das ist normal und sollte gelernt werden, um das gesamte Team zu beschleunigen.

Mein Vorschlag ist, Zeit zu sparen. Beschleunigen Sie das Feedback. Ich würde:

• Machen Sie mehr Zwischenbewertungen, um zu vermeiden, dass derselbe Fehler gemacht und derselbe Kommentar 50 Mal generiert wird
• Setzen Sie sich mit einem Prüfer in Verbindung, der Ihren Code überprüft, damit Sie über die auftretenden Probleme sprechen können, und vermeiden Sie so, 300 "Probleme" zu dokumentieren, die bei der nächsten Übergabe beseitigt werden
• Koppeln Sie sich einige Zeit mit einem dieser "echten" Entwickler, während Sie den Code schreiben, um zu sehen, was sie anders machen würden

Die Leute mögen gegen Pairing argumentieren, weil "es länger dauern wird", aber das ist hier offensichtlich kein Problem.