it-swarm.com.de

Sollte ich einen Fehler aufzeichnen, den ich entdeckt und gepatcht habe?

Ich nehme an, dass dies eine häufige Situation ist: Ich teste Code, entdecke einen Fehler, behebe ihn und übertrage die Fehlerbehebung an das Repository. Angenommen, viele Leute arbeiten an diesem Projekt, sollte ich zuerst einen Fehlerbericht erstellen, ihn mir selbst zuweisen und in der Festschreibungsnachricht darauf verweisen (z. B. "Fehler #XYZ beheben. Der Fehler war auf X und Y zurückzuführen. Behebung durch Q und R ")? Alternativ kann ich den Fehlerbericht überspringen und mit einer Meldung wie "Ein Fehler wurde behoben, der A bei B verursachte. Der Fehler war auf X und Y zurückzuführen. Es wurde durch Q und R behoben" behoben.

Was wird als bessere Praxis angesehen?

68
David D

Es hängt davon ab, wer das Publikum eines Fehlerberichts ist.

Wenn es nur intern von Entwicklern betrachtet wird, um zu wissen, was behoben werden muss, dann stören Sie sich nicht. An diesem Punkt ist es nur Lärm.

Nicht erschöpfende Liste der Gründe für die Anmeldung:

  • Die Versionshinweise enthalten Informationen zu behobenen Fehlern (bis zu einem bestimmten Schwellenwert, den dieser Fehler erreicht) - insbesondere, wenn durch diesen Fehler eine Sicherheitsanfälligkeit vorliegt
  • Das Management möchte den Begriff "Zeitaufwand für die Fehlerbehebung"/"Anzahl der erkannten Fehler" usw.
  • Kunden können den aktuellen Status des Bugtrackers anzeigen (um festzustellen, ob ihr Problem bekannt ist usw.).
  • Tester erhalten Informationen zu einer Änderung, auf die sie testen sollten.
71
Caleth

Ich würde sagen, es hängt davon ab, ob Ihr Produkt mit dem Fehler veröffentlicht wurde oder nicht.

Wenn es mit dem gefundenen Fehler veröffentlicht wurde, erstellen Sie einen Fehlerbericht. Release-Zyklen können oft lang sein und Sie möchten nicht, dass Ihr Fehler als neues Problem gemeldet wird, solange Sie ihn bereits behoben haben.

Wenn Ihr Fehler noch nicht ausgeliefert wurde, würde ich nicht den gleichen Weg gehen. Sie werden jetzt Leute haben, die versuchen, Ihren Fehler neu zu erstellen, was sie nicht können, weil er noch nicht in einer Version enthalten ist, was im Wesentlichen ihre Zeit verschwendet.

52
Pieter B

Sie sollten dies tun, wenn es sich um einen Fehler handelt, der von einem Kunden gemeldet werden könnte. Schlimmster Fall: Sie beheben den Fehler, aber niemand weiß es. Der Kunde meldet den Fehler. Ihr Kollege versucht, den Fehler zu beheben, kann ihn jedoch nicht reproduzieren (da Sie ihn bereits behoben haben). Deshalb möchten Sie eine Aufzeichnung des Fehlers.

Dies ist auch nützlich, wenn Sie Codeüberprüfungen durchführen, bei denen normalerweise Code für eine Aufgabe geschrieben und dann überprüft wird. In diesem Fall ist es besser, diese Fehlerbehebung zu isolieren, was möglicherweise erfordert, dass Sie etwas in Ihre Aufgabenliste aufnehmen und dann die ganze Arbeit erledigen.

24
gnasher729

Dies hängt von mehreren Faktoren ab.

Sowohl Pieter B als auch Caleth listen einige in ihren Antworten auf:

  • War der Fehler Teil einer offiziellen Veröffentlichung?
  • Wird die Anzahl der Fehler/die dafür aufgewendete Zeit speziell erfasst?

Es können auch interne Verfahren befolgt werden, die häufig durch die Anforderungen einer Zertifizierung abgesichert sind. Für bestimmte Zertifikate muss jede Codeänderung auf einen Datensatz in einem Issue-Tracker zurückgeführt werden können.

Außerdem sind manchmal sogar trivial aussehende Bugfixes nicht so trivial und unschuldig, wie sie zuerst erscheinen. Wenn Sie einen solchen Bugfix stillschweigend zur Übermittlung eines nicht verwandten Problems bündeln und sich der Bugfix später als problematisch herausstellt, wird es viel schwieriger, ihn aufzuspüren, geschweige denn zu isolieren oder zurückzusetzen.

Diese Frage kann nur von Ihrem Projektleiter oder demjenigen, der für den "Ticketing-Prozess" verantwortlich ist, wirklich beantwortet werden.

Aber lassen Sie mich andersherum fragen: Warum sollten Sie nicht einen Fehler aufzeichnen, den Sie gepatcht haben?

Der einzige unergründliche Grund, den ich sehe, ist, dass der Aufwand, den Fehlerbericht einzureichen, sich dagegen zu verpflichten und ihn zu schließen, um Größenordnungen größer ist als die Zeit, um den Fehler zu beheben.

In diesem Fall besteht das Problem nicht darin, dass der Fehler so einfach zu beheben ist, sondern dass der Papierkram zu lange dauert. Das sollte es wirklich nicht. Für mich besteht der Aufwand für die Erstellung eines Jira-Tickets darin, c zu drücken, dann eine kurze einzeilige Zusammenfassung einzugeben und Enter zu drücken. Die Beschreibung ist nicht einmal Overhead, da ich sie zusammen mit der Ausgabenummer ausschneiden und in die Festschreibungsnachricht einfügen kann. Am Ende, . c <Enter> und das Problem ist geschlossen. Das läuft auf 5 Tastendrücke hinaus.

Ich weiß nichts über dich, aber das ist wenig genug, um es selbst in kleinen Projekten zu einer Richtlinie zu machen, um jeden Bugfix auf diese Weise aufzuzeichnen.

Der Vorteil liegt auf der Hand: Es gibt einige Leute, die problemlos mit einem Ticketsystem wie Jira arbeiten können, aber nicht mit dem Quellcode. Es werden auch Berichte aus dem Ticketsystem generiert, jedoch nicht aus der Quelle. Sie möchten auf jeden Fall, dass Ihre Fehlerkorrekturen darin enthalten sind, um Informationen über mögliche Entwicklungen zu erhalten, wie z. B. einen stetig wachsenden Zustrom kleiner 1-Zeilen-Fehlerkorrekturen, die Ihnen einen Einblick in Prozessprobleme oder was auch immer geben können. Zum Beispiel warum müssen Sie solche kleinen Fehlerbehebungen häufig durchführen (vorausgesetzt, es kommt häufig vor)? Kann es sein, dass Ihre Tests nicht gut genug sind? War der Bugfix eine Domainänderung oder ein Codefehler? Usw.

3
AnoE

Die Regel, der ich folge, lautet: Wenn der Abschnitt, an dem Sie arbeiten, noch nie veröffentlicht wurde und noch nicht einmal ausgeführt wird und kein Benutzer ihn jemals gesehen hat, beheben Sie jeden kleinen Fehler, den Sie schnell sehen, und fahren Sie fort. Sobald die Software veröffentlicht wurde und in Produktion ist und einige Benutzer sie gesehen haben, erhält jeder Fehler, den Sie sehen, einen Fehlerbericht und wird überprüft.

Ich habe festgestellt, dass das, was ich für einen Fehler halte, eine Funktion für jemand anderen ist. Indem ich Fehler behebe, ohne diese Fehler überprüfen zu lassen, kann es sein, dass ich einen Fehler erstelle, anstatt ihn zu beheben. Geben Sie in den Fehlerbericht ein, welche Zeilen Sie ändern würden, um den Fehler zu beheben, und planen Sie, wie er behoben werden soll.

Zusammenfassend: Wenn dieses Modul noch nie in Produktion war, beheben Sie jeden Fehler, den Sie sehen, schnell und befolgen Sie die Spezifikation. Wenn das Modul bereits in Produktion ist, melden Sie jeden Fehler als Fehlerbericht, der vor der Behebung überprüft werden muss. =

2
Russell Hankins

Ja.


Es gibt bereits einige Antworten, die Situationen aufdecken, in denen es sich lohnt, einen Fehlerbericht zu erstellen. Einige Antworten. Und sie unterscheiden sich.

Die einzige Antwort ist, dass niemand weiß. Unterschiedliche Personen zu unterschiedlichen Zeiten haben unterschiedliche Meinungen zu diesem Thema.

Wenn Sie also auf einen Fehler stoßen, haben Sie zwei Lösungen:

  • überlegen Sie, ob es sich lohnt, einen Fehlerbericht zu öffnen, oder nicht, fragen Sie vielleicht einen Kollegen nach seiner Meinung ... und bedauern Sie später in einigen Fällen, dass Sie dies nicht getan haben, weil jemand danach fragt und wenn Sie den Bericht bereits hatten, könnten Sie es Zeigen Sie sie einfach darauf
  • erstellen Sie einfach den Bericht

Das Erstellen des Berichts ist schneller und wenn nicht, automatisieren Sie ihn.


Wie automatisiere ich es? Vorausgesetzt, Ihr Tracker unterstützt Skripte, erstellen Sie einfach ein Skript, das Sie aufrufen können und das die Commit-Nachricht (Titel und Text) verwendet, um einen Fehlerbericht zu senden und ihn sofort als "implementiert" zu schließen, wobei die Commit-Revision für das Tracking zugeordnet ist.

1
Matthieu M.

Ich werde zustimmen, dass die anderen Antworten alle gute Faustregeln bieten und einige sogar diesen Punkt berühren, aber ich denke, dass es hier nur eine wirklich sichere Antwort gibt.

Fragen Sie einfach Ihren Manager. Nun, Ihr Manager oder alternativ Projektleiter oder Scrum Master usw., je nachdem, wie Ihre Gruppe strukturiert ist.

Es gibt viele verschiedene Systeme für gute und schlechte Praktiken, aber der einzige Weg zu wissen, dass Sie das Richtige für Ihr Team tun, besteht darin, zu fragen.

Etwas in der Art eines einminütigen Korridor-Gesprächs würde reichen: "Hey (Chef), wenn ich einen kleinen Fehler behebe, der nur wenige Minuten dauert, lohnt es sich, ein Ticket dafür zu machen oder sollte Ich erwähne es nur in meiner Commit-Nachricht? " und Sie werden es sicher wissen. Alle guten Praktiken der Welt sind nutzlos, wenn diese Methode Ihr Team und Ihren Manager nervt.

0
Vality