Przepływ pracy, edycja rzeczy, których nie ma w bieżącym zadaniu

Zwykle, kiedy programuję, mam przed sobą jasne zadanie, ale znajdę irytujące rzeczy, które chciałbym posprzątać w miarę upływu czasu.

Tutaj widzę trzy opcje:

• Zrób to później (może zapomniałem / musiałem poświęcić czas na dodawanie biletu)
• Zrób to teraz i dokonaj tego razem z moją obecną pracą (niejasne)
• Zrób to teraz i zatwierdź osobno (musisz go znaleźć, może popełnić błąd i niechcący wybrać opcję nr 2)

Jest to prawdopodobnie dość proste, ale jakie są sposoby na obejście tego za pomocą svn / git / other?

Osobiście myślę, że to zależy :-).

• W przypadku drobnych poprawek najlepsza jest opcja trzecia (teraz w osobnym zatwierdzeniu), ponieważ narzut związany z robieniem tego później nie jest tego wart. W takim przypadku wystarczy utworzyć osobne zatwierdzenie. Jak to zrobić, zależy od używanego VCS i jest osobnym pytaniem :-).

• Jeśli jest to większa poprawka , tworzysz bilet. W przeciwnym razie istnieje ryzyko ciągłego wykolejenia się od głównego zadania („Och, spójrz, kolejna okazja do refaktoryzacji, och, jest jeszcze jedna, i tam, i tam ...”).

Rozważ to. Kiedy „znajdziesz irytujące rzeczy (...) do wyczyszczenia” i podejmujesz decyzję wykonawczą, odcinasz resztę swojego zespołu od dyskusji i decyzji dotyczących priorytetów. Pozwalasz, aby Twój plan przebijał wszystkich innych z powodu uprzywilejowanej relacji z kodem. Nie sądzę, że to miłe. Z doświadczenia prowadzi również do niechęci zespołu / akcjonariusza.

Zamiast tego utwórz problem / zadanie czyszczenia / refaktoryzacji. Chociaż jest to świeże w pamięci, wymień powody, dla których jest to ważne: szacunki zwiększonej stabilności, łatwości konserwacji i tego rodzaju rzeczy. Może zawierać oszacowanie wysiłku w zależności od tego, jak działa Twój zespół. Następnie na kolejnym spotkaniu dotyczącym wyboru / przypisania / priorytetów zadania zaprezentuj swoje zadanie refaktoryzacji i umieść je w zestawieniu z innymi zadaniami. Jako zespół zdecyduj, kiedy należy go ukończyć.

Proszę nie myśleć, że mówię wam, abyście wyrzucali rozsądek w imię zasad. Użyj swojej głowy. Jeśli w edytowanej funkcji jest coś brzydkiego, nie jest to nowe zadanie refaktoryzacji. Napraw to i sprawdź wszystko. Jeśli zmiana nazwy właściwości, z którą pracujesz, na coś bardziej sensownego wpływa na kilka dodatkowych plików źródłowych, nie jest to nowe zadanie refaktoryzacji. Napraw to i sprawdź wszystko. Jeśli z drugiej strony nie podoba ci się sposób, w jaki inny programista (Mitch, nienawidzę tego faceta) zrobił coś w funkcji, której nie edytujesz, a funkcja wydaje się działać dobrze, na razie zostaw to w spokoju . Utwórz zadanie refaktoryzacji i przedstaw swoją sprawę zespołowi.

Jeśli Twój zespół zawsze rezygnuje z refaktoryzacji na korzyść nowych funkcji, zacznij szukać innej pracy. Łatwiej jest znaleźć pracę, gdy już ją masz.