Soll ich einen Fehler aufzeichnen, den ich entdeckt und behoben habe?


68

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

Was ist eine bessere Praxis?


4
Hängt von der Größe Ihres Unternehmens und Teams sowie von den Merkmalen des Fehlers ab. In kleinen und schnellen Teams ist dies nicht erforderlich, da Sie mit Ihren Kollegen kommunizieren können, indem Sie sie nur anschreien. In großen Teams, großen Organisationen und verteilten Entwicklungsumgebungen ist es gut, Ihre Arbeit zu protokollieren, aber es ist auch ein Overhead, der Ihre Produktionsstufe beeinträchtigt, wenn Sie an mehreren kleinen Fehlern arbeiten. Es sei denn, es handelt sich um einen schwerwiegenden Fehler, der immer schön dokumentiert, Unit-getestet, um Regressionen zu vermeiden, und geschlossen ist.
Machado

15
Vergessen Sie nicht, dass einige Fehler nicht behoben bleiben - sie inkarnieren sich spontan, wenn Sie sie für eine Weile ignorieren. Zu wissen, wie jemand versucht hat , das Problem beim letzten Mal zu beheben, kann wertvoll sein. Zumindest sollte es eine Dokumentation geben, in der steht, was Sie mit dem Code gemacht haben und warum, auch wenn es sich nur um Kommentare im Code handelt.
alephzero

5
Zusätzlich zu den vorherigen Kommentaren hängt es auch davon ab, ob der Fehler tatsächlich aufgetreten ist, aber Sie hatten das Glück, dass keine Kunden darauf gestoßen sind, oder ob er innerhalb eines Veröffentlichungszyklus eingeführt und behoben wurde.
Whatsisname

3
Wenn Sie Zweifel haben, rufen Sie es heraus. Mir hat es nie geschadet, einen Fehlerbericht zu öffnen und zu schließen. Unter bestimmten Umständen ist es gut, solche Dinge dokumentiert und offiziell zu haben.
Phresnel

1
Bezogen auf @ alephzeros Kommentar, etwas, das mir kürzlich passiert ist: Durch das Beheben eines Fehlers in einem Teil des Codes wurden Fehler an anderer Stelle aufgedeckt. Sie hatten sich in dem Teil, den ich nicht berührt hatte, ungewollt aufgehoben, und der erste Instinkt des Betreuers bestand darin, meine Fehlerbehebung rückgängig zu machen.
Izkata

Antworten:


71

Es kommt darauf an, wer die Zielgruppe eines Fehlerberichts ist.

Wenn es nur von Entwicklern intern betrachtet wird, um zu wissen, was repariert werden muss, dann kümmere dich nicht darum. Es ist nur Lärm an diesem Punkt.

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

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

56
Die wahrscheinlichste Stelle, an der ein Fehler auftritt, ist eine Stelle, an der zuvor ein Fehler aufgetreten ist. Ich würde empfehlen, es in praktisch jedem Szenario aufzunehmen.
corsiKa

18
# 4: Tester verwenden den Bug-Tracker, um ihre Tests zu steuern. Sie werden testen, ob das Update funktioniert und keine neuen Bugs oder Regressionen verursacht hat.
jpmc26

2
@corsiKa Wann ist das Medikament schlimmer als die Krankheit? ;-)
hBy2Py

1
@ hBy2Py Einen neuen Arzt finden und aufzeichnen.
corsiKa

2
@BradThomas umformulieren, was Sie zitiert haben: "Der Bugtracker wird als TODO-Liste verwendet und nicht mehr" + "Behobener Bug" -> "no TODO". Ich stimme in fast allen anderen Situationen zu, Sie möchten eine Aufzeichnung
Caleth

52

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, dann erstelle einen Fehlerbericht. Release-Zyklen können oft lang sein und Sie möchten nicht, dass Ihr Fehler als neues Problem gemeldet wird, solange Sie es bereits behoben haben.

Wenn Ihr Bug noch nicht ausgeliefert wurde, würde ich nicht den gleichen Weg gehen. Sie werden nun Leute haben, die versuchen, Ihren Fehler wiederherzustellen, was sie nicht können, da er noch nicht in einer Veröffentlichung enthalten ist, was im Wesentlichen ihre Zeit verschwendet.


2
Wenn Sie außerdem Code für Arbeitselemente einchecken, sollten Sie die Fehlerbehebung für das ursprüngliche Arbeitselement einchecken, wenn Sie Fehler beheben, die es nicht zu einer Produktversion geschafft haben.
Wablab

24

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. Kunde meldet den Fehler. Ihr Kollege versucht, den Fehler zu beheben, kann ihn jedoch nicht reproduzieren (weil Sie ihn bereits behoben haben). Deshalb möchten Sie eine Aufzeichnung des Fehlers.

Es 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, die Fehlerbehebung zu isolieren, was möglicherweise erfordert, dass Sie etwas in Ihre Aufgabenliste aufnehmen und dann die ganze Arbeit erledigen.


9

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 Bugs / Zeit, die für sie aufgewendet wurden, spezifisch erfasst?

Es kann auch interne Verfahren geben, die häufig durch die Anforderungen einer Zertifizierung gestützt werden. Für bestimmte Zertifikate ist es obligatorisch, dass jede Codeänderung auf einen Datensatz in einem Issue-Tracker zurückgeführt werden kann.

Außerdem sind manchmal sogar trivial aussehende Bugfixes nicht so trivial und unschuldig, wie sie zuerst erscheinen. Wenn Sie einen solchen Bugfix stillschweigend bündeln, um ein nicht damit zusammenhängendes Problem zu lösen, und der Bugfix sich später als problematisch herausstellt, wird es viel schwieriger, ihn aufzuspüren, geschweige denn zu isolieren oder wiederherzustellen.


2
Natürlich sollten Sie den Bugfix in der Commit-Nachricht erwähnen und vorzugsweise einen separaten Commit für die Änderung durchführen, die den Bug behoben hat. (Und vielleicht eine separate Pull-Anfrage oder Patch-Serie, wenn es sich um eine eigenständige Änderung handelt). Die einzige Ausnahme wäre, wenn der Fehler als Nebeneffekt einer Änderung aus einem anderen Grund behoben wird (aber dann immer noch in der Festschreibungsnachricht erwähnt wird). Die Frage ist nur, ob Sie sich um den Bug-Tracker kümmern sollen, nicht, ob Sie die Änderung mit anderen Dingen in einem einzigen Commit bündeln sollen!
Peter Cordes

3

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

Aber lassen Sie mich andersherum fragen: Warum würden Sie einen Fehler, den Sie behoben haben, nicht aufzeichnen?

Der einzige nachvollziehbare Grund, den ich sehe, ist, dass der Aufwand für das Einreichen des Fehlerberichts, das Festlegen und das Schließen des Fehlers um Größenordnungen größer ist als der Zeitaufwand für die Behebung des Fehlers.

In diesem Fall ist das Problem nicht, 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 zum Erstellen eines Jira-Tickets aus Drücken von c, Eingeben einer kurzen einzeiligen Zusammenfassung und Drücken von Enter. Die Beschreibung ist nicht einmal überflüssig, da ich sie zusammen mit der Ausgabenummer ausschneiden und in die Commit-Nachricht einfügen kann. Am Ende . c <Enter>und die Ausgabe ist geschlossen. Das läuft auf 5 Tastendrücke über Kopf hinaus.

Ich kenne Sie nicht, aber das reicht nicht aus, um es selbst in kleinen Projekten zur Regel zu machen, 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, jedoch 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 Fehlerbehebungen vorhanden sind, um sich über mögliche Entwicklungen zu informieren, z. B. über einen stetig wachsenden Zustrom kleiner 1-Zeilen-Fehlerbehebungen, die Ihnen einen Einblick in Prozessprobleme oder was auch immer geben könnten. Zum Beispiel, warum hast du so kleine Fehlerbehebung oft (vorausgesetzt , es passiert oft) zu tun? Kann es sein, dass Ihre Tests nicht gut genug sind? War der Bugfix ein Domainwechsel oder ein Codefehler? Usw.


2

Die Regel, der ich folge, lautet: Wenn der Abschnitt, an dem Sie arbeiten, noch nie veröffentlicht wurde und der noch nicht einmal ausgeführt wird und von keinem Benutzer gesehen wurde, 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, wird jeder Fehler, den Sie sehen, mit einem Fehlerbericht versehen und überprüft.

Ich habe herausgefunden, dass das, was ich für einen Fehler halte, eine Funktion für jemand anderen ist. Indem ich Fehler behebe, ohne dass diese überprüft werden, kann ich einen Fehler erstellen, anstatt ihn zu beheben. Tragen Sie in den Fehlerbericht ein, welche Zeilen Sie ändern würden, um den Fehler zu beheben, und legen Sie Ihren Plan fest, wie er behoben werden soll.

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


1

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 Menschen werden zu unterschiedlichen Zeiten unterschiedliche Meinungen zu diesem Thema haben.

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 die Meinung eines Kollegen ... und später, in einigen Fällen, bereuen Sie, dass Sie dies nicht getan haben, weil jemand danach fragt und wenn Sie den Bericht bereits hätten, könnten Sie Zeige sie einfach darauf
  • erstelle einfach den Bericht

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


Wie automatisiere ich das? 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 übermitteln, und schließen Sie ihn sofort als "implementiert", wobei die Commit-Revision für das Tracking zugeordnet ist.


0

Ich werde zustimmen, dass alle anderen Antworten 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 der guten und schlechten Praxis, aber der einzige Weg, um zu wissen, dass Sie das Richtige für Ihr Team tun, ist zu fragen.

Etwas in der Art einer einminütigen Korridor-Konversation würde dazu führen: "Hey (Boss), wenn ich einen kleinen Fehler behebe, der nur ein paar Minuten dauert, lohnt es sich, ein Ticket dafür zu erstellen, oder sollte ich es einfach in meiner Commit-Nachricht erwähnen? " und Sie werden es sicher wissen. Alle guten Praktiken auf der Welt sind nutzlos, wenn diese Methode Ihr Team und Ihren Manager verärgert.

Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.