Jak zarządzasz refaktoryzacją z dużą bazą kodu i wieloma programistami?

Chciałbym zapobiec sytuacji, w której dwóch programistów refaktoryzuje ten sam kod jednocześnie, nie rozmawiając o nim wcześniej, prawdopodobnie używając jakiegoś narzędzia, być może wtyczki Eclipse. Możesz pomóc?

Mamy 4,5 miliona linii kodu i ponad 20 zespołów programistów na czterech kontynentach.

Idealnie chciałbym, aby drugi ze wspomnianych wcześniej programistów zauważył, że ktoś inny pracuje nad tym samym kodem i porozmawia z pierwszym, zanim cokolwiek zmodyfikuje.

Znasz rozwiązanie?

Wiele systemów kontroli źródła drugiej generacji działa przy użyciu podłączonego „kasy”, która informuje serwer, że zamierzasz zmodyfikować plik. Przykłady obejmują TFS, SourceGear Vault i wiele innych. W ten sposób możesz technicznie spełnić swoje wymagania. Jak jednak zauważył Adam Butler, tego typu narzędzia mają swoje własne problemy (bez długiej debaty - ograniczone wsparcie dla pracy offline i ogólnie przepływ pracy programistycznej przynoszącej efekt przeciwny do zamierzonego).

Zdecydowanie zasugerowałbym jakieś hierarchiczne podejście do alokacji pracy refaktoryzacyjnej. Programiści mogą być logicznie pogrupowani w podgrupy, z których każda odpowiada za określone obszary kodu. W zależności od tego, jak lubisz organizować zespoły, każdy z nich może pełnić rolę „lidera” odpowiedzialnego za ogólny projekt obszaru zespołu. Struktura ta powinna być dobrze znana programistom i powinna uprościć komunikację w celu refaktoryzacji. Jestem pewien, że takie podejście wydaje się niektórym zbyt formalne i wstecz, ale myślę, że zdecydowanie lepiej jest, aby 20+ programistów stosowało podejście „bezpłatne dla wszystkich” do refaktoryzacji dużego systemu. Niektóre refaktoryzacje będą miały miejsce na wysokim poziomie (np. Jak moduł X komunikuje się z modułem Y), w takim przypadku będziesz potrzebować ludzi, którzy mogą nawiązywać połączenia na odpowiednim poziomie. Nie każdy programista w zespole powinien podejmować decyzje architektoniczne, więc w każdym razie prawie narzucona jest hierarchia, nawet jeśli ktoś się na nią nie zna.

Zasadniczo istnieją narzędzia, które spełnią postawione przez Ciebie podstawowe wymagania, ale żadne narzędzie nie zastąpi właściwej komunikacji i niewielkiej liczby osób kierujących ogólną architekturą Twojego projektu.

1. Upewnij się, że programiści mają przypisane określone moduły.
2. Mieć system śledzenia zadań / błędów, który śledzi każdą zmianę refaktoryzacji. Przydziel każde wydanie tylko jednemu programistowi
3. Niektóre systemy kontroli wersji mają możliwość blokowania pliku, dzięki czemu tylko jeden programista może mieć prawa do aktualizacji pliku. Nigdy nie korzystałem z tej funkcji, ale jeśli programiści nieustannie się nad sobą zastanawiają, warto rozważyć to.
4. Przeprowadź testy jednostkowe, aby nawet jeśli programiści pracowali nad tym samym plikiem, wiesz, że ich zmiany w żaden sposób nie psują aplikacji.
5. Wszystkie powyższe pomogłyby, jeśli refaktoryzacja jest zawarta w modułach. Jeśli jednak ktoś dokona refaktoryzacji w związku z zagadnieniami przekrojowymi, takimi jak rejestrowanie lub bezpieczeństwo, z definicji wpłynie to na wiele plików. Z tymi należy się obchodzić ostrożnie, zwłaszcza jeśli nie skorzystałeś już z podejść aop.

Istnieją / były systemy kontroli wersji, które powodują, że programiści kasują kod, zanim będą mogli go edytować, ale mają one własny zestaw problemów. Lepszą praktyką jest zachęcanie programistów do częstego zatwierdzania i aktualizacji. Jeden programista może następnie oznaczyć klasę jako amortyzowaną i zatwierdzić, a jeśli inny programista zaktualizuje przed rozpoczęciem refaktoryzacji, zobaczy zamiar.

Technologia nie może rozwiązać problemów społecznych. Musisz poprosić programistów, aby ze sobą rozmawiali i koordynowali ich pracę. W przypadku 20 drużyn niezbędna będzie pewna struktura i zasady. Będziesz chciał wspierać ich rozwiązaniami technologicznymi, ale ludzie są na pierwszym miejscu.

Jeśli odejdziesz notice that someone else is working on the same piece of code and talk to the first one before modifying anything, zgodnie z tym, co powiedziałeś, potrzebujesz systemu kontroli wersji (CVS / SVN / GIT). Nie jestem jednak pewien, ale jeśli chcesz to uwzględnić, będziesz potrzebować zaawansowanych rzeczy (może to być jakiś mechanizm wyzwalający / coś niestandardowego).

Programiści blokujący pliki w kontroli źródła powinni łatwo rozwiązać Twój problem, ale myślę, że możesz mieć większe problemy.

4,5 miliona LOC to ogromna piaskownica, w której można grać, dlatego w dobrze zaprojektowanym i zaprojektowanym rozwiązaniu rzadko należy natrafiać na sytuacje, w których wiele zespołów programistów narzuca się sobie nawzajem. Fakt, że dzieje się to bardziej niż przypadkowo, świadczy o poważnych potencjalnych wadach projektowych, na które należy zwrócić uwagę.

Parę rzeczy:

1. Oddzielne moduły do ​​pracy
2. Mówienie o zmianach przed ich wprowadzeniem [ze wszystkimi programistami]
3. Testowanie jednostkowe [w celu weryfikacji i uniknięcia złamania powiązanych rzeczy]
4. Jak inni wspominali o VCS