Es scheint, dass Sie mit Ihrer Arbeit bereits ziemlich produktiv sind, da Sie sagen, dass Sie Ihre Entwicklungszeit verbessern und auch darauf warten, dass andere Ihren Code überprüfen, damit Sie fortfahren können.

Außerdem Ich würde mir keine Sorgen machen, dass Aufgaben bei der Überprüfung Sie schlecht aussehen lassen. Ganz im Gegenteil, diese ausstehenden Überprüfungen bedeuten, dass Sie bei Ihren Entwicklungsaufgaben gute Fortschritte machen, und angesichts der Situation, in der Sie die Überprüfungen nicht so schnell durchführen oder selbst durchführen können.

Ich werde noch weiter gehen und das sagen Sie sollten sich keine Sorgen machen, dass Sie Ihren Job machen und Ihre Mitarbeiter schlecht aussehen. Obwohl es für Sie eine gute Sache ist, sich Sorgen um Ihre Mitarbeiter zu machen, ist es ihr Problem, wenn sie zu lange brauchen, um die von Ihnen geleistete Arbeit zu überprüfen.

Es mag sein, dass Sie wenig Erfahrung im Team haben, aber es scheint, dass Ihre Produktivität in Ordnung ist. Denken Sie auch daran, dass es wahrscheinlich nicht Ihre Aufgabe ist, sich um die Produktivität des Teams und effiziente Überprüfungen zu kümmern. Das ist etwas, was Ihr Lead oder Manager tun sollte. Lassen Sie sich also nicht darüber quälen, dass Sie Ihr Team zum Leuchten bringen müssen. In diesem Fall ist das Setzen eines Beispiels (wie Sie in einem gelöschten Kommentar erwähnt haben) durch effiziente Bewertung eine großartige Möglichkeit, um sie zu mehr Produktivität zu ermutigen.

Eine weitere wichtige Sache, die Sie erwähnt haben (aber auch das gelöscht haben) Kommentar) ist, dass Sie mit Code Reviewing Wissen mit Ihrem Team teilen können. Die Fehler, die Sie bei den Überprüfungen möglicherweise finden, sind nichts im Vergleich zu den Erkenntnissen, Best Practices und Wissensdomänen, die Ihr Team dabei erhält. Dies ist auf lange Sicht wertvoller als das Beheben einiger Fehler einige Tage zuvor.

Apropos lange Läufe: Ihr Team scheint diese Überprüfungsstrategie erst kürzlich umgesetzt zu haben. Wenn Sie sich daran gewöhnen, wird sich Ihre Überprüfungsproduktivität sicherlich erheblich verbessern . Es wird erwartet, dass eine Lernkurve zu Beginn schwieriger wird.

Wie in den Kommentaren erwähnt, sollten Sie, wenn Ihr Team eine neue Aufgabe enthält, die alle Teammitglieder erledigen müssen (was Zeit von Ihrer Seite erfordert), auch Ihre Arbeitsbelastung entsprechend ausgleichen, damit Sie dies nicht tun. nicht überarbeitet werden.

Als letzten Vorschlag können Sie Ihre Wartezeit auf die Überprüfungen Ihres Codes besser nutzen, indem Sie Dokumentationen erstellen, zukünftige Aufgaben planen oder andere Dinge tun, die Sie aus dem Weg räumen können die Zwischenzeit. Hoffe das hilft, wünsche dir viel Glück.

Wenn Sie regelmäßig Stunden auf eine Codeüberprüfung warten, ist dies meiner Erfahrung nach normal. Sie tun das Richtige, indem Sie sich in der Zwischenzeit anderen Aufgaben widmen, auch wenn Sie einige nervige Zusammenführungen vornehmen müssen. Wie andere Antworten festgestellt haben, werden kleinere Codestapel mit größerer Wahrscheinlichkeit schnell überprüft (und die Überprüfungen sind wahrscheinlich auch von besserer Qualität).

Wenn Sie regelmäßig Tage warten Bei einer Codeüberprüfung wird dies zu einem großen Produktivitätsproblem, insbesondere wenn alle anderen Mitglieder des Teams ebenfalls Tage auf eine Überprüfung warten müssen. Da Sie sagen, dass dies eine relativ neue Strategie für Ihr Team ist, würde ich empfehlen, mit Ihrem Manager darüber zu sprechen, wie Sie eine schnellere Abwicklung fördern können. Vielleicht könnte es ein kurzes Treffen geben, in dem gute Überprüfungspraktiken sowohl für den Prüfer als auch für den Autor besprochen werden. Gelegentlich muss mein Manager bei der Arbeit unser Team daran erinnern, andere nicht ewig auf Codeüberprüfungen warten zu lassen.

Ich stimme dem anderen Beitrag zu (dass Sie sich darüber keine allzu großen Sorgen machen sollten und dass er sich gut auf Sie auswirkt). Ich möchte aber auch hinzufügen, dass ich mir zwei Möglichkeiten vorstellen kann, wie Sie möglicherweise den Umfang der "Codeüberprüfungsarbeit" für Ihre Mitarbeiter reduzieren können:

Stellen Sie sicher, dass jede Änderung so gut wie möglich getestet wird

Insbesondere, wenn Sie in einem Zyklus stecken bleiben:

1. Neue Funktion
2. Codeüberprüfung
3. Fix 1 auf Neue Funktion
4. Codeüberprüfung
5. Fix 2 auf neue Funktion
6. Codeüberprüfung
ol>

usw. usw.

Minimieren Sie die Menge an neuem / geändertem Code pro neuer Funktion

Mit anderen Worten, machen Sie nicht in zehn Zeilen, was Sie in zwei tun können. Dies ist auf jeden Fall eine gute Vorgehensweise, erleichtert aber auch Ihren Kollegen das Leben.

Refaktorieren oder formatieren Sie den Code nicht nach dem Zufallsprinzip, es sei denn, dies ist wirklich erforderlich.

Versuchen Sie, Ihre Arbeit zu verpacken und die Überprüfung zu vereinfachen. Schätzen Sie die Zeit, die zum Überprüfen der Elemente benötigt wird.

Wenn Sie viele kleine unabhängige Elemente haben, packen Sie diese in Codesätze in logische Blöcke, die innerhalb eines bestimmten Zeitraums überprüft werden können - beispielsweise innerhalb einer Stunde. Planen Sie eine Besprechung und senden Sie Links zu den Repo-Artikeln. Sprechen Sie mit dem Team und erklären Sie, dass Sie versuchen, den Rückstand durch eine Reihe von kurzen und gezielten Besprechungen zu beseitigen.

Auf der anderen Seite können Sie alles zu einer wachsenden, einzelnen Überprüfungsanfrage zusammenfassen. Aber das drängt in die Richtung, in die Sie scheinbar nicht wollen. Fügen Sie jedes Mal, wenn Sie eine neue Codeeinheit vervollständigen, diese dieser einzelnen Anforderung hinzu und aktualisieren Sie die Gesamtzeit. Es kann sein, dass die Leute einfach nicht über das Wachstum des Rückstands nachdenken. Wenn Ihr Manager eine Codeüberprüfungsanforderung sieht und diese lautet: "Dies ist eine Codeüberprüfungsanforderung für Element X, das am {x / x / x} | vor {21 Tagen} festgeschrieben wurde, Element y, das am {x / x / x} | festgeschrieben wurde {Vor 20 Tagen}, Artikel ... Es dauert ungefähr 40 Stunden, um diese 200 Artikel zu überprüfen ", es wird den Punkt nach Hause fahren.

Also werde ich hier den konträren Standpunkt vertreten. Ich habe 6 Jahre lang mit [ANONYMISIERTES GROSSES SOFTWAREUNTERNEHMEN] zusammengearbeitet und nach Durchlaufen der Hochlaufphase festgestellt, dass meine Produktivität aufgrund von obligatorischen Codeüberprüfungen in etwa 20% des vorherigen (und nachher) Plateaus liegt verschiedene Zeitzonen.

Das Argument der langfristigen Produktivität ist, gelinde gesagt, Unsinn. Sicher, zu Beginn der Lernkurve erhalten Sie einen Einblick, wie die Dinge hier gemacht werden, und Sie lernen, Ihren Stolz beiseite zu legen und Ihr Gehirn im Lama s> neu zu formatieren. Aber nach ein oder zwei Jahren? Sie kennen das Lama gut genug, vielen Dank, und viele der Bewertungskommentare wirken falsch, wenn nicht gar unwissend. Und ja, sie beeinträchtigen Ihre Produktivität und Ihren Sinn für Nützlichkeit bei der Arbeit.

Die Bewältigungsstrategien, die ich gefunden habe, sind:

• Wenn Sie in mitreden können Wer Ihren Code überprüft , nutzt diese Kraft mit Bedacht aus. Es ist gut, jemanden dazu zu bringen, Ihnen zu vertrauen, damit Ihre Codeüberprüfungen sofort mit einem Stempel versehen werden. Es ist besser, den Juckreiz einer Person (was auch immer es sein mag) so weit zu kratzen, dass sie Ihnen Perforce OWNERShip des Codes zuweist und Ihre Hände frei lässt, um alle bösen Pläne umzusetzen, die Sie haben Git und private Filialen und bleiben den Code-Reviewern so weit voraus, wie Sie es bequem verwalten können. Wenn Ihr Shop Git nicht ausführt, investieren Sie die erforderliche Zeit, um ein Gateway zwischen dem internen VCS und Git zu installieren / zu erstellen.
• Behandeln Sie es und planen Sie Für freigegebenen Code, der Tage oder Wochen hinter Ihrem Git-Tipp zurückbleibt, verschwenden Sie Zeit damit, sich auf die Änderungen anderer Personen mit besseren Verbindungen oder EQ wie Sie selbst usw. usw. zu stützen.

Dinge, die ich von mir selbst hinzufügen möchte:

• Denken Sie daran, dass jemand, der zu viel Zeit mit der Codeüberprüfung verbringt, möglicherweise auch Schwierigkeiten hat, den Code zu lesen . Ich nehme an, Sie üben Clean-Coding. Wenn nicht, stellen Sie sicher, dass Sie lesbaren Code mit aussagekräftigen Namenskonventionen und einer zufriedenstellenden Codestruktur schreiben. Vermeiden Sie knifflige Oneliners, die Ihre Teamkollegen täuschen können.

• Bringen Sie Ihren Mitarbeitern auch bei, dass es ein berechtigtes Anliegen ist und sein sollte, wenn sie eine Linie nicht klar verstehen wird in der Überprüfung als Kommentar erwähnt.

• Nehmen Sie sich mehr Zeit, um anderen zu helfen, ihre Aufgabe effizienter zu erledigen. Führen Sie mit Ihren Kollegen eine Paarprogrammierung durch. Helfen Sie ihnen, Probleme zu lösen, die sie verlangsamen. Sie werden sehen, dass sie sich nach einiger Zeit verbessern.

• Bringen Sie anderen bei, wie man eine gute Codeüberprüfung durchführt. In meinem Unternehmen fügen wir normalerweise mehr als zwei Personen zu einer einzelnen Bewertung hinzu, damit diese die Kunst der guten Bewertung von sich selbst lernen können. Im vorherigen Job ist mir so etwas wie eine Überprüfung des Paarcodes aufgefallen: Mehr als zwei Personen diskutierten von Angesicht zu Angesicht über Bedenken im Code eines anderen.

• Sie können auch etwas Zeit verbringen um die Automatisierung in Ihrem Entwicklungsprozess zu verbessern. Wenn es noch einige Teile gibt, die von Entwicklern manuell ausgeführt werden müssen, sollten Sie darüber nachdenken, Skripte dafür zu schreiben. Es kann eine schöne Bereitstellung, kontinuierliche Integration, Box-Test-Umgebung sein. Jemand erwähnte statische Analysegeräte, aber ich schlage vor, sie eher als Verbesserung zu verwenden, als Code-Überprüfungen zu ersetzen.

• Sie können Nehmen Sie sich auch mehr Zeit, um die Codeabdeckung durch Tests zu erhöhen.

Bearbeiten

• Nur eine andere Sache ist mir eingefallen Denken Sie daran: Sie können auch Ihre Freizeit nutzen, um eine Checkliste für die Codeüberprüfung zu erstellen. Es ist ein sehr nützliches Mind-Tool, um die Codeüberprüfung sehr schnell durchzuführen und nichts zu verpassen. Es könnte Ihren Kollegen sehr helfen.

Unser Entwicklerteam hat zugestimmt, dass der gesamte zum Projekt beigetragene Code überprüft werden muss.

Dies ist der Kern des Problems, und angesichts der Größe der Organisation kann dies der Fall sein unvermeidlich. Ihr Team muss diese Entscheidung basierend auf dem aktuellen Ergebnis (Erstickungsproduktivität) neu bewerten, da es schwieriger ist, Code zu lesen als ihn zu schreiben. Auf dieser Grundlage wird die Entscheidung, Code zu überprüfen, alles ist mehr als die Verdoppelung der Arbeitsbelastung aller, und Sie müssen dies als Kosten für die Entscheidung Ihres Teams berücksichtigen.

In unserem (kleineren) Geschäft tun wir Folgendes:

Phase 1: In den ersten 3 Monaten (Probezeit) wird alles überprüft. Der Entwickler lernt, wie wir Dinge tun, wie das System aufgebaut ist, wie vorhandener Code gefunden wird, den er wiederverwenden sollte (im Gegensatz zum Umschreiben / Duplizieren), Namenskonventionen, Formatierungen usw. Wir messen die Fähigkeiten / Talente des Entwicklers. Nach dieser Zeit wird der Entwickler entweder beibehalten oder losgelassen.

Angenommen, der Entwickler bleibt erhalten, wechseln wir zu Phase zwei:

Phase 2: Sobald der Entwickler die Art und Weise, wie wir codieren, verstanden hat eine bestimmte Codebasis, überprüfen sie sich selbst. Der Entwickler hat die Möglichkeit, jederzeit eine Überprüfung anzufordern, diese sind jedoch nicht obligatorisch. Sie gehen zurück und schauen sich ihr Commit an und stellen sicher, dass nichts wackelig ist. Wir vertrauen dem Entwickler und er ist dafür verantwortlich, in diesem Schritt fleißig zu sein. Commits stehen jedem zur Verfügung, sodass ein Manager oder Lead die Commits weiterhin überwachen oder abtasten kann. Dies halbiert die Kosten. Wenn ein Entwickler in diesem Schritt nicht fleißig ist, wird er angesprochen.

Ich habe festgestellt, dass die meisten großen Unternehmen Dinge, insbesondere die Entwicklung, normalerweise sehr ineffizient ausführen. Sie haben ihre Gründe, aber vieles davon ist Trägheit und Schüchternheit. Aus diesem Grund arbeite ich nicht gerne in großen Unternehmen.

Wir hatten dieses Problem bei einer früheren Firma, bei der ich gearbeitet habe. Jede einzelne Codeänderung musste eine Pull-Anfrage (PR) und eine Codeüberprüfung mit mindestens zwei Genehmigungen von Experten auf dem Gebiet durchlaufen (normalerweise genügten unsere eigenen Teammitglieder, aber die Genehmigungen bestimmter Personen wurden stärker gewichtet als andere), bevor dies möglich war in Master verschmolzen. Wir haben festgestellt, dass einige Dinge dazu beigetragen haben, den Überprüfungsprozess zu beschleunigen:

• Versuchen Sie, so wenig Änderungen wie möglich in jeder PR vorzunehmen, damit sie schneller überprüft werden können.
• Machen Sie das PR-Beschreibung so detailliert wie möglich in Bezug darauf, was Sie ändern und warum. Alle Änderungen an der Benutzeroberfläche sollten vor und nach Screenshots erfolgen. Auf diese Weise erhalten die Prüfer einen Kontext zu der Änderung, sodass sie leichter Dinge identifizieren können, die möglicherweise nicht beabsichtigt sind.
• Neue PRs werden in unserem Team Slack-Kanal veröffentlicht, um die Sichtbarkeit zu erhöhen. Wenn Sie in der Domäne eines anderen Teams arbeiten, wird die PR auch in deren Slack-Kanal veröffentlicht.
• Wenn Sie in der Domäne eines anderen Teams arbeiten, bitten Sie dieses Team zunächst um Hilfe, damit die PR dies nicht tut eine Überraschung. Es ist auch viel weniger wahrscheinlich, dass Sie Dinge so getan haben, wie Sie es lieber nicht getan hätten.
• Jedes Teammitglied verbringt jeden Morgen und Nachmittag 15 bis 30 Minuten damit, herausragende PRs zu überprüfen. Normalerweise haben wir dies als erstes am Morgen getan und als wir vom Mittagessen zurückkamen, war es weniger wahrscheinlich, dass wir es vergessen.
• Wenn eine PR mehr als 24 Stunden ohne Überprüfung vergangen ist, erinnern Sie das Team mündlich.

Zwischen all diesen haben wir eine gute Balance zwischen dem Schreiben und Überprüfen von Code gefunden und konnten so Code mit einer ziemlich konsistenten Rate liefern.

Während diese Frage mit dem Tag "Softwareindustrie" gekennzeichnet ist, ist es meines Erachtens am besten, einen Schritt zurückzutreten und sie aus branchenunabhängiger Sicht zu betrachten externer Qualitätsprüfungsschritt. Ihre Produktivität wird also nicht an der Zeit gemessen, die Ihre Aufgabe von Anfang bis Ende benötigt, sondern an der Zeit zwischen Start und Überprüfung (insgesamt, wenn mehr Arbeit erforderlich ist, um die Qualitätskontrolle zu bestehen). Dann wird diese zusätzliche Arbeit zu Ihrer Gesamtsumme hinzugefügt.

Damit Ihre persönliche Produktivität nicht in Frage kommt, verlangsamt diese externe Überprüfung Sie nicht.

Jetzt sind zwei Vorbehalte zu beachten, einer, der direkt in Ihrer Verantwortung liegt, und einer aus Sicht der Unternehmenseffizienz.
1. Zunächst möchten Sie natürlich so wenig wie möglich nacharbeiten. Einige werden erwartet, möglicherweise sogar wünschenswert, vieles ist ein Problem.
2. Zweitens, und dies ist branchenspezifischer, möchten Sie die Überprüfung Ihrer Arbeit so einfach wie möglich gestalten. Wenn die Qualitätssicherung länger dauert, weil Sie nicht die zusätzlichen Schritte unternommen haben, die erforderlich sind, um sicherzustellen, dass das Testen einfach und klar ist, kann dies Ihnen zu Füßen gelegt werden, insbesondere wenn Ihre Kollegen Schritte unternehmen, um den Testern zu helfen. Das einfache Testen kann daher als Teil der Vorbereitung auf die Überprüfung angesehen werden.