tl; dr - Wygląda na to, że czas wkroczyć do wielkich lig. Nałożenie pomadki na świnię nie sprawia, że jest ładniejsza, chyba że lubisz takie rzeczy ...
Problem ludzi
Pierwszym problemem jest synchronizacja zatwierdzeń. JEŚLI masz wiele osób pracujących nad tym samym kodem w tym samym czasie, potrzebujesz tylko jednej reguły, aby zapobiec problemom:
Rule 1: Always pull before you merge/rebase
Jeśli chodzi o DVCS, trudno jest wprowadzić zmiany w zdalnej gałęzi (tj. Głównym repozytorium) i bardzo łatwo wprowadzić zmiany w lokalnym. Każda osoba jest odpowiedzialna za dopasowanie własnych dodatków kodu do większej całości bez problemów. Jeśli 2 osoby nie zaangażują się dokładnie w tym samym czasie, nie powinieneś tego doświadczać. Zatwierdź dostęp do źródła / zdalnego wzorca powinien być ograniczony tylko do kilku programistów i powinni pobierać zmiany od innych programistów za pośrednictwem zdalnych gałęzi śledzenia.
Problem z kodem
Skąd wiesz, że wprowadzone zmiany nie powodują uszkodzenia kodu?
Prosta odpowiedź ... Napisz testy, aby udowodnić, że nie. Jeśli zignorujesz szkołę myślenia TDD (Test Driven Design), cały sens testów polega na dodaniu poziomu weryfikacji, który umożliwia zmianę kodu bez jego łamania.
Rule 2: Don't make assumptions, write proofs (ie tests).
Ponadto, zanim przejdziesz do źródła / zdalnego wzorca, należy uruchomić pełną gamę testów.
Zachowaj swoje zobowiązania tak małe i zwięzłe, jak to możliwe. W ten sposób, jeśli będziesz musiał wycofać się z zmiany, która później coś popsuła, zaoszczędzisz od konieczności ponownego wdrażania części, które nie złamały kodu.
Najpierw może być konieczna restrukturyzacja organizacji
Jeśli powyższe rozwiązania nie mogą być łatwo zastosowane, prawdopodobnie istnieją pewne problemy ze strukturą programistyczną, które należy rozwiązać w pierwszej kolejności.
Właścicielem projektu powinien być strażnik. Jeśli występują problemy z synchronizacją zatwierdzeń, prawdopodobnie zbyt wiele osób ma dostęp do zatwierdzania. Nawet w przypadku dużych projektów, takich jak jądro Linuksa, tylko garstka programistów ma dostęp do źródłowego / zdalnego głównego repozytorium. W rzeczywistości istnieje wiele poziomów repozytoriów do zarządzania zatwierdzeniami. Zamiast modelu zatwierdzania jednowarstwowego, w którym wszyscy wypychają swoje zmiany do źródła, model hierarchiczny ma strażników, którzy dokonują zmian i sprawdzają ich jakość przed włączeniem do projektu. Hierarchiczny model zatwierdzania może skalować się o wiele większy i bardziej efektywny niż model jednowarstwowy bez utraty jakości.
Dla deweloperów, którzy nie mają dostępu do zatwierdzania, powinni nauczyć się tworzyć własne gałęzie zdalnego śledzenia (git i gitorious są do tego dobre), więc deweloperzy, którzy to robią nie popełnić dostępu można łatwo wyciągnąć / zintegrować gałęzie do pochodzenia. Jeśli zmiany są niewielkie, łatki będą działać równie dobrze.
Zdolność do wyciągania zmian przed scaleniem / rebasesem zakłada, że nie rozwijasz się w lokalnym oddziale głównym. Najłatwiejszym sposobem jest poradzenie sobie z tym, zanim zaczniesz kodować, a następnie wykonasz całą pracę w tej gałęzi. Trudno jest rozgałęzić go tuż przed scaleniem i wycofać master.
Zdefiniuj styl kodowania dla całego projektu i spraw, aby deweloperzy podążali za nim. Współpracujący deweloperzy powinni pisać kod, który jest zgodny ze standardami / normami projektu, aby zminimalizować czyszczenie. Styl kodowania może stanowić dużą barierę ego w otwartym projekcie. Jeśli nie zostanie ustawiony żaden standard, wszyscy będą kodować w swoim preferowanym stylu, a baza kodów stanie się bardzo brzydka bardzo szybko.
Mit „Miesiąca mitycznego człowieka”
Wierzcie lub nie, większe / bardziej udane projekty open source nie są prowadzone jak demokracja. Są prowadzone jako hierarchia. Stwierdzenie, że projekt nie może skutecznie przekroczyć 8-10 programistów, jest naiwne. Gdyby tak było, to nie istniałyby tak wielkie projekty jak jądro Linuksa. Głębszą kwestią jest to, że udzielenie każdemu dostępu tylko utrudnia efektywną komunikację.
Problem mitycznego miesiąca człowieka można rzeczywiście rozwiązać. Musisz tylko uruchomić swój projekt jak wojsko. W hierarchii istnieje wiele poziomów, ponieważ powszechnie wiadomo, że poszczególne osoby są tak naprawdę skuteczne tylko w zarządzaniu komunikacją z garstką ludzi. Dopóki żadna osoba nie jest odpowiedzialna za zarządzanie pracą więcej niż 5-7 osób, system może skalować się w nieskończoność.
Może ograniczyć najlepszych / doświadczonych programistów do większej integracji i projektowania / planowania wyższego poziomu, ale to nie jest złe. Częścią zwiększenia skali jest podjęcie decyzji, że projekt potrzebuje długoterminowego planu. Osoby na najwyższych poziomach, które mają największe inwestycje (czas jest również zasobem) w przyszłe projekty, powinny być odpowiedzialne za podejmowanie wielkich decyzji.
Miło jest słyszeć o projekcie open source przechodzącym bóle. Gratulacje i powodzenia.