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

13

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?

Roger CS Wernersson
źródło
1
Nie wiem o żadnych wtyczkach Eclipse ... brzmi bardziej jak zadanie dla systemu kontroli wersji.
SL Barth - Przywróć Monikę
Dlaczego chcesz temu zapobiec? Czy ma to na celu uniknięcie komplikacji (błędów) czy oszczędność czasu programisty? Rozwiązanie zależy w dużej mierze od odpowiedzi na to IMO.
KaptajnKold,
Dlaczego nie spróbujesz SVN, Apache Subversion lub Tortoise svn będzie w tym dobrze.
1
Dlaczego dwadzieścia zespołów edytuje to samo źródło?
Mamy VCS. Właśnie zmieniliśmy z ClearCase na Git.
Roger CS Wernersson

Odpowiedzi:

14

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.

Daniel B.
źródło
Większość zmienia pion; modyfikuje GUI, protokoły sieciowe, bazę danych, działa. Potrzebujemy narzędzia, które pomoże nam komunikować refaktoryzacje. Staramy się zmienić kod przy każdym odprawie, aby poprawić czytelność i zmniejszyć koszty konserwacji.
Roger CS Wernersson
@RogerWernersson - Rozumiem, po prostu nie sądzę, że istnieje dobry sposób na osiągnięcie tego. Właśnie dlatego moja odpowiedź zaleciła strukturyzowanie zespołów i obowiązków oraz kulturę firmy, aby w rezultacie zminimalizować liczbę kroków. Próba dopasowania równoległego kasy na git będzie bolesna i prawdopodobnie będzie miała wszystkie wady scentralizowanego systemu kontroli wersji. Jestem pewien, że ktoś to zrobił, powinieneś być w stanie znaleźć pewne konkretne implementacje, skoro już wspomniałeś, że używasz git.
Daniel B
7
  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.
Sriram
źródło
Jestem zwolennikiem korzystania z blokad w zasadzie, ale co zrobić, jeśli twoje narzędzie (np. Eclipse) zmienia wiele plików automatycznie przez refaktoryzację. Czy wszystkie zmienione pliki powinny być automatycznie blokowane? Liczba zablokowanych plików może rosnąć bardzo szybko. Czy zamki należy nabywać stopniowo? Jak radzić sobie z impasami?
Giorgio,
Jeśli zmienisz podpis metody i wpływa to na wiele plików, musisz uzyskać blokadę wszystkich plików. W przypadku, gdy ktoś inny ma blokadę, możesz ją zdobyć siłą (pozwala na to svn), jeśli Twoje refaktoryzacja ma wyższy priorytet.
Sriram
Czy można to zautomatyzować (poprzez przechowywanie priorytetów i automatyczne rozwiązywanie konfliktów blokad)? Czy każdy programista decyduje, czy ich refaktoryzacja ma wyższy priorytet?
Giorgio
Myślę, że jeśli priorytety są przechowywane w aplikacji mgmt zadania z przyzwoitym interfejsem API, można to zautomatyzować. Nigdy tego nie próbowałem, ale nie rozumiem, dlaczego nie powinno to być możliwe.
Sriram
Nie chcę zgłaszać błędu przy każdym refaktoryzacji. Podejście polega na oczyszczeniu zmienianego kodu. Złożenie raportu o błędzie dla każdego pliku brzmi jak zbyt dużo pracy.
Roger CS Wernersson
6

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.

Adam Butler
źródło
3
+1: Zatwierdzanie i aktualizacja często oznaczają również, że zmiany są niewielkie i łatwe do zarządzania, co ułatwia zarządzanie konfliktami.
Bringer128,
Zaangażowanie często by pomogło. Niestety nie mogę tego zmienić. Szukam narzędzia, które pomoże nam się komunikować.
Roger CS Wernersson
3

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.

quant_dev
źródło
3
Mówił o 20 drużynach, a nie o 20.
Ingo
1
+1 za technologię nie może rozwiązać problemów społecznych. Ale edytuj odpowiedź, aby powiedzieć „Przy 20 zespołach niezbędna będzie pewna struktura i zasady”
MarkJ
Niektórzy ludzie śpią, a inni pracują. Mamy zespoły na czterech kontynentach.
Roger CS Wernersson
0

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

c0da
źródło
Mamy Gita. Wcześniej mieliśmy ClearCase. VCS nie jest rozwiązaniem. Potrzebujemy mechanizmu wyzwalającego.
Roger CS Wernersson
0

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ę.

wałek klonowy
źródło
Większość zmian ma charakter pionowy; GUI, protokoły sieciowe, baza danych. Każdy zespół jest zwinny i koncentruje się na dostarczaniu wartości dla klienta przy każdym sprincie. Nie możemy mieć jednego zespołu w bazie danych, jednego w GUI itp. Byłoby łatwiej, gdyby kod był czystszy. Ale droga do czyszczenia kodu jest pisana „wiele małych refaktoryzacji”.
Roger CS Wernersson
0

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
mnich
źródło
1. ciężko, gdy każda drużyna pracuje pionowo 2. ciężko, ponieważ niektóre drużyny śpią, podczas gdy inne pracują 3. nie rozwiązuje problemu 4. Gdzie teraz w Git, wcześniej na ClearCase.
Roger CS Wernersson