Rozwiązywanie konfliktów scalania z powodu refaktoryzacji

Niedawno zaangażowałem się w dyskusję na temat tego, jak ogólnie radzić sobie z refaktoryzacją (co samo w sobie jest interesującym tematem). W końcu pojawiło się następujące pytanie:

Jak radzić sobie z konfliktami scalania, które miały miejsce z powodu tego, że ktoś dokonał refaktoryzacji części kodu, podczas gdy ktoś inny pracował nad funkcją dla tego samego fragmentu kodu?

Zasadniczo nie mam pojęcia, jak sobie z tym poradzić w efektywny sposób. Czy są jakieś najlepsze praktyki, które należy stosować w tym zakresie? Czy jest jakaś różnica w tym, jak należy sobie z tym poradzić w przypadku systemu z mnóstwem starszego kodu?

Dobre pytanie. Najlepsza strategia, jaką mogę wymyślić, to:

Zapobieganie

Połączenie ciągłej integracji i często dokonywania małych refaktoryzacji (zamiast sporadycznych dużych refaktoryzacji) znacznie przyczyni się do zminimalizowania kosztów i częstotliwości takich konfliktów.

Myślę, że aby odpowiedzieć na twoje pytanie, najpierw musimy dowiedzieć się, dlaczego dochodzi do konfliktów i jakie jest prawdziwe znaczenie i proces łączenia się?

Konflikty występują tylko wtedy, gdy dwóch lub więcej programistów pracuje nad tym samym plikiem w tym samym czasie, a następnie próbują się zalogować. Pierwszy programista oczywiście nie dostanie żadnego konfliktu. Ale drugi (trzeci, czwarty i tak dalej) miałby konflikty. Dlaczego, ponieważ ma on kod, który częściowo lub całkowicie różni się od kodu istniejącego na serwerze.

To z natury oznacza, że ​​drugi programista ma na myśli coś innego niż pierwszy programista. Różnica może być różna w zależności od stylu, na przykład używanie new UserManager().GetUserName()zamiast UserManager userManager = new UserManager(); userManager.GetUserName();do poziomu, o którym wspominałeś, co oznacza, że ​​obaj programiści mieli różne pomysły, jak zmienić kod w celu jego ulepszenia.

Z drugiej strony połączenie nie oznacza, że ​​programiści mogą zameldować się w kodzie bez uwzględnienia konfliktów. Oni powinni i muszą rozwiązać te konflikty. Jeśli konflikty nie są ważne, mogą się zameldować i zastąpić poprzedni kod. Ale kiedy widzą coś zupełnie innego, powinni zadzwonić do poprzedniego programisty i porozmawiać z nim, aby oboje mogli zostać skoordynowani w celu sprawdzenia najlepszego rozwiązania.

Na przykład, jeśli poprosisz dwóch programistów o ulepszenie biblioteki płatności online, a ich praca nakłada się, oznacza to, że przynajmniej w niektórych miejscach istnieją 2 różne rozwiązania. Tak więc, jedno z tych rozwiązań powinno zostać omówione i zaakceptowane, a zatem sprawdzone, jako lepsze rozwiązanie.

Nie zgadzam się na zapobieganie takim okolicznościom, ponieważ powinniśmy być bardziej realni niż teoretyczni. Czasami facet jest naprawdę dobry w CSS, podczas gdy inny jest naprawdę dobry w znacznikach ASP.NET. Ale ich praca może powodować konflikty, gdy oboje powinni pracować na stronie logowania, aby działała. Mam na myśli to, że jeśli myślimy realnie (nie idealnie), możemy zauważyć, że wiele razy to zjawisko (konflikt) ma miejsce.

Kolejną kwestią, o której chciałem wspomnieć, jest użycie narzędzi pomocnych w procesie odprawy. Narzędzia te zazwyczaj wizualizują różnicę kodu serwera i kodu programisty i bardzo pomagają w określeniu, która część powinna zostać zameldowana.

Jeśli nie ma aktywnego zarządzania zadaniami, masz konflikty.

Jeśli jednak masz codzienne spotkanie stand-up lub menedżera , prawdopodobnie nie możesz mieć tego problemu.

Porozmawiaj (przez codzienne wstawanie) lub porozmawiaj z menedżerem.

Mówiąc to, trywialnie temu zapobiega się.

Miej oddzielną wspólną gałąź do rozwijania określonej funkcji, często łącz / ciągnij / wypychaj - to wszystko.

I komunikować się . Porozmawiaj z innymi programistami o kodzie nawet podczas uruchamiania. Nawet podczas kodowania)))

Upewnij się, że scalanie jest tak proste, jak to możliwe. Refaktoryzacja jest zwykle raczej mechanicznym procesem, który zmienia wiele istniejących linii : przenoszenie deklaracji zmiennych, zmiany białych znaków, formatowanie, sekwencja operacji. Tworzenie funkcji jest zwykle bardziej kreatywnym przedsięwzięciem, często skutkującym nowym kodem i kilkoma drobnymi poprawkami do istniejącego kodu. Teraz, jeśli programista dokonujący refaktoryzacji zarejestruje kroki (na przykład jako wyrażenia regularne), może być znacznie łatwiej zastosować je do kodu z dodatkową funkcjonalnością, a nie odwrotnie. Na tej podstawie powiedziałbym, że zgodnie z ogólną zasadą należy najpierw zastosować najbardziej złożoną zmianę, a następnie stopniowo wprowadzać zmiany.