Workflow, Bearbeiten von Dingen, die sich nicht in Ihrer aktuellen Aufgabe befinden

Normalerweise habe ich beim Programmieren eine klare Aufgabe vor mir, finde aber nervige Dinge, die ich im weiteren Verlauf aufräumen möchte.

Hier sehe ich drei Möglichkeiten:

• Machen Sie es später (möglicherweise vergessen / müssen Sie Zeit damit verbringen, ein Ticket hinzuzufügen)
• Mach es jetzt und setze es zusammen mit meiner aktuellen Arbeit ein (unklar)
• Tun Sie es jetzt und legen Sie es separat fest (müssen es finden, könnten einen Fehler machen und Option 2 aus Versehen wählen)

Dies ist wahrscheinlich ziemlich einfach, aber wie kann man dies mit svn / git / other umgehen?

Persönlich denke ich, dass es abhängt :-).

• Für kleine Fehlerbehebungen ist Option drei (jetzt in einem separaten Commit) am besten geeignet, da sich der Aufwand für eine spätere Ausführung nicht lohnt. In diesem Fall erstellen Sie einfach ein separates Commit. Wie das geht, hängt vom verwendeten VCS ab und ist eine separate Frage :-).

• Wenn es sich um einen größeren Fix handelt , erstellen Sie ein Ticket. Andernfalls riskieren Sie, ständig von Ihrer Hauptaufgabe entgleist zu werden.

Bedenken Sie. Wenn Sie "nervige Dinge finden (...), die aufgeräumt werden müssen", und Sie eine Entscheidung der Geschäftsleitung treffen, schneiden Sie den Rest Ihres Teams aus einer Diskussion und Entscheidung über Prioritäten heraus. Sie lassen Ihre Agenda alle anderen übertrumpfen, weil Sie eine privilegierte Beziehung zum Code haben. Ich finde das nicht schön. Erfahrungsgemäß kommt es auch zu Ressentiments von Mitarbeitern / Aktionären.

Erstellen Sie stattdessen ein Problem / eine Aufgabe für die Bereinigung / Umgestaltung. Nennen Sie die Gründe, aus denen es wichtig ist, auch wenn es noch frisch in Ihrem Kopf ist: Schätzungen zu erhöhter Stabilität, Wartungsfreundlichkeit und dergleichen. Schließen Sie vielleicht eine Schätzung des Aufwands ein, je nachdem, wie Ihr Team arbeitet. Präsentieren Sie dann in Ihrer nächsten Aufgabenauswahl / Zuweisung / Prioritätenbesprechung Ihre Refactoring-Aufgabe und stellen Sie sie gegenüber anderen Aufgaben auf. Entscheide als Team, wann es abgeschlossen sein soll.

Bitte glaube nicht, dass ich dir sage, du sollst im Namen der Prinzipien einen gesunden Menschenverstand walten lassen. Benutze deinen Kopf. Wenn die Funktion, die Sie bearbeiten, etwas Hässliches enthält, ist dies keine neue Refactoring-Aufgabe. Beheben Sie das Problem und checken Sie alles ein. Wenn sich das Umbenennen der Eigenschaft, mit der Sie arbeiten, auf einige zusätzliche Quelldateien auswirkt, ist dies keine neue Refactoring-Aufgabe. Korrigieren Sie es und checken Sie alles ein. Wenn Ihnen andererseits nicht gefällt, wie ein anderer Entwickler (Mitch, ich hasse diesen Typen) etwas in einer Funktion getan hat, die Sie nicht bearbeiten, und die Funktion anscheinend einwandfrei funktioniert, Lass es jetzt in Ruhe . Erstellen Sie eine Refactoring-Aufgabe und präsentieren Sie Ihren Fall Ihrem Team.

Wenn das Refactoring von Ihrem Team immer zu Gunsten neuer Funktionen abgelehnt wird, suchen Sie nach einem anderen Job. Es ist einfacher, einen Job zu finden, wenn Sie bereits einen haben.