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

152

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ę

LordScree
źródło
3
Wygląda na to, że nie są bardzo daleko od współpracy z DVCS, takim jak Mercurial. Ludzie, którzy przeciągną stopy, nadal mogliby „używać” Mercurial, gdyby istniejący folder został faktycznie przekształcony w repozytorium. Z ich punktu widzenia wyglądałoby to prawie tak samo, a gdyby nie, moglibyście wprowadzić zmiany.
John Fisher,
19
AKTUALIZACJA (Prawie rok po tym, jak zadałem to pytanie): W ciągu ostatniego roku prowadziłem kampanię, nakłaniałem, błagałem i oszukiwałem, aż doszedłem do punktu, w którym byłem cholernie kilka razy zwolniony z powodu niesubordynacji. Z przyjemnością stwierdzam, że dana firma w końcu poważnie przygląda się kontroli źródła, w celu wdrożenia TFS po około miesięcznym okresie próbnym, podczas gdy zapewniamy, że wszyscy programiści są zadowoleni z nowych procesów. W dużej mierze pozytywna odpowiedź, jaką otrzymałem od programistów na to pytanie, dała mi pewność, że mogę je realizować. Twoje zdrowie.
oliver-clare
10
Programiści, którzy nie używają kontroli źródła, są równoważni chirurgom, którzy nie myją rąk ani nie używają brudnych narzędzi do działania. Jest to zawodowo niekompetentne i nie ma usprawiedliwienia dla tego rodzaju nadużyć.
Tim
1
Mimo że elektryczność została wynaleziona dawno temu i jest wszechobecna w naszym codziennym życiu, niektórzy ludzie nadal decydują się na pisanie kodu świecącego na świecach na woskowanej planszy za pomocą spiczastego patyka.
Newtopian
2
15 deweloperów to raczej mały sklep.
Louis Kottmann

Odpowiedzi:

108
  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 ?)

Benjol
źródło
2
Dziękuję za (niestety) konieczne rozróżnienie między normalnym a niezwykłym. +1
keppla
29
+1 za ignorancję / dziwactwo. Jeśli jesteś profesjonalnym programistą i nie używasz SCM, to nie jesteś. Kropka.
Chris Thornton
2
Tylko z ciekawości, kto zapłaciłby 300 USD za osobę za kontrolę źródła (Valut, zgodnie z linkiem do wiki), gdy istnieje niezliczona ilość bezpłatnych aplikacji?
Rob
11
w punkcie 2: Nie widzę żadnego uzasadnionego powodu, aby zespół dowolnej wielkości (w tym zespół 1) nie używał kontroli źródła ...?
James Khoury
1
Kolejny powód, dla którego niektóre małe grupy nie mają kontroli wersji - jest pewien narzut i nauka związana z konfiguracją. Potrzebujesz serwera do obsługi bazy kodu. Musisz administrować serwerem i oprogramowaniem VC na tym serwerze. Należy wykonać kopię zapasową bazy danych VC, utworzyć i przetestować plan odzyskiwania oraz monitorować kopie zapasowe, aby upewnić się, że kopia zapasowa / odzyskiwanie jest nadal prawidłowe. Cała ta administracja wymaga czasu. W organizacjach o słabym zarządzaniu oprogramowaniem czas, który programiści spędzają na administrowaniu systemem VC, może być karany, a nie nagradzany.
Jay Elston,
185

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.

Jon Purdy
źródło
45
Niestety, niewybaczalne nie oznacza niecodzienności ...
Marjan Venema
6
Nie wspominając o tym, że istnieją DARMOWI dostawcy kontroli źródła, więc nie jest to tak kosztowny sposób działania.
Mantorok
9
Nakłanianie ludzi do zmiany nawyków, przepływu pracy i procedur może być kosztowne.
user1936
4
@Rook: Oczywiście. Ale wolę mieć siatkę bezpieczeństwa, której nie potrzebuję, niż potrzebować takiej, której nie mam. Programowałem na długo, zanim dowiedziałem się, czym jest system kontroli wersji. Chociaż nie jest to konieczne, pozbawianie się dobrego narzędzia jest głupie.
Jon Purdy
12
Nie wyobrażałem sobie rozwoju bez kontroli źródła, nawet gdy jestem jedynym programistą.
webbiedave
34

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?

Treb
źródło
„znacząca liczba nie”… hmm… z 15 programistami na tej samej podstawie kodu? Tam gdzie jestem, dodaliśmy SCC, kiedy byliśmy ... 5 + 2 programistami na tej samej podstawie kodu i czuliśmy, że najwyższy czas na to. Mam nadzieję, że 15 programistów i brak SCC na tej samej podstawie kodu jest wysoce nietypowy :-)
Martin Ba
3
@Martin: Nie jest to niezwykłe znaleźć 15 osób, którzy wszyscy cierpią z powodu nie wymyślił tu syndrom ... Przypuszczam, że może 5% wszystkich małych (<20 pracowników) firm nie mają kontroli źródłowego. Mam nadzieję, że twoje doświadczenie różni się od mojego ;-)
Treb
+1 za nietypowe, niestety.
Jonas
6
+1 za nietypowe. Niektóre osoby po prostu nie rozumieją, że korzyści wynikające z kontroli kodu źródłowego przewyższają koszty. Obawiają się kosztów i integrują się, kopiując pliki lub łatki do „centralnego” obszaru roboczego scalania „kompilacji”; głównie dlatego, że wymyślili, że to zadziała i nikt nie inwestuje w środowisko programistyczne. Zazwyczaj wynika to z przekonania, że ​​mają tak wiele pracy do wykonania w kodzie, że nie mogą tracić czasu na rozwój środowiska. Uważam, że czas zaoszczędzony dzięki bardziej wydajnemu środowisku jest większy niż zwrot inwestycji dewelopera pracującego nad nim
Edwin Buck
27

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.

Kangkan
źródło
4
+1, jestem obecnie jednym zespołem programistów i używam kontroli źródła. Korzystam nawet z kontroli źródła w domu, aby zarządzać osobistymi dokumentami niezwiązanymi z tworzeniem oprogramowania, takimi jak przepisy kulinarne i moje CV.
wałek klonowy
1
+1, wiele małych sklepów zaczyna od plików zip jako swoich archiwów. Myśląc: „Mogę wrócić do tego punktu, więc po prostu spakuję wszystko”. To wcale nie to samo. Po zapoznaniu się z SCM i wspaniałymi narzędziami zbudowanymi na nim (log, diff, wina itp.) Nigdy nie wrócisz.
Chris Thornton
5
Kolejne świetne zastosowanie dla SCM: Wchodzę w poniedziałek, zastanawiam się nad czym do cholery pracowałem w ostatni piątek. Robię tylko różnicę lub patrzę na ostatni dziennik meldowania i natychmiast wracam do strefy.
Chris Thornton
1
Imagine of a single developer, who might have removed some code and feels that the code is now required. Can he get the old code back?Tak, po prostu używam ostatniej kopii zapasowej, którą zrobiłem ręcznie, kilka tygodni temu, i wykonuję kopie zapasowe, gdy chcę wprowadzić istotną zmianę. Nie zawiodło mnie jeszcze przez kilka lat i nigdy nie potrzebowałem (lub czułem, że powinienem był użyć) kontroli źródła ...
Mehrdad,
Jestem jedynym, który zajmuje się rozwojem w naszej firmie (zajmuję się także IT), a kiedy zaczynałem, nie używałem kontroli źródła, nigdy nie było katastrofy, ale w końcu zdałem sobie sprawę, jak bardzo jesteśmy na krawędzi. Zainstalowałem Mercuarial nieco później, bez wcześniejszego korzystania z niego, a dzięki interfejsowi Windows stał się on bardzo pomocny.
Tony Peterson
17

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

jwernerny
źródło
9

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.

Caleb
źródło
1
W punkcie drugim wiele VCS zapisuje delty, ale Git zapisuje cały plik dla każdego unikatowego skrótu pliku. Ale to nie ma znaczenia; miejsce na dysku jest tanie, a kod źródłowy niewielki. gitready.com/beginner/2009/02/17/how-git-stores-your-data.html
James
8

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.
Geerten
źródło
„była jedna osoba, do której powinieneś wysłać zmieniony kod, a on by go scalił” - To nie brzmi tak źle. Wiele projektów typu open source działa w ten sposób. Łaty wysyłasz do opiekuna. Ale to oczywiście nie będzie skalowane do dużych zespołów.
Alex Jasmin
6

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

Karl Bielefeldt
źródło
Z tego też bym skorzystał. Czytałem tylko o korzyściach płynących z kontroli źródła, ale nigdy sam tego nie doświadczyłem. Zastanawiałem się nad ustawieniem SVN w domu (ale obecnie zajmuję się domem i nie mam dużo czasu ...!)
oliver-clare
5

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

tdammers
źródło
4
tak, nie ma powodu, aby nie używać go sam, a następnie przypadkowo pokaż jego moc współpracownikowi, gdy najmniej się jej spodziewa.
gtrak
5

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.

João Pinto Jerónimo
źródło
4

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.

Burhan Ali
źródło
4

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!

j-dog
źródło
3

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.

Michał Šrajer
źródło
2
Nie jestem pewien, czy potrzebujesz dwóch dni na naukę SVN. Z 15 programistami nie wszyscy mogą „wyjść ze szkoły”. Z pewnością połowa już go kiedyś gdzieś używała.
Michael Blackburn,
1
@MichaelBlackburn: Zgadzam się. Nie wyraziłem się jasno. Myślałem o 2 dniach na szkolenie i konfigurację (repozytorium konfiguracji, kod importu itp.)
Michał Šrajer
3

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.

me1974
źródło
1
svnnie istniał w 1998 roku.
Faheem Mitha
3

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.

radarbob
źródło
Dzięki stary. Podoba mi się definicja lidera „postępującego właściwie”, który różni się od definicji menedżera „postępującego właściwie”. To znaczy, że menedżer robi to, co robi we właściwy sposób, ale może nie być to właściwe. Lider postępuje właściwie, ale często potrzebuje menedżera, aby zrobić to dobrze. Zdecydowanie warte +1 :)
oliver-clare
2
  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
cctv
źródło
2

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.

Bill Leeper
źródło
2

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!

mmf
źródło
Myślę, że moim najsilniejszym argumentem za kontrolą źródła było ryzyko, że firma go nie posiada. Nieprawidłowe wydanie produktu może kosztować godziny pracy, a nawet dni czasu na uporządkowanie - nie wspominając o uszkodzonej relacji z klientem. Jest to realne ryzyko bez kontrolowanej kontroli źródła ze względu na liczbę ręcznych kroków potrzebnych do wydania oprogramowania i śledzenia rzeczy takich jak wersje dla każdego klienta. Spróbuj podejść z biznesowego punktu widzenia, ponieważ menedżerowie chętniej słuchają tych argumentów niż po prostu „wszyscy korzystają z nich, więc powinniśmy”.
oliver-clare
Innym czynnikiem mającym wpływ na to było to, że akredytacja ISO 9001 w moim miejscu pracy patrzy na firmy informatyczne z powodu braku kontroli źródła. Akredytacja jest przydatna przy składaniu ofert na nowe projekty i partnerstwa biznesowe, ponieważ jest to często szukane w dokumentacji przetargowej. Powodzenia w walce!
oliver-clare
1

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.

Nicholas Smith
źródło
1

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)

V4Vendetta
źródło
1

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.

tori
źródło
1

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.

Steve Buzonas
źródło
1

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

Bill K.
źródło
1

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.

msr
źródło
0

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.

Spencer Rathbun
źródło
0

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.

Jaskółka oknówka
źródło
Kontrola wersji była łatwa w konfiguracji za pomocą Safe Source i SVN. Nawet CVS. (Git NIE jest łatwy do skonfigurowania i używania w środowisku Windows)
Tim
0

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.

Pan Smith
źródło
W pełni się zgadzam. Instalator Git jest niezwykle łatwy w użyciu i możesz zacząć działać w kilka minut. Zaawansowane funkcje mogą czekać, podstawowa kontrola wersji nie może czekać. cd topleveldirectory; git init; git add *; git commit -m "initial commit"
dustmachine
0

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

Dwayne Charrington
źródło
0

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.

Yves
źródło