Agile Praktiken: Code-Überprüfung - Fehlgeschlagene Überprüfung oder Problem?

53

Am Ende eines zweiwöchigen Sprints hat eine Aufgabe eine Codeüberprüfung. In der Überprüfung stellen wir fest, dass eine Funktion funktioniert, lesbar ist, aber ziemlich lang ist und ein paar Code-Gerüche aufweist. Einfache Refactor-Arbeit.

Ansonsten entspricht die Aufgabe der Definition von erledigt.

Wir haben zwei Möglichkeiten.

  • Schlagen Sie die Codeüberprüfung fehl, damit das Ticket in diesem Sprint nicht geschlossen wird, und wir bemühen uns ein wenig um die Moral, da wir das Ticket nicht weitergeben können.
  • Der Refactor ist ein kleines Stück Arbeit und würde im nächsten Sprint (oder sogar bevor er beginnt) als winzige, halbe Punktgeschichte erledigt werden.

Meine Frage ist: Gibt es irgendwelche Probleme oder Überlegungen, wenn Sie ein Ticket von der Rückseite einer Überprüfung abheben, anstatt es nicht zu bestehen?

Die Ressourcen, die ich finden kann und die ich gelesen habe, sind normalerweise zu 100% oder gar nichts, aber ich finde, dass dies normalerweise nicht realistisch ist.

Erdrik Ironrose
quelle
23
Also, wenn Sie die Code-Überprüfung dafür nicht scheitern können, was ist der Zweck der Überprüfung? Im Moment scheint es Ihnen wichtig zu sein, zu prüfen, ob etwas funktioniert. Dies ist jedoch sicherlich die Aufgabe eines Tests oder Testers, nicht der Überprüfung des Codes.
VLAZ
21
Ich denke, die meisten Antworten verfehlen einen wichtigen Punkt in Ihrer Frage: Ansonsten entspricht die Aufgabe der Definition von erledigt. Sind die von Ihnen erwähnten Probleme Teil dessen, was Ihr Team als "nicht erledigt" ansieht? Oder werden diese Fragen nicht in Betracht gezogen, was eine "erledigte" Aufgabe sein sollte? Wenn Ihre Definition von "erledigt" "kein Code riecht" enthält, ist die Aufgabe einfach nicht erledigt.
Josh Teil
1
@ErdrikIronrose klingt also so, als ob die Änderung nicht dem Standard entsprach und möglicherweise nicht (so einfach) wartbar war. Obwohl Ihr anderer Kommentar darauf hinzudeuten scheint, dass die Änderung nicht Teil der Anforderung war, sollte sie in diesem Fall nicht Teil der Codeüberprüfung sein. Wenn jemand einen korrekten und auf dem neuesten Stand befindlichen Code neben einen vorhandenen hässlichen Hack schreibt, dann zögern Sie nicht, ein Ticket für die Behebung des hässlichen Hack zu erheben und die aktuelle Codeüberprüfung zu bestehen. Wenn jemand einen Code schreibt, der korrekt, aber nicht dem Standard entspricht (wie Ihre Frage angibt), schließen Sie die Codeüberprüfung erst ab, wenn er korrekt ausgeführt wurde.
VLAZ
9
@ErdrikIronrose: Ah, also der Code-Geruch wurde nicht während der Arbeit an der zu überprüfenden Geschichte erzeugt , sondern existierte bereits? Das ist ein wichtiger Unterschied - überlegen Sie, ob Sie die Frage bearbeiten möchten.
sleske
1
@ Vlaz sollten Sie eine Antwort von Ihrem Kommentar machen
Ister

Antworten:

67

Gibt es irgendwelche inhärenten Probleme oder Überlegungen beim Erheben eines Tickets von der Rückseite einer Überprüfung, anstatt es zu scheitern?

Nicht von Natur aus. Beispielsweise hat die Implementierung der aktuellen Änderung möglicherweise ein Problem aufgedeckt, das bereits vorhanden war, aber bis jetzt nicht bekannt / offensichtlich war. Ein Fehlschlagen des Tickets wäre unfair, da Sie es für etwas missachten würden, das nichts mit der tatsächlich beschriebenen Aufgabe zu tun hat.

In der Rezension entdecken wir eine Funktion

Ich vermute jedoch, dass die Funktion hier etwas ist, das durch die aktuelle Änderung hinzugefügt wurde. In diesem Fall sollte das Ticket nicht bestanden werden, da der Code den Geruchstest nicht bestanden hat.

Wo würdest du die Linie zeichnen, wenn nicht wo du sie bereits gezeichnet hast? Sie glauben eindeutig nicht, dass dieser Code sauber genug ist, um in der aktuellen Form in der Codebasis zu bleiben. Warum sollten Sie dann in Betracht ziehen, dem Ticket einen Pass zu geben?

Schlagen Sie die Codeüberprüfung fehl, damit das Ticket in diesem Sprint nicht geschlossen wird, und wir bemühen uns ein wenig um die Moral, da wir das Ticket nicht weitergeben können.

Mir kommt es so vor, als würden Sie indirekt argumentieren, dass Sie versuchen, diesem Ticket einen Pass zu geben, der der Moral des Teams zugute kommt und nicht der Qualität der Codebasis.

Wenn das der Fall ist, haben Sie Ihre Prioritäten gemischt. Der Standard für sauberen Code sollte nicht geändert werden, nur weil dies das Team glücklicher macht. Die Korrektheit und Sauberkeit des Codes hängt nicht von der Stimmung des Teams ab.

Der Refactor ist ein kleines Stück Arbeit und würde im nächsten Sprint (oder sogar bevor er beginnt) als winzige, halbe Punktgeschichte erledigt werden.

Wenn die Implementierung des Originaltickets den Code-Geruch verursacht hat, sollte dieser im Originalticket angesprochen werden. Sie sollten nur dann ein neues Ticket erstellen, wenn der Code-Geruch nicht direkt dem ursprünglichen Ticket zugeordnet werden kann (z. B. ein "Strohhalm, der den Rücken des Kamels gebrochen hat").

Die Ressourcen, die ich finden kann und die ich gelesen habe, sind normalerweise zu 100% oder gar nichts, aber ich finde, dass dies normalerweise nicht realistisch ist.

Pass / Fail ist von Natur aus ein binärer Zustand , der von Natur aus alles oder nichts ist.

Ich denke, Sie beziehen sich hier eher darauf, dass Sie Codeüberprüfungen so interpretieren, dass sie perfekten Code erfordern oder auf andere Weise fehlschlagen, und das ist nicht der Fall.

Der Code sollte nicht makellos sein, sondern einfach dem angemessenen Sauberkeitsstandard Ihres Teams / Unternehmens entsprechen. Die Einhaltung dieses Standards ist eine binäre Entscheidung: Er hält an (bestanden) oder er tut es nicht (nicht bestanden).

Anhand Ihrer Beschreibung des Problems ist klar, dass Sie nicht der Meinung sind, dass dies dem erwarteten Codestandard entspricht, und dass es daher nicht aus anderen Gründen wie der Moral des Teams weitergegeben werden sollte.

Ansonsten entspricht die Aufgabe der Definition von erledigt.

Wenn "es gelingt, die Arbeit zu erledigen" der beste Maßstab für die Codequalität wäre, müssten wir zunächst nicht das Prinzip von sauberem Code und bewährten Methoden erfinden - der Compiler- und Komponententest wäre bereits unser automatisierter Überprüfungsprozess und Sie benötigen keine Codeüberprüfungen oder Stilargumente.

Flater
quelle
26
"Die Richtigkeit und Sauberkeit des Codes hängt nicht von der Stimmung des Teams ab." +1 für dieses alleine, jedoch die einzige Einschränkung zu dieser gesamten Antwort würde das Schlagen einer Frist sein. Wenn diese Codeüberprüfung fehlschlägt, müssen Sie die Sauberkeit des Codes mit den Kundenanforderungen in Einklang bringen. Denken Sie jedoch daran, dass falscher Code, der heute die Deadline des Kunden einhält, morgen ein Produktionsproblem darstellt.
Greg Burghardt
11
Tolle Antwort - fest, aber nicht unhöflich. Ein tangentialer Punkt könnte auch sein: Wie sind wir dazu gekommen, Code-Reviews so spät im Sprint durchzuführen, dass ein einfacher Refactor nicht durchgeführt werden kann, ohne dass der gesamte Sprint fehlschlägt?
Daniel
@ Daniel: Der Entwickler ist möglicherweise anderweitig beschäftigt, oder es handelt sich um ein Planungsproblem. Die Zeit zwischen dem Beenden einer Aufgabe und dem Beenden des Sprints ist normalerweise minimal, da (in einer idealen Welt) die Leute ihre letzte Aufgabe des Sprints um die Endzeit des Sprints herum erledigen würden. Sie können keine längere Zeit zum Überprüfen / Korrigieren benötigen. oder alternativ, vielleicht ist der Entwickler für den Rest des Sprints einfach nicht anwesend / verfügbar.
Flater
8
+1 Programmierer können sich gut fühlen, wenn sie guten Code geschrieben haben. Die Umgehung Ihrer Qualitätskontrolle ist keine Antwort auf die Verbesserung der Moral. Eine gelegentliche Ablehnung kleinerer Probleme wird die Moral ohnehin nicht leiden lassen. Wenn Ihre Moral leidet, weil Sie die Qualitätskontrolle regelmäßig nicht bestehen, besteht die Antwort darin, die ganze Zeit etwas gegen eine fehlerhafte Qualitätskontrolle zu unternehmen und die Standards nicht zu verlieren.
jpmc26
1
@GregBurghardt: Da ich gesehen habe, dass das Deadline-Argument in vielen Unternehmen missbraucht wird, stimme ich einem schlechten Review nur dann zu, wenn eine Aufgabe für das sofortige Refactoring erstellt und für den ersten Sprint nach der Veröffentlichung geplant ist. Die zusätzlichen Zeitkosten erhöhen die Umgehung der Codequalität erheblich.
Flater
38

Am Ende eines 2-wöchigen Sprints und einer Aufgabe hat eine Code-Überprüfung [...] Easy Refactor Job.

Warum taucht das am Ende des Sprints auf? Eine Codeüberprüfung sollte erfolgen, sobald Sie glauben, dass der Code fertig ist (oder sogar schon zuvor). Sie sollten Ihre Definition von "erledigt" für jede abgeschlossene Story überprüfen.

Wenn Sie feststellen, dass Sie die Storys so kurz vor Ihrer Demo / Sprint-Überprüfung fertigstellen, dass Sie sie nicht für eine "kleine" Aufgabe halten können, müssen Sie Ihre Arbeit besser einschätzen können. Ja, diese Geschichte wurde nicht beendet. Nicht wegen einer Codeüberprüfung, sondern weil Sie nicht vorhatten, Änderungen aus der Codeüberprüfung zu übernehmen. Das ist so, als würde man "Testen" auf Null schätzen, denn "wenn Sie es richtig programmiert haben, wird es einfach funktionieren, oder?". So funktioniert das nicht. Beim Testen werden Fehler festgestellt, und bei der Codeüberprüfung werden Änderungen vorgenommen. Wenn es nicht wäre, wäre es eine große Zeitverschwendung.

Also, um es zusammenzufassen: Ja, das DoD ist binär. Bestehen oder Durchfallen. Eine Codeüberprüfung ist nicht binär, sondern sollte eher eine fortlaufende Aufgabe sein. Sie können nicht scheitern . Es ist ein Prozess und am Ende ist es geschafft. Aber wenn Sie nicht richtig planen, werden Sie nicht rechtzeitig zu diesem "erledigten" Stadium gelangen und am Ende des Sprints im "nicht erledigten" Gebiet festsitzen. Das ist nicht gut für die Moral, aber das müssen Sie bei der Planung berücksichtigen.

nvoigt
quelle
5
Dies ist genau die Antwort, die mir in den Sinn kam. Wenn jede Story mit einem eigenen Zweig implementiert wird, verschieben Sie das Überprüfen und Zusammenführen der Zweige nicht bis zum Ende des Sprints. Erstellen Sie stattdessen eine Abrufanforderung, sobald angenommen wird, dass die Verzweigung bereit ist, und wiederholen Sie diese Verzweigung, bis sie tatsächlich ausgeführt, genehmigt und zusammengeführt wurde. Wenn dieser Prozess am Ende des Sprints noch nicht abgeschlossen ist, ist die Geschichte noch nicht fertig.
Daniel Pryden
20

Einfach: Sie überprüfen die Änderung . Andernfalls überprüfen Sie den Status des Programms nicht. Wenn ich einen Fehler in einer Funktion mit 3.000 Zeilen behebe, überprüfen Sie, ob meine Änderungen den Fehler beheben, und das war's. Und wenn meine Änderung den Fehler behebt, akzeptieren Sie die Änderung.

Wenn Sie der Meinung sind, dass die Funktion zu lang ist, geben Sie eine Änderungsanforderung ein, um die Funktion zu verkürzen, oder teilen Sie sie auf, nachdem meine Änderung akzeptiert wurde. Diese Änderungsanforderung kann dann entsprechend ihrer Wichtigkeit priorisiert werden. Wenn die Entscheidung getroffen wird, dass das Team wichtigere Dinge zu tun hat, wird dies später erledigt.

Es wäre lächerlich, wenn Sie die Entwicklungsprioritäten während einer Codeüberprüfung festlegen könnten, und wenn Sie meine Änderung aus diesem Grund ablehnen würden, wäre dies ein Versuch, die Entwicklungsprioritäten festzulegen.

Zusammenfassend ist es absolut akzeptabel, eine Codeänderung zu akzeptieren und ein Ticket sofort zu erheben, basierend auf den Dingen, die Sie bei der Überprüfung der Änderung gesehen haben. In einigen Fällen werden Sie dies sogar tun, wenn die Änderung selbst die Probleme verursacht hat: Wenn es wichtiger ist, die Änderungen jetzt zu haben, als die Probleme zu beheben. Wenn beispielsweise andere Benutzer blockiert wurden und auf die Änderung warten, möchten Sie die Blockierung aufheben, während der Code verbessert werden kann.

gnasher729
quelle
4
Ich denke , dass dieser Fall in der Änderung war die übermäßig lange Funktion - wenn Sie eine 3000 - Line - Funktion eingeführt haben , die nicht dort vorher war (oder war eine 10 - Line - Funktion zuvor).
user3067860
3
Im Prinzip ist diese Antwort genau richtig. In der Praxis ..... Wenn alle Entwickler an bewährte Codierungsmethoden glauben und diese gegen Aufwand ausbalancieren, werden Sie wahrscheinlich nicht sehr oft auf dieses Problem stoßen, und dann ist diese Antwort genau richtig. Es scheint jedoch, dass es immer ein oder zwei Entwickler gibt, die alles schnell und schmutzig machen, um jetzt 5 Minuten zu sparen. Während sie die Stunden bis Tage oder Monate ignorieren, die sie später zur Arbeit hinzufügen. In diesen Fällen ist diese Antwort nur eine schlüpfrige Aufgabe, das gesamte System neu zu starten und zu entwerfen.
Dunk
+1, obwohl ich denke, dass Sie den letzten Absatz umformulieren sollten, um hervorzuheben, dass das Einchecken von Code mit Problemen eine absolute Ausnahme sein sollte. Ich meine, nur dass jemand gesperrt ist, ist nicht genug Entschuldigung. Das Scheitern eines einzelnen Sprints scheint auch keine ausreichende Ausrede zu sein, und sicherlich keine Ausrede, die wiederholt verwendet werden könnte.
Frax
@ user3067860 Wenn Sie eine 10-Zeilen-Funktion in eine 3000-Zeilen-Funktion umgewandelt haben, schlagen Sie eindeutig fehl. Wenn Sie eine 3000-Zeilen-Funktion in 3010 verwandelt haben - dann gehen Sie wahrscheinlich vorbei. Aber was ist, wenn Sie eine 100-Zeilen-Funktion (normalerweise etwas zu groß) in eine 300-Zeilen-Funktion ( definitiv zu groß) umgewandelt haben?
Martin Bonner unterstützt Monica
9

Schlagen Sie die Codeüberprüfung fehl, damit das Ticket in diesem Sprint nicht geschlossen wird, und wir bemühen uns ein wenig um die Moral, da wir das Ticket nicht weitergeben können.

Dies scheint das Problem zu sein.
Theoretisch weißt du, was du tun sollst, aber es ist kurz vor der Deadline, also willst du nicht das tun, von dem du weißt, dass du es tun sollst.

Die Antwort ist einfach: Tun Sie alles, was Sie tun würden, wenn Sie am ersten Tag des Sprints denselben Code für die Codeüberprüfung erhalten würden. Wenn es akzeptabel wäre, sollte es jetzt sein. Wenn es nicht wäre, würde es jetzt nicht.

xyious
quelle
"Sehr geehrter Kunde, Sie können Ihre Funktion noch 2-3 Wochen nicht nutzen, da unser Code funktioniert hat, aber wir mochten nicht, wie er aussah." !
RandomUs1r
6
@ RandomUs1r-Kunden sollten solche Informationen nicht haben. Es wurde nicht gemacht, weil nicht genug Zeit dafür war und das war's. Schreiben Kunden vor, wie Code geschrieben werden soll? Wenn Sie einen Elektriker anrufen, um die Verkabelung bei Ihnen zu Hause zu reparieren, gehen Sie dann wie folgt vor: "Tauschen Sie nur die Kabel aus, ohne zu prüfen, ob dies die richtigen Kabel sind." Oder sagen Sie Ihrem Arzt "Ich bin krank - gib mir ein paar Tabletten, aber diagnostiziere mich nicht zuerst"? Codeüberprüfungen sollten ein fester Bestandteil der Arbeit sein, nicht etwas, was der Kunde vorschreibt.
VLAZ
1
@ RandomUs1r: „“? Lieber Entwickler, warum die Funktion nicht abgeschlossen wurde „ - die Antwort sollte sein,‚weil wir nicht genug Zeit , um zu bauen auf ein vertretbares Maß an Qualität haben‘ vielleicht gefolgt von“ Wir können es geben an Sie, wenn Sie bereit sind, bei der Qualität Kompromisse einzugehen. "
Bryan Oakley
1
@ RandomUs1r Sie möchten also im Grunde genommen die Codequalität opfern, was die spätere Implementierung von Funktionen erheblich erschwert. Ein Fix für 2 Tage könnte Ihnen sehr gut 4 Wochen später ersparen. Dann heißt es also: "Lieber Kunde, Sie können Ihre Funktion noch 2-3 Wochen nicht nutzen, da die Implementierung einer kleineren Funktion jetzt so lange dauert." Auch ist es das Ende eines Sprints oder ist es eine wichtige Frist? Wenn es sich um eine wichtige Frist handelt, könnte ich sehen, dass sie jetzt verschmilzt, in den nächsten zwei Tagen einen Fix schreibt und unmittelbar nach Ablauf der Frist eine PR-Anzeige erstellt.
Xyious
5
Ich sage nur, wenn Ihre Standards am ersten und am letzten Tag des Sprints unterschiedlich sind, dann haben Sie keinen Standard und Ihre Qualität wird unweigerlich den Bach runtergehen.
Xyious
5

Ein großer Teil des Prozesses besteht darin, zu entscheiden, was getan wird , und an Ihren Waffen festzuhalten. Es bedeutet auch, dass Sie Ihre Peer-Reviews nicht zu lange ausführen müssen, damit die Tests sicherstellen, dass die Arbeit auch funktionell abgeschlossen ist.

Wenn es um Codeüberprüfungsprobleme geht, gibt es einige Möglichkeiten, wie Sie damit umgehen können, und die richtige Wahl hängt von einigen Faktoren ab.

  • Sie können den Code einfach selbst bereinigen und der Person mitteilen, was Sie getan haben. Bietet einige Mentoring-Möglichkeiten, aber dies sollten ziemlich einfache Dinge sein, die in wenigen Minuten erledigt werden können.
  • Sie können sich mit Kommentaren zurücklehnen , was falsch ist. Wenn die Fehlerbehandlung schlecht durchgeführt wird oder der Entwickler dieselben Fehler wiederholt, kann dies gerechtfertigt sein.
  • Sie können ein Ticket erstellen und technische Schulden machen. Das Ticket ist da, um sicherzustellen, dass Sie es später bezahlen. Es kann sein, dass Sie sich in einer schwierigen Zeit befinden und bei der Überprüfung der Änderungen ein größeres Problem feststellen, das nicht direkt mit der Änderung zusammenhängt.

Fazit: Wenn Sie mit der Arbeit fertig sind, müssen Sie damit fertig sein. Wenn es Probleme gibt, die größer sind als die, an denen der Entwickler gearbeitet hat, heben Sie die Flagge und fahren Sie fort. Sie sollten sich jedoch nicht in einer Position befinden, in der es Stunden vor dem Ende des Sprints liegt, und Sie müssen sich gerade einer Peer Review unterziehen. Das riecht nach Überbeanspruchung Ihrer Ressourcen oder nach Aufschieben der Peer Reviews. (ein Prozessgeruch).

Berin Loritsch
quelle
4

Es gibt keine inhärenten Probleme bei der Depriorisierung von Codeüberprüfungsproblemen, aber es klingt so, als ob die Hauptprobleme, auf die Sie sich als Team einigen müssen, folgende sind:

  1. Was ist der Zweck Ihrer Codeüberprüfung?
  2. In welcher Beziehung stehen die Ergebnisse der Codeüberprüfung zur Definition von "Fertig" für ein Arbeitselement?
  3. Welche Probleme werden als "Blocker" eingestuft, wenn die Codeüberprüfung als Gating-Test gilt?

Dies alles hängt von dem ab, was das Team als Definition von Done vereinbart hat. Wenn das Bestehen der Codeüberprüfung mit Zero Issues für ein Arbeitselement als erledigt definiert ist, können Sie kein Element schließen, das diese Anforderung nicht erfüllt.

Es ist das gleiche, als ob während des Unit-Tests ein Unit-Test fehlgeschlagen wäre. Sie würden den Fehler beheben und den Komponententest nicht ignorieren, wenn das Bestehen von Komponententests eine Voraussetzung dafür wäre.

Wenn das Team nicht zugestimmt hat, dass Codeüberprüfungen eine Definition von "Fertig" sind, sind Ihre Codeüberprüfungen kein Gating-Akzeptanztest für das Arbeitselement. Sie sind eine Teamaktivität, die Teil Ihres Backlog-Prozesses ist, um nach zusätzlicher Arbeit zu suchen, die möglicherweise benötigt wird. In diesem Fall haben alle Probleme, die Sie entdecken, nichts mit den Anforderungen des ursprünglichen Arbeitselements zu tun und sind neue Arbeitselemente, die das Team priorisieren muss.

Beispielsweise kann es durchaus akzeptabel sein, dass ein Team die Korrektur von Tippfehlern in einigen Variablennamen außer Kraft setzt, da dies keine Auswirkungen auf die bereitgestellte Geschäftsfunktionalität hat, obwohl das Team den Variablennamen "myObkect" wirklich hasst.

Jay S
quelle
1

Die höher gestimmten Antworten hier sind sehr gut; Dieser befasst sich mit dem Refactoring-Winkel.

In den meisten Fällen besteht die meiste Arbeit beim Refactoring darin, den vorhandenen Code zu verstehen. Eine Änderung danach ist in der Regel der kleinere Teil der Arbeit, und zwar aus einem von zwei Gründen:

  1. Wenn nur der Code klarer und / oder präziser formuliert wird, sind die notwendigen Änderungen offensichtlich. Oft haben Sie Ihr Verständnis für den Code gewonnen, indem Sie Änderungen ausprobiert haben, die sauberer erschienen, und herausgefunden haben, ob sie tatsächlich funktionierten oder im komplexeren Code einige Feinheiten übersehen haben.

  2. Sie haben bereits ein bestimmtes Design oder eine bestimmte Struktur im Sinn, die Sie benötigen, um das Erstellen eines neuen Features zu vereinfachen. In diesem Fall war die Arbeit, dieses Design zu entwickeln, Teil der Geschichte, die die Notwendigkeit dafür erzeugte. Es ist unabhängig davon, dass Sie ein Refactoring durchführen müssen, um zu diesem Design zu gelangen.

Das Erlernen und Verstehen von vorhandenem Code ist eine Menge Arbeit für einen nicht dauerhaften Nutzen (in einem Monat hat wahrscheinlich jemand viel über den Code vergessen, wenn er in dieser Zeit nicht weiter liest oder damit arbeitet) Dies ist nur in Codebereichen sinnvoll, die Probleme verursachen oder die Sie in naher Zukunft ändern möchten. Da dies wiederum die Hauptaufgabe des Refactorings ist, sollten Sie das Refactoring nicht für Code ausführen, es sei denn, dies verursacht derzeit Probleme oder Sie planen, es in naher Zukunft zu ändern.

Aber es gibt eine Ausnahme: Wenn jemand derzeit ein gutes Verständnis für den Code hat, der im Laufe der Zeit verloren geht, kann es eine gute Investition sein, dieses Verständnis zu verwenden, um den Code später klarer und schneller zu verstehen. Das ist die Situation, in der sich jemand befindet, der gerade mit der Entwicklung einer Geschichte fertig ist.

Der Refactor ist ein kleines Stück Arbeit und würde im nächsten Sprint (oder sogar bevor er beginnt) als winzige, halbe Punktgeschichte erledigt werden.

In diesem Fall ist der Gedanke, eine separate Story für das Refactoring zu erstellen, ein Warnsignal an mehreren Fronten:

  1. Sie denken nicht an Refactoring als Teil der Codierung, sondern an eine separate Operation, die es wahrscheinlich macht, dass es unter Druck gerät.

  2. Sie entwickeln Code, der mehr Arbeit zum Verstehen bedeutet, wenn das nächste Mal jemand damit arbeiten muss, sodass die Erstellung von Geschichten länger dauert.

  3. Sie verschwenden möglicherweise Zeit und Energie, um Dinge umzugestalten, von denen Sie nicht viel profitieren. (Wenn eine Änderung viel später erfolgt, muss trotzdem noch jemand den Code verstehen. Dies ist effizienter in Verbindung mit dem Refactoring-Job. Wenn eine Änderung nicht später erfolgt, hat das Refactoring keine Wirkung gezeigt.) Zweck überhaupt, außer vielleicht eine ästhetische.)

Die Antwort hier ist also, das Element zu verfehlen, um zu verdeutlichen, dass etwas in Ihrem Prozess fehlgeschlagen ist (in diesem Fall ist dies der Entwickler oder das Team, das keine Zeit für die Überprüfung und die Implementierung von Änderungen reserviert hat, die sich aus der Überprüfung ergeben), und den Entwickler sofort mit der Arbeit fortfahren zu lassen auf dem Artikel.

Wenn Sie die Schätzung für die nächste Iteration vornehmen , schätzen Sie die vorhandene Story neu ein, da noch viel Arbeit zu leisten ist, damit sie überprüft und Ihrer nächsten Iteration hinzugefügt werden kann, wobei die Schätzung aus der vorherigen Iteration beibehalten wird. Wenn die Story am Ende der nächsten Iteration abgeschlossen ist, setzen Sie die historische Gesamtarbeitsmenge auf die Summe der ersten und zweiten Schätzung, damit Sie wissen, wie viel geschätzte Arbeit tatsächlich in sie gesteckt wurde. Auf diese Weise können Sie in Zukunft genauere Schätzungen ähnlicher Storys zum aktuellen Stand Ihres Prozesses erstellen. (Gehen Sie also nicht davon aus, dass Ihre offensichtliche Unterschätzung nicht erneut auftritt. Gehen Sie davon aus, dass sie erneut auftritt, bis Sie ähnliche Storys erfolgreich abgeschlossen haben und weniger Arbeit leisten.)

Curt J. Sampson
quelle
1

Ich bin überrascht, dass in den Antworten und Kommentaren zu dem Begriff "Fehlschlagen" einer Codeüberprüfung keine Antwort gefunden wurde, da dies kein Konzept ist, mit dem ich persönlich vertraut bin. Weder würde ich mit diesem Konzept noch mit jemandem in meinem Team zufrieden sein, der diese Terminologie verwendet.

Ihre Frage bezieht sich ausdrücklich auf "agile Praktiken". Schauen wir uns das agile Manifest noch einmal an (Hervorhebung von mir):

Wir entdecken bessere Wege, um Software zu entwickeln, indem wir dies tun und anderen dabei helfen. Durch diese Arbeit sind wir zu Wert gekommen:

  • Individuen und Interaktionen über Prozesse und Werkzeuge
  • Arbeitssoftware über umfangreiche Dokumentation
  • Zusammenarbeit der Kunden bei Vertragsverhandlungen
  • Reagieren, um nach einem Plan umzuschalten

Das heißt, während es Wert in den Gegenständen auf der rechten Seite gibt, schätzen wir die Gegenstände auf der linken Seite mehr.

Sprechen Sie mit Ihrem Team. Besprechen Sie den fraglichen Code. Bewerten Sie die Kosten und den Nutzen und entscheiden Sie - als zusammenhängende Expertengruppe -, ob Sie diesen Kodex jetzt, später oder nie überarbeiten möchten.

Beginnen Sie mit der Zusammenarbeit. Stoppen Sie fehlerhafte Codeüberprüfungen.

Ameise P
quelle
Ich bin alle für die Zusammenarbeit. Aber welchen Begriff würden Sie verwenden, wenn Sie nicht "scheitern"? Selbst wenn man als Gruppe diskutiert, würde eine Person sagen, "das ist nicht gut genug, es muss umgestaltet werden", was einfach bedeutet, dass die Qualitätsprüfung nicht bestanden wurde, oder?
Erdrik Ironrose
1
@ErdrikIronrose Ich habe noch nie die Terminologie "Fehlschlagen" einer Codeüberprüfung verwendet - oder musste sie verwenden. Jemand überprüft den Code, woraufhin eine Diskussion über mögliche Verbesserungspunkte und eine Entscheidung über die Behebung dieser Punkte erfolgt. Es gibt kein "Bestehen" oder "Versagen", sondern nur Kommunikation und Fortschritt. Ich bin mir nicht sicher, warum ein Stempel benötigt wird.
Ant P
0

In der Rezension entdecken wir eine Funktion, die funktioniert, lesbar ist, aber ziemlich lang ist und ein paar Code-Gerüche hat ...

Gibt es irgendwelche inhärenten Probleme oder Überlegungen beim Erheben eines Tickets von der Rückseite einer Überprüfung, anstatt es zu scheitern?

Kein Problem (nach Meinung meines Teams). Ich gehe davon aus, dass der Code die im Ticket angegebenen Akzeptanzkriterien erfüllt (dh, es funktioniert). Erstellen Sie ein Rückstandselement, um die Länge und den Geruch von Code zu ermitteln, und priorisieren Sie es wie jedes andere Ticket. Wenn es wirklich klein ist, dann priorisieren Sie es einfach für den nächsten Sprint.

Eines der Sprüche, die wir haben, lautet: "Wähle progressive Verbesserung gegenüber aufgeschobener Perfektion".

Wir haben einen sehr flüssigen Prozess und bauen eine ziemlich gute Anzahl von Proof-of-Concept-Funktionen auf (1 oder 2 pro Sprint), die es durch Entwicklung und Test schaffen, aber niemals durch interne Stakeholder-Überprüfungen (hmm, können wir dies stattdessen tun) ?), Alpha oder Beta ... manche überleben, manche nicht.

Bei dem aktuellen Projekt habe ich den Überblick verloren, wie oft wir ein bestimmtes Feature erstellt, in die Hände der Stakeholder gegeben und ein oder zwei Sprints später vollständig entfernt haben, weil sich die Produktrichtung geändert hat oder Anforderungen entstanden sind eine komplette Neufassung, wie das Feature implementiert werden sollte. Verbleibende "Verfeinerungs" -Aufgaben für ein gelöschtes Feature oder für ein Feature, das nicht den neuen Anforderungen entspricht, werden gelöscht.

railsdog
quelle
0

Meiner Meinung nach gibt es zwei Möglichkeiten, dieses Problem zu betrachten:

  1. Der akademische Weg
  2. Der Weg in die reale Welt

Akademisch gesehen schlagen die meisten Codeüberprüfungsprozesse fehl, wenn die Bereitstellung einer PBI (Product Backlog Item) fehlschlägt, wenn der Codequalitätsstandard nicht erfüllt wird.

In der realen Welt folgt jedoch niemand dem T agil, da aus einem (von vielen Gründen) unterschiedliche Branchen unterschiedliche Anforderungen haben. Dabei sollte im Einzelfall entschieden werden, ob der Code jetzt festgelegt wird oder ob eine technische Verschuldung vorgenommen wird (Sie würden höchstwahrscheinlich eine neue PBI erstellen). Wenn dies den Sprint oder eine Veröffentlichung gefährden oder ein unangemessenes Risiko mit sich bringen soll, sollten die Geschäftsinteressenten in die Entscheidung einbezogen werden.

RandomUs1r
quelle
2
niemand in der realen Welt folgt dem T agil - es wird nicht mehr "agil" sein, wenn wir zu strenge Regeln haben, oder?
Paŭlo Ebermann
@ PaŭloEbermann Ich hatte ein amüsantes Gespräch mit einem Unternehmen, mit dem ich einmal gesprochen habe. Sie behaupteten, ihr Prozess sei nicht agil, weil es kein Lehrbuchbeispiel für Agilität sei. Obwohl alles, was sie taten, im Geist der Agilität war. Ich habe sie darauf hingewiesen, wurde aber nur (im Wesentlichen) mit "Nein, wir halten uns nicht an ein etabliertes agiles Verfahren, auch wenn wir die Konzepte stark ausleihen. Deshalb sind wir nicht agil" konfrontiert. Es war ziemlich bizarr.
VLAZ
Wie andere Rezensenten bereits betont haben, kann in diesem Fall möglicherweise eine Lektion daraus gezogen werden, dass der Code die Rezension nicht wirklich bestanden hat. Für mich sieht es so aus, als ob die Leute in diesem Projekt nicht wirklich verstehen, dass a) Sie Zeit für die Überprüfung und Korrekturen für jede Geschichte lassen müssen und b) das Refactoring, das erforderlich ist, um sauberen Code zurückzulassen, ein wesentlicher Teil der Geschichte. In diesem Fall ist es das Beste, die Geschichte zu verfehlen, um zu verdeutlichen, dass diese Dinge wirklich nicht optional sind.
Curt J. Sampson
@Curt Ich verstehe, dass meine Ansicht vom Standpunkt eines Entwicklers aus unbeliebt ist (ich bin übrigens auch ein Entwickler), aber das Geschäft sollte wirklich an erster Stelle stehen, sie unterschreiben die Gehaltsschecks und das verdient etwas Respekt. Was die Zeit angeht, werde ich Ihr Verständnis der realen Welt erneut in Frage stellen, und Sie müssen feststellen, dass dies nicht immer möglich ist und viele Sprints eng werden, da Entwickler auch am Ende des Sprints Aufgaben erledigen müssen. Es ist nicht so, als ob der Code SOLID ist. Eine Abteilung kann alle 2 Wochen 1/10 Tage auf die Beine treten und nichts tun, was kurzfristig großartig sein könnte, aber nicht lebensfähig ist.
RandomUs1r
@ RandomUs1r Ich arbeite auch in der realen Welt, nehme die ganze Zeit Verknüpfungen und stelle das Geschäft immer an die erste Stelle, also glaube ich nicht, dass mir hier das Verständnis fehlt. Die Beschreibung des OP lautete jedoch nicht "Normalerweise verstehen wir das immer richtig und dies war nur ein kleiner Rülpser", sonst hätte er die Frage nicht gestellt. Wie ich in meiner Antwort erklärt habe , sieht es wie ein Prozessproblem aus, und Sie können dies beheben, indem Sie den Prozess korrekt üben, bevor Sie sich damit entspannen.
Curt J. Sampson
-2

Weder noch . Wenn die Codeüberprüfung fehlschlägt, ist die Aufgabe nicht erledigt. Aber Sie können Codeüberprüfungen auf persönlicher Meinung nicht scheitern. Der Code ist bestanden. Fahren Sie mit der nächsten Aufgabe fort.

Es sollte ein einfacher Anruf sein, und die Tatsache, dass dies nicht der Fall ist, deutet darauf hin, dass Sie nicht genügend klare Regeln für die Codeüberprüfung haben.

  1. Msgstr "Die Funktion ist ziemlich lang". Notieren Sie sich: Funktionen müssen kürzer als X Zeilen sein (ich behaupte nicht , dass Regeln über die Länge von Funktionen eine gute Sache sind).

  2. Msgstr "Es gibt einige Codegerüche". Notieren Sie sich: Für öffentliche Funktionen müssen Komponententests für Funktionalität und Leistung durchgeführt werden. Sowohl die CPU- als auch die Speichernutzung müssen innerhalb der Grenzen x und y liegen.

Wenn Sie die Regeln für das Bestehen einer Codeüberprüfung nicht quantifizieren können, erhalten Sie den folgenden Fall: "Code, den Sie nicht mögen".

Sollten Sie versagen "Code, den Sie nicht mögen"? Ich würde nein sagen. Du wirst natürlich anfangen zu bestehen / scheitern, basierend auf nicht-Code Aspekten: Magst du die Person? Argumentieren sie stark für ihren Fall oder tun sie einfach, was ihnen gesagt wird? Übergeben sie Ihren Code, wenn sie Sie überprüfen?

Außerdem fügen Sie dem Schätzprozess einen nicht quantifizierbaren Schritt hinzu. Ich schätze eine Aufgabe basierend darauf, wie ich denke, dass sie programmiert werden sollte, aber am Ende muss ich den Codierungsstil ändern.

Wie lange wird das noch dauern? Wird derselbe Prüfer die nachfolgende Codeüberprüfung durchführen und dem ersten Prüfer zustimmen oder werden zusätzliche Änderungen festgestellt? Was ist, wenn ich mit der Änderung nicht einverstanden bin und sie ablehne, während ich nach einer zweiten Meinung suche oder den Fall argumentiere?

Wenn Sie möchten, dass Aufgaben schnell erledigt werden, müssen Sie sie so spezifisch wie möglich gestalten. Das Hinzufügen eines vagen Qualitätsfensters trägt nicht zu Ihrer Produktivität bei.

Re: Es ist unmöglich, die Regeln aufzuschreiben !!

Es ist nicht wirklich so schwer. Du meinst wirklich "Ich kann nicht ausdrücken, was ich mit 'gutem' Code meine" . Sobald Sie das erkennen, können Sie sehen, dass es offensichtlich ein HR-Problem ist, wenn Sie anfangen zu sagen, dass die Arbeit eines anderen nicht auf dem neuesten Stand ist, aber Sie können nicht sagen, warum.

Schreiben Sie die Regeln auf, die Sie können, und diskutieren Sie darüber, was Code „gut“ macht.

Ewan
quelle
6
Nein, Sie übersehen den Punkt, dass "ein perfekter und universell anwendbarer Standard ohne Mehrdeutigkeiten" keine realistische Voraussetzung für die Durchführung von Code-Überprüfungen ist. Es wird immer neue Arten von Problemen geben, die Sie noch nicht berücksichtigt haben, und daher müssen Sie in der Lage sein, eine Entscheidung auf unbekanntem Gebiet zu treffen. Natürlich sollten Sie diese Entscheidung dann dokumentieren, damit sie kein Neuland mehr ist, aber Ihre Antwort beruht auf der Annahme, dass Sie die Abwesenheit von Neuland irgendwie garantieren können, wenn Sie nur die perfekten Regeln vor der Überprüfung entwerfen. Sie stellen den Karren vor das Pferd.
Flater
5
Absolute Werte wie "Funktionen müssen kürzer als x Zeilen sein" sind ebenfalls keine Lösung .
Blrfl
2
Einverstanden mit Blrfl. Funktionen (im Allgemeinen) sollten nicht mehr als 20 Zeilen umfassen. Aber es zur absoluten Regel zu machen, ist ein Fehler. Besondere Umstände haben immer Vorrang vor allgemeinen Regeln: Wenn Sie einen guten Grund haben, Ihre Funktion auf mehr als 20 Zeilen zu beschränken, dann tun Sie dies.
Matt Messersmith
1
Sie sollten keine Regeln für Code benötigen, der gemäß einer gesetzlichen Spezifikation geschrieben wurde ... Sie können nur Richtlinien sowie die Tatsache haben, dass Sie vermutlich alle Erwachsene sind, die versuchen, dasselbe Ziel zu erreichen (funktionierender, lesbarer, wartbarer Code). Es ist von zentraler Bedeutung für Scrum, dass alle Teammitglieder wirklich in das Team investiert sind und bereit sind, zusammenzuarbeiten. Wenn Sie das nicht haben, ist Scrum vielleicht sowieso nicht für Ihr Team.
user3067860
2
@Ewan Sicher. Mein Punkt war nur , dass die OP eine Länge von Funktion hat Leitlinie , keine Regel. Überall dort, wo der Schwellenwert festgelegt ist, wird empfohlen, schwer zu verwaltenden Code zu erkennen. Dies ist jedoch keine absolute Regel. Wenn es (wie das OP sagt) tatsächlich perfekt lesbar ist und die Prüfer zustimmen, dass es perfekt lesbar ist und es keine Probleme gibt, es angemessen zu testen, dann hat die Funktion per Definition die richtige Größe. Die Rezension erhält möglicherweise eine einzeilige Notiz mit der Aufschrift "Ja, es ist länger als empfohlen, aber wir sind uns einig, dass es in Ordnung ist", und die Arbeit ist erledigt. Refactoring nach diesem Zeitpunkt ist eine Vergoldung.
Graham