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

12

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?

version-control git svn workflows Nattfrosten
źródło
powiązane (być może duplikat): kod opcji + kod infrastruktury - jak ustrukturyzować kwestie commits / JIRA?
komara
Zwykle wybieram drugą opcję. Ale jeśli zrobiłem dużo refaktoryzacji, robię dwa osobne zatwierdzenia. 1 dla mojego konkretnego zadania, a inne właśnie oznaczone jako „Refaktoryzacja”, które rebasezamiast tego merge.
Alternatex,

Odpowiedzi:

7

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 ...”).

Śleske
źródło
W przypadku pierwszego pocisku drobne poprawki natychmiastowe rozpoczęcie edycji wydaje się najlepszą opcją. Nie mam pojęcia, dlaczego o tym nie pomyślałem, chyba złe nawyki.
Zwykle wchodzę
@Nattfrosten: Tak, to naturalne i nie jest złe - w końcu zwykle należy skupić się na kodowaniu. Zarządzanie kodami ma na celu ułatwienie kodowania.
sleske,
5

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.

Scant Roger
źródło
1
Bardzo dziękuję za tę odpowiedź, do tej pory głównie zajmowałem się projektami solowymi, stąd moja perspektywa. Będę musiał zmienić wiele nawyków, aby później lepiej dopasować się do zespołu, a tego rodzaju rzeczy właśnie tego potrzebowałem.
Nattfrosten,
Ten sam wniosek, ale często szefowie decydują się na nowe funkcje, a nie na refaktoryzację: - |
Mark Hurd,