Sollten Sie bereits vorhandene Fehler beheben, während Sie an etwas anderem arbeiten?

Problem: Während Sie an einer neuen Funktion arbeiten oder einen Fehler beheben, finden Sie ein altes Problem im Code. Was sollte man tun? Beheben Sie das Problem und riskieren Sie, das Verhalten des Codes zu ändern. Entweder hat es bis jetzt durch einen Zufall funktioniert, oder der Defekt wurde nicht entdeckt oder es lohnt sich, ihn zu melden. Sollten Sie es in Ruhe lassen und zulassen, dass das Problem die Arbeit mit dem Code später erschwert? Das Beheben des Problems erhöht nur die Zeit Ihrer ursprünglichen Aufgabe und zwingt Sie zum Regressionstest. Nur wenige werden die Arbeit zu schätzen wissen. Es scheint jedoch irgendwie richtig zu sein, es zu beheben. Code mit weniger Problemen ist einfacher umzugestalten und aufzubauen.

Ich befand mich immer wieder in dieser Situation, als wir an der Modernisierung einer Webanwendung arbeiteten. Ich kann nicht sagen, ob ich besessen oder ehrenwert bin, wenn ich an diesen alten Fehlern arbeite. Wie gehen Sie mit diesen Situationen um?

Danke, Corey

Ich arbeite in einem sehr kleinen Team, es hängt also davon ab, wie sich das ändert:

Wenn es sich um eine kleine, offensichtliche Fehlerbehebung handelt, dann bin ich auf jeden Fall dafür. Ich werfe auch zusätzliche Kommentare ein, wenn ich den Code eines anderen und andere kleine Verbesserungen durcharbeiten muss, die unter die "Boyscout-Regel" fallen.

Wenn der Code so verflochten ist, dass Sie die Frage stellen müssen, ob dies geändert und getestet werden soll, sollten Sie es nicht ändern. Rufen Sie es in Ihrem Bug-Tracking-System auf, wenn Sie sich Sorgen machen.

Aus diesem Grund versuche ich übrigens, kleinere Methoden auch mit deutlicheren Typ-Signaturen zu codieren. Wenn Sie wissen, dass es keine Nebenwirkungen gibt und die Ein- und Ausgänge übereinstimmen, können Sie den Code im Innenraum ohne Risiko korrigieren, neu anordnen oder optimieren.

Aber denken Sie nicht, dass mangelnde Wertschätzung ein Grund ist, Fehler, die Sie finden, nicht zu beheben oder die Codebasis aus irgendeinem Grund zu verbessern. Wenn nichts anderes, sind Sie freundlich zu der Zukunft, die sicher wieder da sein wird, um etwas anderes zu reparieren.

EDIT: Sie müssen auch Ihre Zeit auf dem Projekt beobachten. Natürlich muss man sich unter engen Fristen darauf konzentrieren, die Hauptarbeit zu erledigen, aber wenn man nur unter "normaler Last" ist, dann macht ein bisschen Aufräumen hier und da auf lange Sicht alle glücklicher.

Wie immer kommt es darauf an.

• Wenn es trivial ist und Sie sicher sind, dass Sie es beheben können, beheben Sie es.
• Wenn es viele Komponententests gibt, können Sie ziemlich sicher sein, dass Sie nichts kaputt gemacht haben, und das Problem beheben.
• Fügen Sie andernfalls ein // TODO hinzu, und fügen Sie es Ihrer Fehlerverfolgung hinzu

Grundsätzlich führen Sie eine Risikobewertung durch: Wie hoch ist das Risiko, dass sich etwas ändert oder nicht? Wenn Sie das Gefühl haben, nicht genug Erfahrung zu haben (mit dem Programmieren im Allgemeinen oder dem System im Besonderen), fragen Sie jemanden im Team.

Der Pragmatic Programmer nennt diese "Broken Windows".

Wenn Sie kaputte Fenster nicht reparieren, besteht die Tendenz, dass sie eine Abwärtsspirale der Codequalität erzeugen. Und je mehr von ihnen es gibt, desto größer ist die Aufgabe, sie zu reparieren, und daher ist es weniger wahrscheinlich, dass sie repariert werden.

Ob sie jetzt oder später repariert werden, ist eine Frage des Urteils. Ist es eine einfache Lösung? Sind Sie sicher, dass der Code das tut, was Sie denken? Wird es wahrscheinlich von Ihrer aktuellen Aufgabe ablenken? Stehen Sie unter Zeitdruck? Wird es wahrscheinlich mehr Bugs geben?

Markieren Sie mindestens den Artikel in Ihrem Tracking-System und stellen Sie sicher, dass er später repariert wird. Es ist wichtig, dass Sie es im Nachverfolgungssystem markieren, auch wenn Sie sich dafür entscheiden, es jetzt zu reparieren, sicherzustellen, dass es auch getestet wird, und Änderungen zu dokumentieren.

Wenn es sich um einen offensichtlichen Fehler handelt, der die Sicherheit verletzt, Daten beschädigt oder eine Ausnahme auslöst, die dem Benutzer angezeigt wird, beheben Sie diesen Fehler. Fragen Sie andernfalls jemanden, der die Codebasis besser kennt als Sie.

Es hängt davon ab, ob es sich um einen kleinen Fehler handelt, bei dem Sie sicher sind, dass Ihr Fix nur geringe Auswirkungen hat. Ich persönlich würde ihn dann im Rahmen der anderen Arbeit beheben und den PM darüber informieren.

Wenn für den Kunden, Benutzer oder das Unternehmen ein Risiko besteht, wenden Sie sich an den Projektmanager und besprechen Sie den weiteren Verlauf. Es ist ihre Aufgabe, das Risiko zu bewerten, um sie darauf aufmerksam zu machen und die Gründe für die Behebung zu nennen. Dann ehre ihre Entscheidung.

Unsere Tester hassen das. Es sei denn, es ist sehr trivial, wir protokollieren es in der Bug-Datenbank, ordnen es dann einem Release zu und schreiben Regressionstests. Wenn die Entwickler nur Änderungen vornehmen, die nicht im Zeitplan enthalten sind, wie können Sie dann eine Frist einhalten?

Ich war in Teams, in denen unkritische Fehler oder Standardverstöße als "Weak Code" -Fehler gemeldet wurden. Ich würde sagen, dass die Person, die einen kritischen Defekt findet, die Verantwortung hat, eine Art Flagge zu werfen

es kommt auf den Fehler an. Das Hauptanliegen ist die Einführung neuer Fehler. Es ist besser, sich mit einem bekannten Problem zu befassen, als mit einem unbekannten. Wenn es einfach ist, sagen wir eine Textänderung oder einen einfachen logischen Fehler, beheben wir es, ansonsten lassen wir es in Ruhe.

Eine Sache zu beachten, obwohl wir ein kleiner Laden mit 4 Entwicklern und einem Praktikanten sind und der Fehler, den ich behebe, wahrscheinlich der Fehler ist, den ich verursacht habe.

Wenn der Code offensichtlich falsch ist, die Fehlerbehebung ziemlich einfach ist und Sie glauben, dass das Risiko, die Benutzer zu beeinträchtigen, gering ist, dann versuchen Sie es. Es kommt auf professionelles Urteilsvermögen an.

Sie müssen sich jedoch daran erinnern, dass die Benutzer es vermutlich nicht gefunden haben, wenn Sie es gefunden haben, oder dass sie es sonst gemeldet hätten. Anstatt Zeit mit der Behebung eines Problems zu verbringen, auf das ein Benutzer möglicherweise nie stößt, ist es möglicherweise besser, diese Zeit mit der Behebung von Problemen zu verbringen, die jetzt Probleme für Ihre Benutzer verursachen.

Dokumentieren Sie die Beobachtungen zuerst und entscheiden Sie, ob Sie sie später korrigieren möchten.

Besprechen Sie sich formell (z. B. in der regulären Besprechung) oder informell (z. B. während des Mittagessens) mit Ihren Kollegen und nehmen Sie die Änderungen vor, nachdem Sie mehr Vertrauen in das Verhalten der zu reparierenden Codes gewonnen haben.

Obwohl es Ihnen als Fehler / Defekt erscheint, kann es sich diesmal tatsächlich um ein "Feature" handeln. Es könnte eine schlecht implementierte Lösung sein, um in der letzten Minute der vorherigen Version um einige Eckfälle herumzukommen, und Ihr "sauberer Fix" könnte einige zuvor gelöste Probleme wieder aufleben lassen.

Ich werde mich hier gegen den Trend wenden. Sofern Sie sich nicht in einer sehr frühen Prototyp-Entwicklungsphase befinden, sollten Sie dies niemals sofort beheben, sondern einen Fehlerbericht einreichen. Dies hat mehrere Vorteile:

• Das Team muss es bewerten. Ist es ein echter Fehler, was sind die Risiken, ihn zu beheben?
• Das Management muss entscheiden, ob dies wichtig genug ist, um die Auswirkungen des Zeitplans auf die Aufnahme in diese Version zu berücksichtigen
• Der Testsuite kann eine Methode zur Erkennung hinzugefügt werden, die hoffentlich allgemein genug ist, um auch ähnliche Fehler zu finden.
• Es liefert wertvolle Informationen darüber, wie viele Fehler in den vorherigen Phasen aufgetreten sind