Czy to niezwykłe, że mała firma (15 programistów) nie korzysta z zarządzanej kontroli źródła / wersji? [Zamknięte]

To nie jest tak naprawdę pytanie techniczne, ale jest kilka innych pytań dotyczących kontroli źródła i najlepszych praktyk.

Firma, dla której pracuję (która pozostanie anonimowa) korzysta z udziału sieciowego do hostowania swojego kodu źródłowego i zwolnionego kodu. Deweloper lub menedżer jest odpowiedzialny za ręczne przeniesienie kodu źródłowego do odpowiedniego folderu w zależności od tego, czy został wydany, jaka jest wersja i tak dalej. Dysponujemy różnymi arkuszami kalkulacyjnymi, w których zapisujemy nazwy i wersje plików oraz co się zmieniło, a niektóre zespoły umieszczają również szczegóły różnych wersji na górze każdego pliku. Każdy zespół (2-3 zespoły) wydaje się robić to inaczej w firmie. Jak możesz sobie wyobrazić, jest to zorganizowany bałagan - zorganizowany, ponieważ „właściwi ludzie” wiedzą, gdzie są ich rzeczy, ale bałagan, ponieważ wszystko jest inne i polega na tym, że ludzie pamiętają, co robić w danym momencie.

Od jakiegoś czasu próbowałem naciskać na jakąś zarządzaną kontrolę źródła, ale wydaje mi się, że nie mogę uzyskać wystarczającego wsparcia w firmie. Moje główne argumenty to:

• Jesteśmy obecnie wrażliwi; w dowolnym momencie ktoś może zapomnieć o wykonaniu jednej z wielu czynności związanych z wydaniem, które musimy wykonać, co może oznaczać, że całe wersje nie są poprawnie przechowywane. W razie potrzeby złożenie wersji może zająć kilka godzin, a nawet dni
• Opracowujemy nowe funkcje wraz z poprawkami błędów i często musimy opóźnić wydanie jednego lub drugiego, ponieważ niektóre prace nie zostały jeszcze zakończone. Musimy również zmusić klientów do przyjęcia wersji, które zawierają nowe funkcje, nawet jeśli chcą tylko naprawić błąd, ponieważ jest tylko jedna wersja, nad którą wszyscy pracujemy
• Mamy problemy z programem Visual Studio, ponieważ wielu programistów korzysta jednocześnie z tych samych projektów (nie tych samych plików, ale nadal powoduje problemy)
• Jest tylko 15 programistów, ale wszyscy robimy rzeczy inaczej; czy nie lepiej byłoby zastosować standardowe podejście obejmujące całą firmę, którego wszyscy musimy przestrzegać?

Moje pytania to:

1. Czy to normalne, że grupa tego rozmiaru nie ma kontroli źródła?
2. Do tej pory podano mi tylko niejasne powody braku kontroli źródła - jakie powody sugerujesz, że mogą być ważne, aby nie wdrożyć kontroli źródła, biorąc pod uwagę powyższe informacje?
3. Są jeszcze jakieś powody, dla kontroli źródła, które mogę dodać do mojego arsenału?

Proszę przede wszystkim, aby poczuć, dlaczego mam tak duży opór, więc proszę odpowiedzieć szczerze.

Udzielę odpowiedzi osobie, która moim zdaniem przyjęła najbardziej zrównoważone podejście i odpowiedziała na wszystkie trzy pytania.

Z góry dziękuję

1. To może nie być normalne , ale jak mówi Treb , prawdopodobnie nie jest tak niezwykłe

2. Jak powiedzieli inni, nie ma żadnych ważnych powodów, dla których nie miałby kontroli źródła w firmie twojej wielkości. Musisz więc zidentyfikować i zaatakować nieprawidłowe przyczyny:

   a) głównym jest status quo : „jeśli się nie zepsuło, nie naprawiaj go”. Jest to trudne: możesz zacząć wskazywać wszystkie rzeczy, które nie działają tak dobrze, jak powinny (co może szybko sprawić, że zostaniesz uznany za „osobę negatywną”), lub po prostu zaczekaj, aż coś wybuchnie (co może nigdy się zdarzyć), lub możesz podkreślić wszystkie rzeczy, które mogą pójść nie tak. Niestety, osoby odpowiedzialne za małe firmy są stosunkowo niewrażliwe na „rzeczy, które mogą pójść nie tak”, dopóki nie popełniają błędu ...

   b) ignorancja / strach / niepewność : „tak naprawdę nie rozumiemy, czym jest kontrola źródła; nie wiemy, jak z niej korzystać; nie wiemy, które narzędzie wybrać; to zahamuje nasz styl” . To jeden z powodów, dla których zdecydowanie ich tutaj nie wysłałbym! To może być dla ciebie dość wysokie zamówienie, ale myślę, że aby zmaksymalizować swoje szanse, musisz przedstawić rozwiązanie „pod klucz”, a nie zbyt wiele wariantów lub alternatyw. Potrzebujesz jasnego pojęcia o tym, jak chcesz dopasować / przekształcić proces pracy do pracy z danym narzędziem; jak / jeśli planujesz back-port istniejącego kodu; jak myślisz, jak szybko możesz „szkolić” użytkowników i sprawić, by działali; jak możesz zarządzać okresem przejściowym (jeśli taki istnieje); ile to będzie „kosztować” (w godzinach, jeśli nie w dolarach).

   c) mogą istnieć inne powody (na przykład wcześniejsze złe doświadczenia z VSS lub przeczytanie „opowieści grozy” o rzekomo nadmiernie skomplikowanych narzędziach), ale musisz je pokonać indywidualnie, gdy je odkryjesz.

3. Istnieją liczne powody, dla kontroli źródła przedstawionej w innych odpowiedzi. Radzę wybrać główne 2 lub 3, które mogą naprawdę zmienić twoją firmę, dopracować je i zaprezentować na spotkaniu z jak największą liczbą współpracowników. Spróbuj sprowokować dyskusję: nawet jeśli nie przekonasz ich od razu, uzyskasz wgląd w to, jakie mogą być kluczowe punkty.

(Czy czytałeś / słyszałeś o funkcji zmiany ?)

Absolutnie nie jest normalne, że grupa o takiej wielkości działa bez kontroli źródła - wielkość największej grupy programistów, którzy mogą efektywnie pracować bez kontroli źródła, jest mniejsza lub równa jeden. Jest to absolutnie niewybaczalne pracować bez kontroli wersji dla profesjonalnego zespołu dowolnej wielkości, a może nie czuję oszczędny, ale nie mogę wymyślić jakiegokolwiek powodu, dlaczego chcesz go zrzec.

Kontrola wersji to po prostu kolejne narzędzie - szczególnie potężne i zapewniające ogromne korzyści w stosunku do jego minimalnych kosztów. Daje to możliwość precyzyjnego zarządzania wszystkimi zmianami w zorganizowany sposób, z wszystkimi innymi przydatnymi rzeczami, takimi jak rozgałęzianie, automatyczne łączenie, tagowanie i tak dalej. Jeśli musisz zbudować wersję z wielu wersji temu, możesz sprawdzić kod od tego momentu i po prostu zbudować bez konieczności przeskakiwania przez inne obręcze.

Co ważniejsze, jeśli musisz napisać poprawkę błędu, możesz połączyć ją w aktualizację bez konieczności dostarczania nowych funkcji, nad którymi pracujesz - ponieważ są one w innej gałęzi, a jeśli chodzi o resztę rozwoju, martw się, jeszcze nie istnieją.

Doświadczasz oporu, ponieważ podważasz kulturę firmy. Dostosowanie ich zajmie trochę czasu, bez względu na to, co powiesz. Najlepsze, co możesz zrobić, to naciskać na to, a jeśli firma naprawdę nie chce się ruszyć, znajdź inną pracę, która lepiej pasuje do twojego poziomu jako programisty.

Czy to normalne, że grupa tego rozmiaru nie ma kontroli źródła?

Z mojego doświadczenia wynika, że ​​nie jest to norma, ale nie tak zupełnie niezwykła, jak sugerują inne odpowiedzi tutaj. Większość małych firm korzysta z kontroli źródła, ale znaczna ich liczba niestety nie.

Do tej pory podano mi tylko niejasne powody braku kontroli źródła - jakie powody sugerujesz, że mogą być ważne, aby nie wdrożyć kontroli źródła, biorąc pod uwagę powyższe informacje?

Zobacz to pytanie dotyczące SO, aby uzyskać dobrą dyskusję. Przyjęta odpowiedź brzmi:
„Nie ma dobrych powodów, aby nie używać kontroli wersji. Ani jednego”.

Czy są jeszcze jakieś powody kontroli źródła, które mógłbym dodać do swojego arsenału?

Konsensus między wszystkimi programistami i kierownikami projektów, których spotkałem, i oczywiście tutaj w sprawie programistów i SO jest taki, że kontrola źródła jest koniecznością. To zaakceptowana najlepsza praktyka . Jeśli ktoś zdecyduje się go zignorować, musi mieć bardzo mocne i przekonujące argumenty, dlaczego jest to właściwa decyzja dla niego (tj. Trochę więcej niż „nigdy go nie potrzebowaliśmy, więc dlaczego powinniśmy go potrzebować w przyszłości”). Argumenty, które przedstawiłeś do tej pory, koncentrują się na konkretnych kwestiach, być może powinieneś spróbować szerszego podejścia w stylu „wszyscy to robią, więc dlaczego my też nie?

Kontrola źródła jest dobra nawet dla jednego zespołu programistów. Każdy system kontroli źródła jest w zasadzie systemem kontroli wersji, który śledzi zmiany. Wyobraź sobie jednego programistę, który mógł usunąć część kodu i uważa, że ​​kod jest teraz wymagany. Czy uda mu się odzyskać stary kod?

Po prostu wybierz narzędzie, które ci pomoże. Rozmiar nie ma znaczenia wszędzie. Jakość ma znaczenie wszędzie.

Wygląda na to, że już korzystasz z systemu kontroli wersji, ale niezbyt dobrego. Wydaje się, że ludzie już rozpoznają potrzebę kontroli wersji. Wystarczy wprowadzić je na wyższy poziom - kontrolę wersji oprogramowania.

Gdybym to był ja, przedstawiłbym SCM jako ulepszoną wersję tego, co już robią. Chciałbym podkreślić, jak użycie dobrego narzędzia zautomatyzuje wiele pracy, która już trwa.

• Zamiast rejestrować zmiany w arkuszu kalkulacyjnym, system SCM śledzi nie tylko to, co się zmieniło, ale kto to zmienił i dlaczego.

• Jako bonus możesz wrócić do dowolnego punktu w życiu kodu i zobaczyć, co tam naprawdę było.

• Zamiast posiadania różnych wersji kodu w różnych folderach i konieczności przenoszenia / scalania rzeczy między folderami w celu przeniesienia zmiany, możesz zachować wszystko w tym samym miejscu i (co ważniejsze) pozwolić narzędziu na scalenie.

Jak już powiedzieli inni, spodziewam się pewnego oporu, więc prototypuję system, wykorzystując go do tego, co robię.

(BTW, faktycznie umieściłem swoje CV i inne dokumenty pod SVN. Z drugiej strony kilkakrotnie grałem role Menedżerów konfiguracji i integracji).

Do tej pory podano mi tylko niejasne powody braku kontroli źródła - jakie powody sugerujesz, że mogą być ważne, aby nie wdrożyć kontroli źródła, biorąc pod uwagę powyższe informacje?

• Opracowywany przez ciebie produkt to system kontroli wersji; menedżerowie obawiają się, że istniejące produkty nie będą miały wpływu na projektowanie i wdrażanie nowego produktu.

• Pomiędzy weekendami BASE skakania i biegania z bykami, poszukiwacze emocji lubią jeździć do pracy, zastanawiając się, czy wszystko poszło już do piekła.

• Unika wrogich przejęć. Kto chciałby kupić zestaw do tworzenia oprogramowania zarządzany w ten sposób?

Czy są jeszcze jakieś powody kontroli źródła, które mógłbym dodać do swojego arsenału?

• Już robisz kontrolę wersji, ale obecnie robisz to w najmniej wydajny, najbardziej pracochłonny i podatny na błędy sposób, jaki można sobie wyobrazić. Korzystanie z VCS pozwoli zaoszczędzić pieniądze, zaoszczędzić czas i poprawić jakość.

• Oszczędza miejsce na dysku. Większość systemów kontroli wersji zapisuje tylko delty między plikami. Obecnie zapisujesz całą kopię każdej wersji każdego pliku. (Tworzenie kopii zapasowych wszystkich tych kopii musi zająć dużo czasu i miejsca!)

• Kilku programistów może jednocześnie pracować nad tym samym plikiem i pogodzić różnice bez większych problemów. Scalanie zmian jest oczywiście możliwe bez VCS, ale prawie niemożliwe jest śledzenie, kto zmienił co, kiedy i dlaczego w takim przypadku.

• Daje programistom swobodę wypróbowywania nowych pomysłów, wiedząc, że mogą odzyskać dowolną wersję w dowolnym momencie.

• Lepszy proces ułatwia zatrudnianie i zatrzymywanie utalentowanych programistów.

Czy to normalne, że grupa tego rozmiaru nie ma kontroli źródła?

Nie definitywnie nie. Kiedy zaczynałem w mojej obecnej firmie, była jedna osoba, do której powinieneś wysłać zmieniony kod, a on by go scalił. W ciągu kilku dni mógłbym przekonać wszystkich do korzystania z SVN.

Do tej pory podano mi tylko niejasne powody braku kontroli źródła - jakie powody sugerujesz, że mogą być ważne, aby nie wdrożyć kontroli źródła, biorąc pod uwagę powyższe informacje?

Myślę, że powodem, dla którego słyszałeś tylko niejasne powody, jest to, że nie ma żadnych ważnych powodów, aby nie używać kontroli wersji.

Czy są jeszcze jakieś powody kontroli źródła, które mógłbym dodać do swojego arsenału?

Tak, jest wiele powodów.

1. Rozgałęzienie daje możliwość opracowania nowej funkcjonalności bez ingerencji w inne rozwiązania.
2. Każde zatwierdzenie zawiera informacje o tym, co dokładnie zostało zmienione, kto dokonał tej zmiany i kiedy ta zmiana została wprowadzona.
3. Możesz łatwo zatwierdzać poprawki błędów, wdrażać je wśród klientów i pomijać niedokończone nowe funkcje.
4. Możesz zachować różne wersje, jeśli klienci boją się przejść na nowszą wersję.
5. Możesz z łatwością pracować nad tym samym projektem (nawet tymi samymi plikami źródłowymi!).
6. Możesz łatwo cofnąć błąd, zachowując zmiany po popełnionym błędzie.

Niektórzy ludzie mają problem z uświadomieniem sobie, jak zły jest stan obecny, dopóki nie zobaczą czegoś lepszego dla siebie. Potrzebne jest dobre demo . Pokaż kilka faktycznych przykładów zadań, które można poprawić. „Wyśledzenie naszego obecnego systemu zajęło mi 4 godziny, ale ta jedna komenda kontroli źródła powiedziała mi natychmiast”.

Brak korzystania z kontroli źródła powoduje problemy, nawet dla programisty solowego. Prosty fakt, że możesz bezlitośnie edytować bez ryzyka utraty niczego, rekompensuje wysiłek uczenia się w ciągu tygodni lub dni.

To powiedziawszy, jeśli nie możesz przekonać swoich menedżerów do wprowadzenia kontroli źródła, zrób sobie przysługę i przynajmniej skorzystaj z czegoś takiego jak git lub merkurial lokalnie - jeśli coś wybuchnie z powodu braku kontroli źródła, przynajmniej nie będziesz ten, który to zrobił.

Moja firma używa GIT do kontroli wersji. Firma to jeden programista, jeden dyrektor generalny, jeden ochroniarz, jedna sprzątaczka i jeden recepcjonista. Wszystkie z nich to ja. Kontrola wersji źródłowej MUSI za każdym razem.

Sam pracuję nad wieloma projektami i nadal używam kontroli wersji. Rozmiar nie ma znaczenia. Zawsze pomaga mieć kontrolę wersji.

Jest powód, dla którego jest to numer 1 w teście Joela: http://www.joelonsoftware.com/articles/fog0000000043.html

Umożliwia także # 2 i 3 na liście.

Kilka lat temu byliśmy w podobnej sytuacji z sześcioosobowym zespołem. Jeden z programistów podjął krok instalacji SVN na serwerze deweloperskim, na którym znajdował się folder współdzielony, i po prostu zaczął go używać.

Wszyscy poszli w ich ślady i nie minęło dużo czasu, zanim wdrożyliśmy CI ( CruiseControl ) i zrewolucjonizowaliśmy nasz proces kompilacji i wydania, obejmując automatyzację i kontrole jakości.

WTF ?! To może być najbardziej śmieszne pytanie, jakie kiedykolwiek widziałem. Musisz znaleźć nową pracę. 15 programistów ?! Myślisz, że to mały zespół? To jest szalone. Menedżer powinien zostać natychmiast rozwiązany. Szczerze mówiąc, po przeczytaniu tego pytania będę miał koszmary. Poinformuj nas o produkcie, który sprzedajesz, abyśmy wszyscy wiedzieli, że go nie kupujesz! Nie wiem, co jest bardziej przerażające, to pytanie lub odpowiedzi mówiące, że to nie jest niezwykłe!

Nie mogę sobie wyobrazić, jak 15 programistów może pracować bez kontroli źródła. Jednak z:

(...) używa udziału sieciowego do hostowania swojego kodu źródłowego (...)

Zakładam, że stworzyłeś własną kontrolę wersji biedaka, taką jak VSS (również w oparciu o folder współdzielony). Jest to ryzykowne i nieefektywne.

Wyjaśnij swojemu szefowi, jak źle jest, zainwestuj w dwudniowe szkolenie SVN lub GIT i zacznij korzystać z prawdziwego systemu kontroli wersji, póki kod jest nadal w rozsądnej formie.

Jeśli nie popełniam kilka razy dziennie, a przynajmniej przed wyjściem do domu, czuję, że coś brakuje, coś jest nie tak.

Kiedyś pracowałem w firmie z zaledwie 2 programistami (ja + długowłosy administrator), w 1998 roku. Nawet wtedy korzystaliśmy z svn. To takie wygodne.

Kilka razy w mojej karierze straciłem dni pracy, ponieważ zrobiłem coś takiego jak mv zamiast cp, a następnie rm -rf. Zmusił mnie do płaczu i błądzenia po ulicach miasta w rozpaczy.

Przez 13 lat pracy w SE pracowałem w 5 firmach, byłem na niektórych konferencjach i nigdy nie spotkałem firmy, która nie używa kontroli wersji.

Jednak moja ulubiona firma zajmująca się projektowaniem wnętrz, 20 pracowników, używa białej tablicy do zarządzania projektami + współpracy. Wiedzą, że to po prostu źle, ale wydaje się, że nie mają czasu na aktualizację. Jakoś to działa. Nie pytaj mnie jak.

Bądź liderem. Bycie liderem oznacza robienie tego, co słuszne; proaktywne rozwiązywanie problemów. Przywództwo nic nie robi, ponieważ nie ma wystarczającej konsensusu. Dobry przywódca uczy się rozpoznawać sytuacje, w których należy budować konsensus i kiedy to robić. Jest to wyraźnie sytuacja, w której się robi. Brak kontroli kodu prędzej czy później wybuchnie ci w twarz.

Liderzy często nie zajmują oficjalnych stanowisk kierowniczych. Ludzie będą podążać za dobrymi, zdecydowanymi liderami bez względu na tytuł.

Jeśli twoje decydujące wysiłki zostaną zahamowane, szczególnie jeśli są podejmowane przez kierownictwo, jest to wyraźny znak, że możesz się stąd wydostać. To utrudnia rozwój zawodowy; a kompetentni programiści i niekompetentne kierownictwo nie mieszają się, a niekompetentni z mocą cię spieprzą.

OK, retrospekcje do mnie docierają. Wylogowywanie się Powodzenia.

1. Zdobądź stoper,
   • Policz czas spędzony w arkuszu kalkulacyjnym tylko na synchronizację wersji
   • Policz czas poświęcony na naprawę uszkodzonych wersji
   • policz, ile razy ludzie krzyczą na korytarzu „ edytuję main.c !, aby upewnić się, że nikt inny nie jest teraz!” .
   • policz liczbę skarg otrzymywanych od klientów, ponieważ ich poprawka zawierała inne zmiany
   • policz opóźnienie wydania tylko dlatego, że nie udało się zsynchronizować wersji
2. Stwórz powerpoint z tymi danymi, porównaj z tym, jak działa vcs.
3. Pokaż zarządzanie

To tylko wypadek, który czeka. Nie masz historii kodu i za jednym zamachem jeden z programistów mógł zniszczyć miesiące pracy. Jako mała firma nie możesz sobie pozwolić na tego rodzaju niepowodzenia.

Jesteś również bardzo widoczny na tym dysku udostępniania. Nawet przy dobrej kopii zapasowej, jak długo możesz sobie pozwolić na niedziałanie. 1 godzina, 1 dzień, 1 tydzień. Ile czasu zajęłoby założenie nowego serwera, przywrócenie go z kopii zapasowej itp. Ponownie, jako mała firma, prawdopodobnie nie masz dodatkowego sprzętu w trybie gotowości i możesz nie być w stanie łatwo upuścić pieniędzy, aby przyspieszyć wysyłkę itp.

Pomyśl także o przechowywaniu poza siedzibą firmy. Powódź lub pożar nie są tak niezwykłe. Co by się stało, gdyby po godzinach w budynku wybuchł pożar. Ile miesięcy pracy zostanie utraconych. Przydałoby się do tego repozytorium kodów zarządzanych, takie jak github. Nawet użycie prostego serwera SVN w hostowanej usłudze byłoby krokiem naprzód w tym obszarze.

LordScree, jestem w niemal identycznej sytuacji jak ty, mój bezpośredni zespół liczy około 15 programistów. Nie wierzę (prawie zgroza), że kontrola źródła nie jest używana. Moja początkowa odpowiedź na „powinniśmy używać kontroli źródła” brzmiała „nie mamy czasu na wdrożenie”. Dla mnie, podobnie jak noszenie bielizny, kontrola źródła nie jest opcjonalna. Po kilku miesiącach, ja też mam zgodę na wdrożenie TFS, wybranego przez organizację, ponieważ jest to stwardnienie rozsiane i ma 90-dniowy okres próbny. Podsumowując, bardzo trudno jest przekonać organizację o potrzebie kontroli źródła, gdy bez niej szmuglują. Mówię programistom, że za każdym razem, gdy tworzysz kopię zapasową plików, szczególnie z datą w kopii zapasowej nazwy pliku lub katalogu, jest to przykład, kiedy chcesz coś kontrolować. Ja nie Mam dla ciebie wspaniałe odpowiedzi, ale wierzę, że to rzadkie. Walczę w tej samej bitwie i będę Cię informować o postępach. I mam nadzieję, że nastąpi postęp, w przeciwnym razie mogę szukać gdzie indziej, ponieważ nie mogę pracować w chaosie!

mamy 3 członków personelu programistycznego i korzystamy z kontroli źródła. W moich osobistych projektach mam jednego programistę i korzystam z kontroli źródła. Jest to przydatne nie tylko do zarządzania zespołem, ale także do eksperymentowania bez obawy, że coś zniszczysz.

Najłatwiejszy sposób na przekonanie kierownictwa? Jest mniej ryzyka dla całego produktu i na dłuższą metę zwiększy produktywność programistów. Oba są również prawdziwe i oba podobają się menedżerom.

To nie jest normalny scenariusz i myślę, że powinieneś ciężko walczyć o zdobycie tego ustawienia w swojej firmie. Ma dalekosiężne korzyści i nie ma sensu zdawać sobie z tego sprawy, gdy zbliżasz się do dnia zagłady, i nie jest to sytuacja, w której się to mieści. Jeśli nie jest zepsute, nie naprawiaj tego

Jakikolwiek powód niewdrożenia może być tylko usprawiedliwieniem złej pracy lub błędem, który czeka.

Po prostu powiedz im, jak wspaniale jest znaleźć aplikację 1 stycznia tego roku

co powiesz na to, że ta funkcjonalność została dodana w marcu? Myślę, że musimy nieco rozszerzyć tę kwestię.

Wow, ten błąd 154256 został naprawiony w tym zatwierdzeniu.

mogę rozgałęzić aplikację i wysłać wdrożenie bez problemu chłopaki, których możesz kontynuować.

Może to trwać i trwało ... (pamiętaj, aby później dodawać komentarze do zatwierdzeń, które byłyby kolejnym pytaniem)

Kontroli wersji używam w projektach jednoosobowych i projektach roboczych, w których od 30 do 40 osób pracuje jednocześnie nad tym samym kodem. Kontrola wersji ma swoje zalety organizacyjne, ale możliwość przywracania plików i ukrytych zmian może naprawdę wyeliminować problem związany z zarządzaniem kodem ... i ostatecznie jest to najlepszy scenariusz dla programisty, więc mogą po prostu skupić się na kodowaniu.

Powody, dla których nie można korzystać z kontroli wersji, są dość ograniczone. Wszystko, co mogę wymyślić, to techniczny aspekt rzeczy.

• Krzywa uczenia się jest zbyt duża, aby przekształcić przebieg pracy całego personelu, aby wprowadzić system kontroli wersji, aby był opłacalny.
• Kierownik projektu nie uważa, że ​​wprowadzenie kosztów ogólnych związanych z zarządzaniem i utrzymywaniem repozytorium byłoby korzystne. (Głównie problem ze starszymi wersjami systemów)

Istnieje wiele powodów, aby używać systemu kontroli wersji. Przynajmniej przestań się poruszać. Pracuj z łatkami. Systemy kontroli wersji mogą robić dokładnie to, co mówisz.

• Możesz pracować nad kolejną wersją w tym samym czasie, gdy robisz poprawki błędów i wypuszczasz je osobno.
• Zamiast przenosić pliki z jednej lokalizacji do drugiej, aby nad nimi pracować, możesz utworzyć gałąź i scalić ją z serwerem głównym po zakończeniu.
• Każdy programista może mieć własną kopię kodu źródłowego, aby zapobiec problemom z tym samym projektem otwartym na wielu komputerach.
• Wypadki się zdarzają, jeśli kod zostanie poważnie uszkodzony, wystarczy cofnąć do ostatniego działającego numeru wersji.
• Kontrola wersji działa dobrze w połączeniu z modułami do śledzenia błędów i ciągłymi systemami integracji.

Ja osobiście jako zespół jednoosobowy używam wersjonowania, śledzenia błędów, ciągłej integracji, przeglądu kodu, sprawdzania spójności kodu, testów jednostkowych, testów selenu, analizy kodu źródłowego, i może być więcej, o czym zapominam. Przyznaję, istnieje niewielka krzywa uczenia się. Istnieje również kompromis dodatkowego czasu administracyjnego niezbędnego do automatyzacji dodatkowych kroków. Z mojego doświadczenia wynika, że ​​zaoszczędzony wysiłek przewyższa dodatkowy czas administracji.

Podczas mojej pierwszej poważnej pracy w 1990 roku byłem jedynym programistą pracującym w moim dziale i nie wiedziałem, jak korzystać z kontroli źródła.

Wkrótce potem się nauczyłem, odtąd nigdy nie widziałem projektu, który nie uczynił go jedną z pierwszych rzeczy, które założyli.

Prawie straciłem całą pracę w tym zadaniu, ponieważ usunąłem folder na niewłaściwym poziomie. Na szczęście przywiozłem kopię do domu na dyskietce 5 "tydzień wcześniej i byłem w stanie odtworzyć pracę tygodniową w ciągu kilku długich dni.

Sądzę więc, że uważam to za dopuszczalne, gdyby był to pierwszy projekt dla wszystkich członków zespołu i nikt nie wiedział lepiej, ale jeśli nawet jedna osoba mogłaby wyjaśnić korzyści, a zespół nadal nie słuchał, przeklasyfikowałbym mój opinia grupy od „naiwnych” do „niebezpiecznie niekompetentnych” (Odporność na używanie narzędzia o tak szeroko wykazywanych korzyściach jest niemal zbrodnicza - to tak, jakby twój zespół nie ufał „kompilatorom” i nalegał na zrobienie wszystkiego w języku asemblera ).

Dużo to napisałem ... w małych firmach inżynieryjnych / elektronicznych, gdzie robią dużo wbudowanego oprogramowania / sprzętu.

W tych miejscach SCM nie jest częścią kultury inżynierii elektronicznej. Zwykle mają jednego inżyniera na projekt, który musi tylko wykonać kopię zapasową najnowszej wersji.

Dlatego rozgałęzianie / scalanie, a nawet dzielenie kodu jest uważane za nieistotne. Ponadto firmy te mają prawdopodobnie ISO9000, więc proces, choć dziwny, jest prawdopodobnie udokumentowany.

W każdym razie ja / inni programiści zacząłem używać SCM osobiście.

Tam, gdzie pracuję, mamy ten sam problem. Obecnie próbuję przesunąć kontrolę źródła w „pod radarem”, aby obejść te same problemy, które masz. Używam skamielin do projektów, które rozwijam osobiście.

Niedawno skonfigurowałem serwer kopalny w sieci LAN firmy, więc teraz jest jeszcze wygodniejszy. Mam nadzieję, że wykazując przydatność niektórych mniejszych projektów, podważę opór i odsunę nas od status quo folderów sieciowych.

Najważniejsze powody, dla których słyszałem o niestosowaniu skamielin lub innych VCS:

1. Wielu „programistów” to dzieciaki skryptowe i nie rozumieją, jak z nich korzystać
2. Ci, którzy mogą się uczyć, uważają, że korzystanie z nich jest uciążliwe
3. Ci ludzie są starymi strażnikami, czują się dobrze w folderach sieciowych, więc każdy powinien być
4. Nikt nie ma czasu, aby go poprawnie skonfigurować lub nauczyć się go używać
5. Chociaż funkcje mogą być świetne, żadna z nich nie jest konieczna

Jak widać, próbuję obejść je, pokazując, że jest łatwy w użyciu, już skonfigurowany, łatwy do nauczenia, a funkcje są tego warte.

Wreszcie, nawet jeśli nie zmusisz ich do korzystania z kontroli źródła, wszystko jest w drzewie sieci. Fossil może wersjonować wszystko w całym drzewie i możesz go skonfigurować tak, aby działał za każdym razem, gdy nastąpi zmiana pliku, lub przynajmniej co godzinę. Zrobiłem to w przypadku niektórych naszych projektów, które „nie wymagały kontroli źródła”, co ostatecznie pozwoliło mi przywrócić dobrą wersję, gdy coś poszło nie tak.

Zrób to dobrze, a nawet nie będą wiedzieć, że to zrobiłeś. Następnie możesz być bohaterem, który przywraca zepsutą wersję i pokazuje, jak przydatne jest twoje narzędzie.

Teraz, gdy narzędzia DVCS, takie jak Git i Mercurial, są dostępne i niezwykle łatwe w konfiguracji i obsłudze, naprawdę nie ma wymówki, aby nawet zespół 1 (!) Nie korzystał z kontroli źródła. Nie chodzi o wielkość zespołu, chodzi o skomentowanie historii zmian i możliwość obsługi przepływów pracy, takich jak rozwiązywanie problemów produkcyjnych podczas pracy nad nową wersją i śledzenie stanu kodu źródłowego dla różnych wersji.

Gdyby zaproponowano mi pracę w zespole, który osiągnął taki rozmiar, a żaden z programistów nie zasugerował korzystania z VCS, lub gdyby „zarządzanie” im zapobiegło, odmówiłbym. To po prostu niedopuszczalny sposób pracy w tych dniach.

Powinieneś natychmiast uzyskać kontrolę wersji GIT. Możesz go używać nawet z Google Code Project Hosting. Kiedy inni widzą, że zatwierdzasz zmiany jednym kliknięciem, podczas gdy ręcznie kopiują rzeczy, być może zmieniają zdanie na ten temat.

Łał po prostu łał. Chociaż nie sądzę, że jest to najlepszy sposób na kontrolę kodu, nie jest niczym niezwykłym, że pracowałem w firmie z 6 programistami i nie stosowałem żadnej kontroli źródła, mieli oni swój własny wewnętrzny sposób zarządzania plikami, menedżera wydań i co nie nadzorowałoby wszystkich zmian. W rzeczywistości mantra głosiła, że ​​nowa funkcjonalność może być dodawana do projektów, o ile jakiś rodzaj przełącznika jest owinięty wokół tej funkcjonalności.

Na przykład pracowaliśmy nad siecią społecznościową ab grade napisaną w PHP, a klient chciał, aby funkcjonalność mogła subskrybować profil użytkownika. Zasadniczo funkcjonalność została zapakowana w taki czek, jeśli (ENABLE_SUBSCRIBE_FUNCTIONALITY == true) {następnie uruchom kod}

W miejscu, w którym pracowałem, nigdy nie pracowało więcej niż jeden programista naraz nad danym plikiem, głównie wszystko było modułowe, więc w tym przypadku nie było potrzeby kontroli źródła. Uważam jednak, że zalety kontroli źródła znacznie przewyższają wady jej braku w większości przypadków.

Sam fakt, że Twoja firma ucieka się do arkuszy kalkulacyjnych dokumentujących zmiany plików, i to, co zostało zmienione, gdy coś takiego jak Git lub Subversion może sobie z tym poradzić, jest absolutnie śmieszne.

Wygląda na to, że jesteś przekonany, ale ktoś w organizacji nie upoważnia cię do tego. Jak możesz przeczytać z innych komentarzy, powinieneś to zrobić.

Niektóre informacje można znaleźć tutaj: http://www.internetcontact.be/scm/?page_id=358

Najważniejsze jest to, że Twoi klienci są zmuszani do ostatniego „niestabilnego” oddziału, a jeśli Twoje umowy z klientami powodują, że jesteś odpowiedzialny za wdrażanie niestabilnych wersji, Twoja firma traci pieniądze. Powinieneś naprawdę skupić się na stabilności wydania. Jest to główny powód kontroli źródła i, jak się wydaje, twoja główna awaria. Pozostałe nie ulegną tak dużej poprawie dzięki zastosowaniu kontroli źródła, ponieważ masz już alternatywne systemy.