Powinieneś poprawić jakość kodu podczas pracy nad gałęzią funkcji

Naprawdę podoba mi się ten artykuł o pozostawieniu kodu / kempingu w ładniejszym stanie, niż go znalazłeś - wydaje się praktycznym podejściem do zachowania czystości kodu.

Bardzo podoba mi się również gałąź funkcji jako sposób na rozwijanie funkcji w oderwaniu, więc jeśli ci się nie podoba, nie możesz łatwo scalić itp.

Jeśli jednak pracuję nad gałęzią funkcji i zauważyłem brzydki kod, czy powinienem to naprawić?

Wygląda na to, że istnieje wiele wad tego rozwiązania:

• Kiedy ponownie połączę gałąź, diff będzie bałagan, zaśmiecony zmiennymi nazwami lub ekstrakcją funkcji
• Jeśli funkcja zostanie porzucona, musisz albo wybrać zatwierdzenie czyszczenia (które może, ale nie musi działać, w zależności od tego, jak zmienił się kod w pobliżu, powodując bałagan podczas scalania), wykonaj to ponownie lub po prostu porzuć.

Z drugiej strony, jeśli nie zrobię tego, gdy jestem w aktach, to oczywiście zapomnę to zrobić za kilka dni, kiedy scalę gałąź.

Ostrzeżono mnie, że jest to oparte na opiniach (myślę, że nie tylko z tytułu tego tytułu should), ale wydaje mi się, że istnieje odpowiedź (na pewno ludzie używają obu tych podejść, więc muszą mieć odpowiedź). Ponadto pytania development methodologiesna ten temat dotyczą tematu i myślę, że wymagają one pewnego stopnia opinii.

Powinieneś „naprawiać” kod tylko w gałęzi funkcji, jeśli i tak zmieniasz ten fragment kodu jako część funkcji.

Na przykład. Pracuję nad funkcją „Drukuj króliki” i znajduję kod drukarki

Public class Printer(string type)
{
    If(type=="bunnies")
    {
        //print a bunny
    }
.....
}

Zmieniam na:

Public class Printer(string type)
{
     PrintFunctionDictionary[type].Print();
}

Czemu:

• Pracuję nad kodem,
• Muszę to zmienić, aby dodać funkcjonalność,
• dodatkowa funkcjonalność sugeruje odnowiony sposób rozwiązania problemu.

Nie losowo uderzyłem w inną część bazy kodu i „poprawiłem to”, ponieważ:

• Starć się z ludźmi pracującymi nad innymi funkcjami.
• Wykorzystaj czas, który należy przeznaczyć na opracowanie funkcji.
• Dodaj dowolny kod do oddziału, który, jeśli funkcja nie jest ukończona, może nie zostać scalony z głównym produktem. Podobnie, jeśli wycofam funkcję, stracę refaktoryzację.

Jeśli chcesz, aby refaktoryzacje „działały niezależnie” z bieżącej gałęzi funkcji, nie wprowadzaj tam zmian. Zamiast tego wykonaj refaktoryzację w głównej gałęzi programistycznej (lub „gałęzi refaktoryzacyjnej”, jeśli w twoim zespole często nie stosuje się zmian bezpośrednio w gałęzi deweloperów). Tak więc każdy z twojego zespołu (łącznie z tobą) może scalić zmiany w aktywnych gałęziach funkcji, nad którymi pracują. Należy jednak uważać, aby nie stosować żadnych globalnych refaktoryzacji w „połowie podstawy kodu” bez uprzedniego pytania współpracowników o pozwolenie - mogą nie być tak zadowoleni, jeśli refaktoryzacje zbyt mocno zakłócają ich bieżącą pracę.

Wyjątkiem jest sytuacja, gdy wprowadzone ulepszenia są lokalne dla części kodu, których dotkniesz dokładnie w tej gałęzi funkcji, i nie ma sensu nadawanie im innego cyklu życia niż „nowa funkcja”.

Celem branchtypów jest zapewnienie zamiaru ich obsługi. Jeśli po styl GitFlow rozgałęzienia, wtedy może mieć rodzaje podoba feature, hotfix, releaseitp .. W przypadku gałęzi funkcji, jego intencją jest, aby otaczać się wtopić się w innej gałęzi (tj develop), który pokazuje, deweloper odpowiedzialny za scalanie, czym jest ta funkcja. Jeśli czyszczony kod nie jest częścią tej funkcji, nie zmieniaj go.

Zamiast tego znajdź najniższą możliwą gałąź, w której znajduje się brzydki kod (prawdopodobnie develop) i stamtąd stamtąd. Zmień kod i zaproponuj włączenie go jako funkcji. Jeśli potrzebujesz tego kodu w tym, nad czym pracujesz, a szczególnie chcesz uniknąć konfliktów scalania, połącz tę gałąź w SWOJĄ gałąź.

Oto całkiem dobre wyjaśnienie różnych strategii: https://www.atlassian.com/git/tutorials/comparing-workflows/

jeśli pracuję nad gałęzią funkcji i zauważam brzydki kod, czy powinienem to naprawić?

Prawdopodobnie dobrze jest naprawić „brzydki kod” na widoku, w zależności od tempa projektu, „brzydoty” kodu itp., Ale staraj się tego nie robić w samej gałęzi funkcji.

• Jeśli twoja gałąź funkcji jest całkowicie lokalna, po prostu ukryj lub zatwierdź niezapisane zmiany, sprawdź gałąź rozwoju, wprowadź zmiany, a następnie wróć do swojej gałęzi funkcji i zacznij opracowywać.
• Jeśli nie możesz zrezygnować z programowania (np. Twoja gałąź funkcji znajduje się na serwerze publicznym), możesz nadal wybrać opcję rozwijania, jeśli jest to potrzebne lub chcesz później uniknąć konfliktów.
• Jeśli edytujesz plik i naprawdę musisz teraz zatwierdzić poprawkę do brzydkiego kodu i naprawdę nie możesz przejść do programowania, możesz wprowadzić poprawkę, użyć jej git add -pdo wprowadzenia poprawki, zatwierdzić tylko tę zmianę , a przed scaleniem / push (w rzeczy samej, najlepiej po następnym zatwierdzeniu), użyj interaktywnej bazy, aby przesunąć ten zatwierdzenie do najwcześniejszego możliwego punktu w twojej gałęzi, a może nawet zdecydować się na rozwój, w zależności od twojej historii.

Zrobiłbym to również z czymkolwiek, co „naprawia” gałąź programistyczną (gdzie „poprawki” to zmiany, które ty lub inny programista możesz wprowadzić na widok, aby zapewnić zgodność kodu ze standardami). To pomaga...

• aby zachować poprawki i zatwierdzić funkcję w różnych grupach, aby dziennik był bardziej czytelny,
• w celu utrzymania rozwoju możliwie jak najbliższego uwolnienia w dowolnym momencie, oraz
• aby uniknąć powielania pracy (wiele osób rozwiązuje ten sam problem w subtelny sposób na różnych gałęziach).