Czy dobry programista może nigdy nie używać kontroli wersji? [Zamknięte]

73

Szukam programisty, który pomoże rozwiązać trudną sytuację.

Dotychczasowe wywiady były zaskakująco rozczarowujące. Najlepszym jak dotąd kandydatem jest bardzo doświadczony programista, który nigdy nie korzystał z oprogramowania do kontroli wersji.

Problem sam w sobie może nie być zbyt poważny, ponieważ można się go szybko nauczyć.

Ale jest głębszy aspekt, który mnie martwi:

Jak można aktywnie rozwijać oprogramowanie przez 10-15 lat bez konieczności kontroli wersji?

Czy sam fakt, że nie szuka się rozwiązania problemu śledzenia, świadczy o złym podejściu do programowania?

lortabak
źródło
25
Kto powiedział, że nie potrzebował kontroli wersji? Potrzebował go i myślę, że zrobił to ręcznie. Powiedział to, że programista, który to robi, wydaje się bardzo odporny na naukę czegoś nowego - bądź na to przygotowany.
Doc Brown
6
@ e-MEE zależy, możesz nauczyć się aktualizacji / rozwiązania / zatwierdzenia w ciągu 30-60 minut, ale nikt nie uczy się, jak działa (d) vcs w ciągu godziny. Większość osób, które używają go od lat, nadal go nie rozumie.
atamanroman
3
@ConradFrix Carrot Cake :)
Chad Harrison
7
Dobry programista może nigdy nie używać kontroli wersji, jeśli w kalendarzu jest napisane, że dziś jest 1981.
Kaz
7
To brzmi jak klasyczny przypadek kogoś, kto nie ma 10-letniego doświadczenia, ale raczej 1 rok doświadczenia powtarzany 10 razy.
Jeanne Pindar

Odpowiedzi:

90

Pracowałem przez około 11 lat w firmach, które nie korzystały z kontroli źródła. Udało nam się (głównie poprzez komentowanie zmian i przechowywanie kodu na centralnym serwerze, który można odzyskać w dowolnym momencie). Nigdy tak naprawdę nie pytaliśmy, czy istnieje lepszy sposób. To powiedziawszy, było to również w czasach, gdy miałem całą bibliotekę MSDN w formie książki na moim biurku.

Tak, programowanie istniało przed Internetem.

Z trudem widzę, jak możesz teraz spędzić ponad 10 lat w branży bez wpadania w kontrolę źródła. Ale chciałbym wyrazić współczucie, uwierzyłbym, że to możliwe i nie odrzuciłbym kandydata pod tym względem. Zbadałbym i dowiedziałem się, jak kandydat sobie z tym poradził.

Ewentualnie mogę zapytać, czy problem stanowiła moja rozmowa kwalifikacyjna. W jaki sposób był najlepszym kandydatem? Czy istnieją inne nowoczesne techniki programowania, których nie ma, a ja po prostu nie zadaję odpowiednich pytań? Gdybym zadawał właściwe pytania, czy inny kandydat świeciłby?

Na koniec, nie bój się odrzucić wszystkich kandydatów, jeśli masz wątpliwości. Rozpoczęcie od nowa zajmuje dużo czasu, ale zatrudnienie niewłaściwej osoby jest bardziej czasochłonne.

pdr
źródło
17
+1, to interesująca odpowiedź. Jednak nie do końca zgadzam się z „w tamtych czasach kontrola źródła kosztowała sporo pieniędzy” . RCS istnieje od 30 lat, CVS - 21 lat; Oba są open source.
vartec
8
+1: Nadal tu pracuję . W tym roku w końcu otrzymujemy kontrolę źródła (w dużej mierze dzięki mnie). Nie sądzę, że wszyscy jesteśmy okropnymi programistami z powodu braku tego do tej pory, ale jestem cholernie zadowolony, że się pojawi
oliver-clare
3
Jeśli kandydat rozumie zasady Kontroli Źródła, nie widzę problemu. Doświadczony programista powinien być w stanie szybko przyswoić „składnię” dowolnego systemu. Chciałbym zadać jedno pytanie - czy to całe doświadczenie w jednym miejscu? Jeśli tak, to może nie był w stanie wprowadzić systemu. Jeśli jego doświadczenie dotyczyło różnych firm, sięgnę trochę dalej. Liczba firm z zespołami programistycznymi, które nie korzystają z kontroli źródła, musi być obecnie minimalna.
BIDeveloper
4
+1 za punkt dotyczący zadawania właściwych pytań. Zastanawiałem się, co czyni go również najlepszym kandydatem.
shambulator
3
@Ramhound: czy uważasz, że przy ręcznej kontroli źródła potrzebujesz mniej sprzętu i mniej czasu na tworzenie kopii zapasowych? Z mojego doświadczenia wynika, że ​​jest odwrotnie.
Doc Brown,
49

Myślę, że to zależy od jego postawy. Jeśli jest bardzo doświadczonym programistą i dobrym programistą, myślę, że byłby w stanie szybko wybrać system kontroli wersji. Może o tym mówić na dwa sposoby:

  • Dobry

    Nigdy nie korzystałem z kontroli wersji, ale jestem bardzo podekscytowany nauką i wygląda na to, że naprawdę pomogłoby to usprawnić programowanie. Nie potrzebowałem go tak bardzo, ponieważ pracowałem sam nad projektami.

  • Zły

    Kontrola wersji to tylko modne hasło, które powoli umiera w branży. Jestem ponad kontrolą wersji.

Pigułki przeciwwybuchowe
źródło
17
Zgodziłbym się, że mogło to być ważne 10 lat temu, ale teraz? Powiedziałbym, że to nie „Dobry / Zły”, ale „Zły / Okropny”
vartec
24
Nawet jeśli pracujesz sam, korzystanie z VCS jest niezwykle cenne. Po przejściu projektu z „prawie działa” do ponownego uruchomienia go i bez możliwości powrotu do wersji „prawie działającej”, przyrzekłem, że wszystko włożę do VCS bez względu na to, jak mały jest projekt .
alroc
11
„Bardzo się cieszę, że się uczę” - To nie jest jakiś drogi produkt komercyjny, taki jak Coherence. Kontrola źródła to coś, z czym każdy może się zapoznać. Jeśli czytasz jakiekolwiek blogi na temat tworzenia oprogramowania, powinieneś o tym wiedzieć.
andy boot
7
+1 za tę odpowiedź. Nie jest oznaką dobrego programisty, że ma on wszystkie umiejętności. Chodzi o to, że może on podnieść dowolną wymaganą umiejętność.
Steven
2
@Steven: Nie. Wcale nie. Zgodnie z tą logiką 8-latek może zostać zatrudniony, ponieważ może zająć się programowaniem. IMO ma, lub powinien być, podstawowe umiejętności wymagane do uznania programisty. Biegła znajomość języka programowania to jedna, znajomość i wykorzystanie dowolnego VCS to inna. Jest więcej.
Steven Evers
34

Pozwól, że dam ci trochę perspektyw na tworzenie oprogramowania w DOS i Windows od ponad 20 lat.

Oprogramowanie do kontroli wersji w świecie Windows / PC było często zawodne we wczesnych latach 90-tych. Visual Sourcesafe (VSS) dotyczył najlepszego systemu Windows, ale może być dziwaczny i wielu programistów go nienawidzi. Niektóre zespoły po prostu nie chciałyby wykorzystać ich po poradzeniu sobie z tą sytuacją.

Większość innych opcji VCS w tamtym czasie nie była oparta na systemie Windows i dlatego rzadko była używana w zespołach programistów systemu Windows. Niektóre z nich były drogimi rozwiązaniami, a rozwiązania typu open source nie były tak łatwo akceptowane, jak obecnie.

W wielu przypadkach, pod koniec lat 90., na początku 00., jeśli zespół Windows nie korzystał z VSS, nie używali niczego do kontroli źródła, oprócz wewnętrznych konwencji. Wiele z nich nadal nie używa VCS, pomimo wyrafinowania Team Foundation Server (TFS) i świetnych darmowych opcji, takich jak git i SVN.

Możliwe, że ktoś, kto przez lata pracował w małym zespole programistów Windows, nie korzystał z VCS. Przeprowadziłem wywiady z, a nawet wykonałem prace kontraktowe w niektórych miejscach, w których ich nie używałem lub które były bardzo przypadkowe w związku z ich wykorzystaniem.

Nie sądzę więc, aby brak doświadczenia twojego kandydata w tym obszarze stanowczo brzmiał „nie”, ale prawdopodobnie chcesz zagłębić się w ich poprzednią sytuację zawodową, aby dowiedzieć się, dlaczego brakuje tego w ich doświadczeniu. Będziesz także chciał zbadać ich stosunek do kontroli wersji. Czy uważają, że to dobry pomysł, ale nie pozwolono im realizować go na poprzednim stanowisku, czy też uważają, że to strata czasu?

jfrankcarr
źródło
18
VSS nie był „dziwaczny” - był po prostu zły. Uszkodzone repozytoria i utrata danych były częste, ale możesz nie odkryć ich przez tygodnie lub miesiące po wystąpieniu problemu, chyba że przeprowadzałeś codzienną kontrolę integralności (i powodzenia odzyskiwania z niego nawet wtedy). Blokowanie i udostępnianie plików było okropne. Programiści nienawidzili tego, ponieważ ich życie stało się piekłem - dokładne przeciwieństwo tego, co powinien zrobić VCS.
alroc
@alroc - Wierzcie lub nie, ale były pewne mniej niezawodne i dziwniejsze. Miałem niefortunne korzystanie z jednego z nich około 1995 roku. Nigdy nie miałem poważnego problemu z niezawodnością VSS, ale słyszałem opowieści o nieszczęściu od innych. Znam niektóre organizacje, które przestały używać VCS po złych doświadczeniach z VSS.
jfrankcarr
UGGH, w przeszłości próbowaliśmy kontroli źródła Powerbuildera. Aktywnie spowodowało to, że straciliśmy kod źródłowy. PB ulegnie awarii, a każdy wyrejestrowany pbl stanie się niedostępny dla wszystkich innych. Co to był za żart.
GrandmasterB
Pracowałem przez 1,5 roku w sklepie, który korzystał z Visual Source Safe. Jeden z najlepszych programistów rujnowałby repozytorium za każdym razem, gdy próbował sprawdzić swój kod przez telefon (tak, to było dawno temu). Jeden z moich najmniej ulubionych systemów VCS.
GlenPeterson
Użyliśmy tlib ( burtonsys.com/index.html ) przy jednym zadaniu w środowisku DOS. To prawda, że ​​miało to miejsce w 2005 roku, ale wyglądało na to, że używali go przez jakiś czas.
Doug T.
29

Nie możesz kontrolować wersji bez oprogramowania do kontroli wersji? Zapytaj, jak zarządzali swoim kodem. Może istniał już system domowy.

Chęć ręcznego robienia rzeczy, odkrycie koła i opieranie się zmianom nie są niczym nowym w programowaniu. Czy zamierzasz ślinić się nad kandydatem korzystającym z Visual Source Safe i „tylko” VSS?

Próbując znaleźć talent, musisz umieć odróżnić: nie można, nie ma i nie będzie.

JeffO
źródło
Zanim dowiedziałem się o kontroli wersji i jej przydatności (odkryłem ją po 2 latach nieprofesjonalnego programowania hobbystycznego), nierzadko miałem pięć folderów z „kopiami zapasowymi” kamieni milowych projektu - prymitywny VCS.
orlp
„Nie można, nie mam, nie chcę i nie wolno”? Słyszałem o miejscach, które nie zgodziłyby się na kontrolę źródła, ponieważ podobały im się dżungle, którymi były ich dyski sieciowe.
Philip
19

Nie ma usprawiedliwienia dla nieużywania kontroli wersji, nawet w przypadku małego projektu opracowanego przez jednego programistę. Konfigurowanie lokalnej kontroli wersji jest trywialne, przynosi ogromne korzyści. Każdy programista, który nie wie, że nie można tego uznać za dobry ani doświadczony.

Jeśli chodzi o firmy postrzegające kontrolę wersji jako „nowość”, której nie chcą wprowadzić:

  • SCCS został wydany w 1972 roku ( 40 lat temu )
  • RCS został wydany w 1982 roku ( 30 lat temu ) i jest całkowicie otwarty i darmowy
  • CVS został wydany w 1990 roku ( 21 lat temu ), również całkowicie open source i za darmo
vartec
źródło
20
Nie jestem pewien, czy SVN jest najlepszym przykładem konfiguracji „ponad trywialnej”. Niektóre pliki, które musisz edytować bezpośrednio w repozytorium, mogą być kłopotliwe. Utworzenie lokalnego DVCS nie jest trywialne. A założenie konta BitBucket / GitHub i klonowanie repozytoriów z niego nie jest o wiele bardziej skomplikowane
pdr
9
@vartec: To, co poza trywialne, jest git init. Link do strony może sprawić, że ucieknę, ponieważ wydaje mi się to dość skomplikowane.
maaartinus
7
@vartec: Twierdziłbym, że git i hg są łatwiejsze do zrozumienia przez początkującego VCS niż ktoś, kto używa scentralizowanego VCS od lat i łatwiejsze niż CVCS dla początkującego. Wystarczy spojrzeć na sekcję Układ repozytorium na tej stronie, jakbyś go jeszcze nie rozumiał. Pomyśl „Mam tutaj repozytorium, chcę je tutaj sklonować”.
pdr
8
@vartec: Hmm. Nie mogę się zgodzić Lubię być w stanie rozgałęziać się i klonować, nawet gdy pracuję sam. Czasami mam pomysły. A czasem są źli :).
pdr
4
Pracowałem w firmach, w których kierownictwo odrzuciło kontrolę nad wersją. To nie była opcja. I zrobiliśmy ciekawe i złożone projekty. Nie sądzę, że jestem najgorszym deweloperem z tego powodu. W domu też go nie używam, choć przyznaję, że to rozważałem.
Picarus
14

Programista, który nigdy nie używał kontroli wersji, prawdopodobnie nigdy nie współpracował z innymi programistami. Prawdopodobnie nigdy nie rozważyłbym zatrudnienia takiego programisty, niezależnie od jakichkolwiek innych danych uwierzytelniających.

JesperE
źródło
34
Nie zgadzam się. Nie stosowanie kontroli źródła wymagałoby znacznie wyższego poziomu współpracy z innymi programistami niż normalnie. I może nawet iść tak daleko, aby powiedzieć, że jeśli trafiłeś ze środowiska, gdzie nie ma kontroli źródła, to naprawdę poznać znaczenie współpracy
Oliver-Clare
12
To chwalebnie zamiatające stwierdzenie i oczywiście nieprawdziwe.
Murph
3
Po prostu nie chciałbym zatrudnić programisty, który nie wie, jak korzystać z nowoczesnych narzędzi. Może on / ona umieć pisać niewiarygodnie ładny kod, ale uważam, że przynajmniej podstawowa znajomość kontroli wersji jest absolutnym wymogiem.
JesperE
6
Wiele osób tutaj wydaje się być zagmatwanych, nie będąc narażonymi na VCS i aktywnie odmawiając korzystania z niego w nowej pracy. Co jeśli po prostu nigdy nie przyszło mu to do głowy / ich w poprzednim miejscu pracy lub nie było werbalne przez kierownictwo? To powiedziawszy, byłby to krytyczny problem, gdybym zatrudniał, a ich chęć do nauki byłaby dla mnie trudnym wymogiem.
György Andrasek
5
Przerażające, że tak wielu ludzi tutaj uważa brak kontroli źródła za coś normalnego lub akceptowalnego.
JesperE
12

Wygląda na to, że czerwona flaga jest w porządku, ale zagłęb się w to, dlaczego go nie użył. Nadal oczekiwałbym, że solo programista użyje kontroli wersji, szczególnie za dziesięć lat, ale byłbym bardziej wybaczający niż gdyby pracował w zespole i nigdy nawet nie próbował wprowadzić kontroli wersji.

Eoin Carroll
źródło
6
+1: Byłbym przerażony, gdybym był bezrobotny tylko dlatego, że mój obecny menedżer nie dostrzegł znaczenia kontroli źródła. Przynajmniej używam kontroli źródła do wszystkich moich osobistych projektów, więc nie byłabym całkowicie zepsuta przez tę sytuację ...
oliver-clare
2
@LordScree - Praca nad obszerną witryną może być trudna do samodzielnego wykonania, ale nadal możesz nauczyć się korzystać z kontroli źródła poza pracą.
JeffO
9

Nie byłbym religijny z powodu braku doświadczenia w kontroli wersji. To tylko narzędzie. Na koniec możesz pobrać podstawy svn lub git za dzień lub dwa. Resztę odbierzesz z czasem. I nie mogę uwierzyć, że żaden na wpół przyzwoity kandydat nie byłby w stanie zmieścić się, gdyby pracował w środowisku korzystającym z kontroli źródła.

Korzystanie z kontroli źródła jest bardziej nawykiem niż umiejętnością. Ktoś, kto nigdy go nie używał, może wyolbrzymić wymagany wysiłek i nie docenić uzyskanych korzyści. W końcu dobrze mu szło. Dopiero po tym, jak faktycznie użyje kontroli źródła, wyrośnie, aby to docenić.

Pytanie, które powinieneś zadać, to jak sobie poradził przy braku kontroli źródła? To może ci powiedzieć coś o nim io tym, jak zarządza swoją pracą.

scrwtp
źródło
4
Zdecydowanie muszę się dowiedzieć, jak zarządzał aktualizacjami, wydaniami itp. Bez kontroli wersji
ChrisF
4

Zostawiasz wiele informacji na temat jego doświadczenia.

Zasadniczo powiedziałbym, że jest bardzo możliwe, że programista może mieć 10-15 lat doświadczenia bez wiedzy o kontroli wersji. Kodowanie przez 10 lat nie jest równoznaczne z ciągłym uczeniem się nowych technik programowania przez 10 lat.

Jestem bardzo młody i widziałem starych i „doświadczonych” inżynierów oprogramowania, których kodu nigdy nie chciałbym dotykać. To powiedziawszy, może być bardzo utalentowany, ale sądzę z niewielkiej ilości informacji, biorąc pod uwagę, że nie jest.

Powodzenia.

cubsink
źródło
4

Osobiście najbardziej niepokojące dla mnie jest to, że kandydat albo nigdy nie zetknął się z systemami kontroli wersji, albo zdecydował, że nie warto go używać. Uważam, że pierwszy scenariusz jest bardzo mało prawdopodobny, ale jeśli tak jest, to prowadzi mnie to do wniosku, że kandydat został znacząco odizolowany przez cały okres kariery, co podważyłoby poważne wątpliwości co do jego wartości jako części zespołu. W szczególności mogą mieć bardzo dziwne koncepcje dotyczące robienia pewnych rzeczy i nie znają żadnego z „właściwych” sposobów robienia rzeczy.

Jeśli jest to drugi przypadek, w którym aktywnie zdecydowali się przeciw kontroli wersji, to zakładam, że albo nigdy nie pracowali nad czymś znaczącym, albo są wyjątkowo aroganccy. W najlepszym razie mają naprawdę okropne sposoby utrzymywania kodu, takie jak komentowanie bloków i przypisywanie każdego wiersza kodu autorowi, dacie i numerowi błędu.

brianmearns
źródło
4

Widzę tu raczej dość osądliwe odpowiedzi, które w rzeczywistości nie biorą pod uwagę ocenianej osoby.

Osobiście uważam oprogramowanie do kontroli wersji za nieocenione narzędzie. Ale nie wszyscy mamy wybór i kontrolę nad narzędziami i procesami stosowanymi w naszym środowisku pracy. Pracuję nad rozwojem systemu Windows od 1990 roku. Jak napisali inni, w tym czasie VCS nie było wiele dostępnych w systemie Windows. Nie zamierzaliśmy wprowadzać serwerów UNIX tylko po to, aby uzyskać VCS. Czy to uczyniło mnie złym programistą? Później w swojej karierze pracowałem dla firmy z produktem komercyjnym na rynku pionowym, w którym kontrola wersji nie była procesem. Czy to uczyniło mnie złym programistą? Moje ostatnie trzy zadania polegały w dużej mierze na narzędziach VCS. Czy to czyni mnie dobrym programistą?

Byłoby wspaniale, gdybyśmy wszyscy mogli korzystać tylko z najnowszych i najlepszych narzędzi, języków i technologii. Ale zawód tworzenia oprogramowania nie zawsze działa w ten sposób. Trochę idealistycznie jest mówić „natychmiast odejdę z pracy, jeśli nie zrobią ...” lub „nigdy nie podjąłbym pracy, która nie wykorzystała ...” lub „zmusiłbym ich do skorzystania. .. ”. Nie wszyscy otaczają nas nieskończone zasoby ofert pracy, w których wszystko działa dokładnie tak, jak chcemy. Mamy rachunki do zapłaty i potrzebujemy pracy, więc radzimy sobie z tym, co nas otacza.

Ostatecznie odpowiedź na twoje pytanie jest następująca: osądź tego programistę na podstawie jego umiejętności, jego filozofii i jego decyzji, a nie (prawdopodobnie błędnych) decyzji podjętych przez osoby odpowiedzialne za jego poprzednie prace.

cdkMoose
źródło
4
Jeśli pracowałeś z idiotami tylko przez 15 lat i nie zrobiłeś z boku żadnego inteligentnego oprogramowania typu open source, prawdopodobnie wpłynie to na twoje umiejętności i nastawienie. Ludzie są kształtowani przez swoje otoczenie. Gdyby tak nie było, dlaczego mielibyśmy nawet spojrzeć na czyjąś historię zatrudnienia.
Kaz
@Kaz Patrzymy na historię zatrudnienia nie na wkład ich współpracowników, ale na własne. Nie możemy osądzać kogoś na obszarze, w którym dorastali, w przeciwnym razie moglibyśmy zacząć przesłuchiwać również sąsiadów.
James Khoury
Tak, ukształtowane przez nasze środowiska, ale nie jesteśmy zdefiniowani przez nasze środowiska. Po prostu sugeruję, aby OP w pełni spojrzał na programistę i nie dokonywał surowej oceny na podstawie jednego z kryteriów.
cdkMoose
4

Nigdy nie uważałem się za „programistę”, dopóki nie zacząłem zarabiać pieniędzy robiąc to profesjonalnie.

Zarobiłem sporo pieniędzy, tworząc systemy, dzięki którym klienci zyskali jeszcze więcej. To, czy jestem „dobrym” deweloperem, jest subiektywne.

Potrafię szybko GSD (Get Something Done), co przy tworzeniu stron internetowych zazwyczaj cieszy moich klientów. Mogą nie widzieć brzydkiego kodu za kulisami, braku komentarzy itp.

Nie korzystałem z Git i nie miałem profilu Github aż do tego roku, co według mnie jest daleko w tyle za nowoczesnymi programistami. Zacząłem też robić projekty w Railsach i Django po tym, jak w przeszłości używałem PHP, Flasha i iOS. Od tego czasu podpisałem umowy na tworzenie witryn zarówno dla klientów, jak i dla mnie, nie było zbyt bolesne nauczenie się czegoś nowego w wieku 30 lat i kilku lat po zakończeniu programowania.

Zbyt wiele we współczesnym społeczeństwie koncentruje się na nadążaniu za Jonesami i dbaniu o to, co myślą inni ludzie. Jeśli potrafisz zerwać te kajdany i zastanowić się, czego potrzebujesz do rozwoju oprogramowania (szybkość / czas wprowadzenia na rynek, zoptymalizowane zarządzanie zasobami, dobrze udokumentowany kod, skalowalność itp.), To może to mieć o wiele większe znaczenie niż to, czy ktoś zna Mercurial, SVN , Git lub inne systemy kontroli wersji.

Wolę zapytać kandydatów na programistów, czym są pasjonaci, jaki jest najfajniejszy system, jaki kiedykolwiek stworzyli według ich opinii i w czym spędzają wolny czas, rozwijając swoje umiejętności. Jeśli ludzie nie rozwijają swoich umiejętności we własnym czasie, to mnie przeraża bardziej niż inne rzeczy, ale nie znaczy, że musi cię przestraszyć.

Myślę, że masz świetne odpowiedzi na to pytanie od ludzi tutaj, a to powinno pomóc ci podjąć własną świadomą decyzję w oparciu o twoje wymagania.

ljs.dev
źródło
2

Uważam, że to niesamowite, że specjalista ds. Oprogramowania nigdy nie używał kontroli źródła i bardzo się denerwuję, że go zatrudnię.

Jakie ma doświadczenie? Zastanawiałbym się, czego jeszcze nie wie, że do tej pory się nie dowiedziałeś.

Jakie są Twoje doświadczenia związane z tworzeniem oprogramowania? Czy jesteś w stanie zapytać go o architekturę, wzorce projektowe, typowe problemy z programowaniem, pytania o wydajność systemu, pytania o bezpieczeństwo systemu itp.?

Gdyby wyszedł dobrze na tego typu rzeczach, może mógłbym przeoczyć brak wiedzy na temat kontroli źródła.

ozz
źródło
2

Czy dobry programista może nigdy nie używać kontroli wersji?

Tak. Wiele małych firm z samoukami nie używa go.

Jak można aktywnie rozwijać oprogramowanie przez 10-15 lat bez konieczności kontroli wersji?

Osobiście wprowadziłem kontrolę wersji dla 2 małych firm, uaktualniłem 1 średnią firmę z czegoś okropnego do SVN (najlepsza wówczas opcja) i pracowałem w innej małej firmie, która miała tylko trochę VC, napisałem własne rozwiązanie VC dla jakiegoś kodu i miał dużo kodu po prostu nie w żadnym VC.

Czy sam fakt, że nie szuka się rozwiązania problemu śledzenia, świadczy o złym podejściu do programowania?

Cóż, to nie jest natychmiastowa porażka, ale z pewnością zadałbym wiele dalszych pytań. Rzeczy jak:

Czy próbowałeś kiedyś oprogramowania VC? Co? Co o tym myślałeś? Czy jest jakiś powód, dla którego nie chciałbyś go użyć? Czego używałeś wcześniej do zarządzania kodem? Czy pracowałeś już wcześniej z kimś na tej samej podstawie kodu i jakich metod użyłeś, aby uniknąć kolizji?

James
źródło
1
Nic nowego w tej odpowiedzi.
pdr
1
Inteligentni programiści, którzy obecnie są samoukami, wiedzą o kontroli wersji i używają jej. Reszta ma gdzieś utknięte głowy.
Kaz.
@Kaz Nie zgadzam się. Myślę, że tak lubimy myśleć, ale spotkałem programistów, których uważam za inteligentnych, którzy tego nie zrobili, jak mówi moje osobiste doświadczenie. Nieużywanie kontroli wersji to duży znak ostrzegawczy, że gdzieś mogą utknąć w głowie [urocze zdanie :-)], ale nie zawsze tak jest.
James
2

Chciałbym się zgodzić z Pigułkami Wybuchowymi (ale mój przedstawiciel jest zbyt niski, atm ...) ... postawa jest znacznie ważniejsza.

Jest kilka rzeczy, na które uważam, że przyczyniają się do doskonałości programowania:

  1. Porozumiewanie się
  2. Kreatywność
  3. Współczucie (powiedz co?)

I często więcej niż trochę OCD.

Znasz ten typ ... tych, którzy siedzą tam, rozwalając problem, całkowicie zatracając się w kodzie, badając opcje. Są to ci, którzy robią notatki podczas pracy, zostawiają komentarze w kodzie, aby upewnić się, że rozumieją swoje własne ścieżki logiczne (i aby wytyczyć drogę dla siebie lub innych programistów, którzy mogą mieć do czynienia z kodem w przyszłości. .. w ten sposób „współczucie” na mojej powyższej liście!) oraz szybkie i jasne przekazywanie złożonych pomysłów decydentom z całego łańcucha, aby skutecznie rozwiązywać problemy.

Znakomity programista mógł utknąć od lat w środowisku, które albo nie wpadło na pomysł VCS, ale miało złe doświadczenia z VCS (a la VSS), co zmusiło ich do nieśmiałości w testowaniu nowych systemów, ale gwarantuję, że doskonały programista w takiej sytuacji nadal wprowadziłby jakąś rutynę, aby uchronić się przed utratą całej pracy z powodu kilku złych iteracji projektowych.

Programiści, których należy się wystrzegać, to ten, który twierdzi, że nigdy nie potrzebował VCS ani żadnego środka ochrony przed nieuniknionymi wpadkami. Ich podejście brzmi: „no cóż, zbudowałem to, dlatego nie może być źle”. Są to te, których obawiam się bardziej niż jakikolwiek nowicjat bezpośrednio po studiach, ponieważ nowicjusz może nauczyć się doceniać mocne strony VCS, ponieważ zdaje sobie sprawę z tego, jak mało naprawdę wiedzą.

Jason M. Batchelor
źródło
2

Jak można aktywnie rozwijać oprogramowanie przez 10-15 lat bez konieczności kontroli wersji?

Jeśli pochodzi ze szkolnych zespołów, w których małe projekty są zarządzane przez jedną osobę, jest to bardzo możliwe. Może mieć 10-letnie doświadczenie w tym samym zestawie technologii bez nauki i doskonalenia się.

Czy sam fakt, że nie szuka się rozwiązania problemu śledzenia, świadczy o złym podejściu do programowania?

Jeśli twój kandydat był w środowisku rozwoju zespołu (co najmniej 4 lub więcej programistów), to pytanie jest trywialne. Jednak może istnieć podział pracy między programistami, pracującymi na modułach wyłącznie im przypisanych, co może zmniejszyć potrzebę kontroli kodu źródłowego.

Jednak brak informacji o kontroli źródła w erze Internetu jest naprawdę zaskakującą sytuacją. Chciałbym zatem spojrzeć na jego gotowość do uczenia się nowych rzeczy (dotyczących środowiska programistycznego) oraz na jego otwartość na dynamiczne środowisko pracy.

ElYusubov
źródło
Nie każdy czyta blogi programistyczne / itp. W szczególności osoba, której kariera opiera się całkowicie na jednej platformie starszego typu, nie znajdzie od razu dużej wartości. Ilu blogów dotyczących oprogramowania mainframe / COBOL / RPG (nie dla graczy) znasz? Programowanie tych platform tak naprawdę niewiele się zmieniło w ciągu ostatnich 30 lat, a wiele z najlepszych źródeł informacji dla nich prawie na pewno ma format martwego drzewa. Jeśli programowanie jest Twoją pracą, w przeciwieństwie do tego, czym obraca się Twoje życie, podczas pracy w tych obszarach czytanie blogów technicznych / etc nie będzie miało krótkoterminowego ROI.
Dan Neely
1
Nawet w przypadku projektu jednoosobowego zyskujesz na kontroli wersji. Jeśli zostanie znaleziony błąd, możesz stwierdzić, że „został wprowadzony w wersji 3.13”, a więc dotyczy to użytkowników wersji 3.13 i późniejszych. Możesz także łatwo zrobić łatkę dla różnych wersji dla osób, które nie chcą migrować do najnowszej wersji. Jeśli potrafisz robić te rzeczy bez kontroli wersji, to robisz de facto kontrolę wersji ad hoc. Oczekujesz, że użytkownicy będą korzystać z Twojego oprogramowania w celu wyeliminowania pracochłonnej i podatnej na błędy pracy ręcznej, ale ty, programista, nie rób tego sam! LOL.
Kaz.
2

Doświadczenie ma znaczenie i masz rację, że mechaniki korzystania z narzędzi kontroli źródła można nauczyć się dość szybko. Ale masz rację, widząc czerwoną flagę.

  • Czy twój kandydat jest odizolowany od zawodu i jego trendów?
  • Czy trzeba będzie nauczyć się wielu innych aspektów pracy w zespole?

Dla mnie kwestia kontroli wersji jest raczej objawem niż chorobą. Przyczyna może się różnić i być dość łagodna. Wielu programistów ad hoc właśnie zaczęło robić to, co według nich miało sens, zaczynając od kilku książek o programowaniu, i nie przeprowadzało systematycznych badań nad tworzeniem oprogramowania. Czasami, zwłaszcza w dawnych czasach, kierunki informatyczne kończyły studia bez korzystania z systemu kontroli źródła, ponieważ wszystkie ich projekty były indywidualnymi projektami i trafiały do ​​firm z bardzo niedojrzałym procesem programowym.

Jednak dotarł tam, jeśli był samotnym wilkiem od dekady lub dłużej, może to utrudniać życie z ludźmi.

Warto zapytać, czy twój kandydat ma jeszcze kilka pytań do zbadania.

  • Opowiedz mi o czasie, kiedy pracowałeś w zespole?
  • Opowiedz mi o czasie, w którym zespół, nad którym pracowałeś, miał konflikt między członkami zespołu?
  • Opowiedz mi o czasie, w którym otrzymałeś kod od innego programisty i zrealizowałeś jego projekt?
  • Powiedz mi, jak Ty i inni członkowie zespołu trzymaliście się z daleka od siebie podczas wspólnego tworzenia kodu?
  • Powiedz mi o zgłoszonym przez klienta problemie z funkcją, która kiedyś działała, ale nie działała w późniejszej wersji? Jak to rozwiązałeś?
  • Co lubisz w pracy w zespole?

Może być również przyzwyczajony do prawie całkowitej kontroli nad swoimi metodami, procesami i bycia rolą, w której jest jedynym ekspertem od oprogramowania. Będziesz chciał kogoś, kto będzie otwarty na nowy sposób robienia rzeczy. Więcej pytań:

  • Opowiedz mi o czasie, który wykorzystałeś lub pomogłeś stworzyć standard kodowania?
  • Jakie rzeczy chcesz zobaczyć w standardzie kodowania?
  • Co sądzisz o przepisaniu kodu innej osoby?
  • Opowiedz mi o czasie, w którym uczestniczyłeś w recenzowaniu oprogramowania lub dokumentacji?
  • Czy możesz mi powiedzieć o propozycji lub umowie dotyczącej opracowania oprogramowania, w której pisaniu uczestniczyłeś?
  • Opowiedz mi o swoim ulubionym menedżerze oprogramowania lub przełożonym?
  • Opowiedz mi o swoim ulubionym współpracowniku lub podwładnym?
DeveloperDon
źródło
2

W roku 2012 dla osoby z 15-letnim doświadczeniem w branży nigdy nie używał kontroli wersji, co jest czerwoną flagą. Może nie byłaby to taka czerwona flaga, gdyby był rok 1982, a nawet 1992. Ale dzisiaj lepiej byłoby wyjaśnić tę zagadkową lukę w tle tego dewelopera.

Sytuacje nadzwyczajne wymagają nadzwyczajnych wyjaśnień.

To trochę jak mechanik samochodowy, który twierdzi, że naprawia samochody od 15 lat, ale nigdy nie miał na sobie nawet odrobiny smaru.

Oczywiście, rozmazanie się smarem nie naprawi przekładni, i żaden z kroków w instrukcji naprawy nie wymaga czegoś takiego, ale nie o to chodzi. Chodzi o to, że bycie czystym jest zgoła niespójne z tym, jak faktycznie wyglądają mechanicy samochodowi podczas pracy. W tej pracy masz na sobie tłuszcz.

Jeśli przeprowadzasz wywiad z kimś doświadczonym, który przyznaje, że nie ma doświadczenia w kontroli wersji, prawdopodobnie przesadza lub zmyśla część swojego doświadczenia (i nawet nie wie, że kontrola wersji jest czymś powszechnie używanym i ważnym, i czym też powinien kłamać! )

W wywiadach można zobaczyć różne żarty. Widziałem ludzi, którzy nie potrafią narysować schematu połączonej listy ani napisać funkcji wstawiającej węzeł na początku połączonej listy. Mimo to twierdzili, że mają 20 lat doświadczenia zawodowego.

Można oczekiwać, że nawet nowi specjaliści informatyki będą pasywnie zaznajomieni z kontrolą wersji, nawet jeśli jeszcze jej nie wykorzystali.

Kaz
źródło
Najlepsze, na co konsekwentnie można oczekiwać od nowych absolwentów, to: „Och, słyszałem o tym”. Mieliśmy tygodniowe wprowadzenie do tego, co to było, oparte na Subversion, ale nigdy nie używaliśmy kontroli wersji do niczego.
Izkata
Tak, a ponieważ są nowymi absolwentami, „kupujemy” to i idziemy dalej.
Kaz.
„przejście znajomości” (co myślę, że oznaczało odpowiedź) wynika, że już używany w pewnym momencie; Zaznaczam, że nie możesz się tego spodziewać.
Izkata,
Powiedziałbym, że jeśli absolwenci CS nie zastosowali kontroli wersji, to ich alma mater nie wdrożyło odpowiedniego, obowiązkowego kursu inżynierii oprogramowania, w ramach którego studenci nie tylko poznają koncepcje inżynierii oprogramowania, ale także pracują nad projektem zespołowym (z wersją kontrola i wszystko). Chciałbym zamienić słowo lub dwa z szefem tego działu.
Kaz.
Profesjonalnie programuję od prawie 20 lat. Wiem, co to jest lista połączona i dlaczego zostaną użyte. I nigdy nie używane jeden, i prawdopodobnie walka z niuanse pisania funkcję. Myślę, że tylko dlatego, że używasz 30-letnich technik, stwierdzenie, że wszyscy inni powinni być trochę niesprawiedliwe.
DefenestrationDay
1

Byłoby dla mnie dziwne, ale nie niemożliwe, aby doświadczony program nigdy nie używał dedykowanej kontroli źródła. W jednej firmie, z którą współpracowałem, szeroko stosowali kontrolę źródła dla swojego tradycyjnego kodu C # i VB. Ale czysty kod bazy danych (procedury składowane i skrypty, a także definicje tabel) nie były pod kontrolą źródła, pomimo posiadania dwóch profesjonalnych programistów SQL, których głównym zadaniem było pisanie, utrzymywanie i wykonywanie czystego kodu bazy danych. Wspierałem kontrolę źródła dla jednostek bazy danych i tylko częściowo mi się to udało.

W innej firmie zespół programistów był niewielki (jeden sklep przez długi czas, potem dwa). Kontrola źródła poprzedniego programisty zawierała wiele kopii plików źródłowych z datą dodaną na końcu. Oprócz braku lepszego systemu kontroli źródła, mój poprzednik był zdecydowanie kompetentny i bystry.

Zanim stałem się profesjonalistą, byłem hobbystą i nie korzystałem z żadnej kontroli źródła, niejasno wiedziałem, co to jest, ale nie zawracałem sobie głowy.

Krótko mówiąc, myślę, że to dziwne, że profesjonalista nie byłby z nim zbyt dobrze zaznajomiony, ale zwłaszcza jeśli jest przyzwyczajony do bardzo małych drużyn, z pewnością można bez niego być kompetentnym. Przy zatrudnianiu nie miałbym mu tego za złe. Absolutnie nie chciałbym się uczyć i zacząć używać go w pracy przeciwko niemu ...

TimothyAWiseman
źródło
poproś DBA, aby wygenerował skrypty SQL z bazy danych, a następnie może przekazać skrypty kontroli źródła.
linquize
@linquize Oh zgodził się. To jeden z lepszych sposobów na zrobienie tego (choć nie jedyny). Po prostu wspominam, że spotkałem wielu kompetentnych profesjonalistów i wykwalifikowanych amatorów, którzy nie mieli doświadczenia w kontroli źródła, szczególnie po stronie DBA. Przy zatrudnianiu niechętnie uczyłbym się kontroli źródła przed potencjalnym nowym zatrudnieniem, ale nie byłbym zbyt zaskoczony, że nie korzystałem z niego wcześniej, zwłaszcza jeśli byli przyzwyczajeni do małego zespołu i byli głównie po stronie bazy danych.
TimothyAWiseman
1

Moje własne 2c polega na tym, że zależy to od tego, jak zareagował na pytanie o VC. Możliwe reakcje to:

  1. Co? Co to jest
  2. Nie, zamiast tego zrobiliśmy
  3. Żadnego zawstydzonego tasowania , kierownictwo nam na to nie pozwoli
  4. Żadnego zawstydzonego tasowania , ale sam trochę zbadałem i pomyślałem, że to wygląda na coś, co powinniśmy robić.

W przypadku 4 facet dostałby ode mnie przepustkę, ma właściwe nastawienie i prawdopodobnie dobrze go odbierze. W przypadku 3 dostaje uznanie za zrozumienie, że należy to zrobić, ale nie aż tak dużo jak 4. Jeśli był w stanie wymienić kilka faktoidów na temat VC (wymienić niektóre pakiety VC tam) potraktować to jako dowód ciekawości i przekazać go.

Gdyby odpowiedział 1 lub 2, to znaczy, gdyby wiedział i nie chciał wiedzieć o VC, poważnie zakwestionowałbym osąd kandydata. Będą inne narzędzia (śledzenie błędów, wskaźniki jakości, automatyzacja kompilacji itp.), Z którymi będzie musiał pracować, i prawdopodobnie okaże się, że masz ciężką bitwę na wszystkie te problemy, jeśli nie jest otwarty na nowe podejścia.

Jak większość ludzi tutaj, myślę, że niesprawiedliwe byłoby niełagodzenie kandydata tylko dlatego, że jego pracodawca nie był zbyt szybki; dla mnie wszystko zależy od tego, jak zareagowali na to.

PhilDin
źródło
1

Pisząc o tym, co się zmieniło, dobrze jest patrzeć wstecz. Oszczędzało mi to wiele razy, gdy zastanawiałem się, co jest nie tak, a mnóstwo problemów zostało szybko naprawionych, ponieważ zapisałem to. Moim zdaniem dobrze jest prowadzić dziennik. Zwłaszcza jeśli programujesz z większą liczbą osób niż ty sam.

Jeśli piszesz aplikację internetową, możesz dodawać nowe funkcje bez kontroli wersji, ponieważ ciągle dodajesz do niej nowe rzeczy. Ale może napiszesz dziennik lub post z aktualnościami.

Chodzi o to, na czym programujesz.

Jason Stackhouse
źródło
0

Pracowałem w lokalizacjach, w których proces zatwierdzania oprogramowania trwał od 12 do 18 miesięcy. Jeśli nie było go już na liście zatwierdzonych programów, nie było sposobu, aby uzyskać je na komputerach. Napędy CD / DVD zostały zablokowane, a maszyny nie były podłączone do Internetu.

Pierwszym miejscem, w którym wpadłem na kontrolę źródła, było napisanie własnego przez programistę, zanim był gotowy do przetestowania wieloletniego projektu, który się kończył. Zaryzykowali, że pisanie go od zera było szybsze niż proces zatwierdzania.

Drugie miejsce, w którym natknąłem się na ten problem, korzystało z kontroli źródła przez pierwsze kilka miesięcy, ale potem klient chciał, aby cały rozwój został przeprowadzony w ich wewnętrznej sieci. Ponownie zamknęli wszystko, więc wróciło do wielu spakowanych folderów.

Znam programistów, którzy pracowali tylko w tych warunkach. Chcą korzystać z tych narzędzi, chcieliby korzystać z nich, ale nie mogą ich używać.

Sprawdź, dlaczego ich nie użyli. Niezrozumienie procedur z powodu braku doświadczenia jest czymś zupełnie innym niż odrzucenie narzędzi.

mhoran_psprep
źródło
Nic nowego w tej odpowiedzi.
pdr
0

Rozwijam się przez ostatnie 15 lat. Użyłem kontroli wersji tylko kilka razy. Nadal korzystam z własnych zaplanowanych skryptów i programów do stopniowego tworzenia kopii zapasowych wszystkich folderów programistycznych. Nie wiem, co powiedzieć Jeśli ktoś zapyta mnie, czy używam Kontroli wersji. Nigdy nie potrzebowałem systemu kontroli wersji, zawsze pracowałem nad małymi projektami. Mam na myśli, że nie jestem najlepszym programistą, ale jestem pewien, że nie jestem najgorszy. Przez większość czasu wstydzę się mówić ludziom, że nie używam regularnie systemu kontroli wersji, ale tak właśnie jest dla mnie.

Następnie
źródło
Mam przeciwne doświadczenie: niektórzy ludzie patrzą na mnie śmiesznie, gdy mówię, że używam kontroli wersji w małych projektach, w których jestem jedynym programistą. Być może w dzisiejszych czasach jest to mniej, ponieważ kontrola wersji służy do hostingu projektów open source i dlatego jest rozumiana jako metoda wdrażania.
Kaz.
2
Powinieneś zmienić swoje nastawienie i przyjrzeć się kontroli wersji, ponieważ pozwala ona łatwo robić wiele rzeczy. Na przykład gitsystem kontroli wersji ma zautomatyzowany przepływ pracy ( git bisect) w celu znalezienia błędu regresji. Wykonuje to binarne przeszukiwanie historii wersji projektu w celu znalezienia zestawu zmian, który wprowadził błąd. Wystarczy przebudować, uruchomić test i poinformować, gitczy był on dobry, czy zły; następnie wybiera i pobiera linię bazową do przetestowania w następnej kolejności.
Kaz
W gitmożesz wprowadzić eksperymentalne zmiany, a następnie umieścić je w stash. Twoja praca zostanie przywrócona do oryginału, a zmiany zostaną zapisane. Później możesz odkryć swoją skrytkę i ponownie zastosować te zmiany, aby nadal z nimi eksperymentować lub je wyrzucić. I oczywiście każdy przyzwoity system kontroli wersji ma rozgałęzienia, dzięki którym możesz robić takie rzeczy, jak rozwijanie, w izolacji, stabilnej wersji. Lub wróć i napraw błąd w wydaniu (aby dać łatkę klientom) i łatwo scalić tę zmianę również z bieżącą wersją programistyczną.
Kaz.
0

Mówiąc z mojego doświadczenia jako programisty w systemach IBM MVS: przez pierwsze dziesięć lat mojej kariery zawodowej system operacyjny, z którym pracowałem, miał dla programisty dokładnie jeden typ pliku do edycji: zestaw danych generacji. Zasadniczo był to plik ze stałą liczbą wersji i trzeba było pamiętać, która wersja jest odpowiednia - prawie bezużyteczna w przypadku nowoczesnej kontroli wersji. W połączeniu z systemem plików, który nie miał prawdziwych katalogów, tylko więcej lub mniej (8-znakowych) kwalifikatorów, koncepcja systemu zarządzania kodem źródłowym była całkowicie obca dla osób pracujących w tym środowisku.

Właściwie nie widziałem systemu kontroli kodu źródłowego, dopóki nie przeniosłem się do SunOS 3 i nie skorzystałem z RCS. W tym momencie byłem wyjątkowo łatwym programistą systemów IBM, bardzo produktywnym i bardzo dobrym w swojej pracy. Wszystkie wersje były obsługiwane przez kopiowanie kopii zapasowych na taśmę i nagrywanie tego, co było gdzie.

Gdybym w tym momencie nadal pracował na komputerach mainframe, jest całkiem możliwe, że nadal nie byłbym narażony na formalny system kontroli wersji; specjalnie wspierane alternatywy to ClearCase i Rational, z których żadna nie jest darmowa (w rzeczywistości obie są dość drogie).

Mówienie, że ktoś jest z definicji niekompetentny, ponieważ nigdy nie używał kontroli wersji, jest spekulacyjnym argumentem. Konieczne jest kopanie i sprawdzanie szczegółów. Jeśli twierdzą, że są programistami Linux / Unix / Mac OS, ale nigdy nie używali kontroli wersji, mówi to dla nich gorzej i być może będziesz musiał rozważyć, czy ich ogólne wrażenia są na tyle dobre, że zechcesz szkolić ich we współczesnej inżynierii oprogramowania. Jeśli są i oldschoolowym programistą komputerów mainframe - i właśnie tego potrzebujesz - skoncentruj się na tym, czy mają dokładnie potrzebne umiejętności programistyczne, których chcesz, i pogódź się z faktem, że musisz im tego nauczyć. Jak powiedzieli inni, ich reakcja na koncepcję będzie w tym przypadku decydującym czynnikiem.

Joe McMahon
źródło
0

Pięknie proszę! Cała nasza społeczność nie żyje w wysoko rozwiniętych społecznościach, w których geekiczne spotkania i hacky są zbyt obfite, nie wszyscy też pracujemy w firmach zajmujących się programowaniem oprogramowania, a niektórzy z nas nie mogą nawet znaleźć odpowiednich lub aktualnych opublikowanych zasobów w naszych językach ojczystych, drukowanych lub online, pozwól nam spotkać się z innym programistą w ciele.

Z tego, co rozumiem, jeśli jest on, jak mówisz, doświadczonym programistą, to prawdopodobnie był samotnym wilkiem pracującym jako wolny strzelec dla małych firm.

Filip Dupanović
źródło
-1

Istnieje kilka możliwych powodów, aby nie używać kontroli wersji:

  1. Praca w firmach, które nie zajmują się głównie tworzeniem oprogramowania.
  2. Lub jeśli programista zdecydował się użyć innego systemu - tylko dla doświadczonych.
  3. Lub jeśli programista nie nauczył się jeszcze, jak działa każdy system
  4. Albo problem z postawą wobec nieznanych narzędzi

Należy jednak zachować ostrożność, spotykając osoby, które zakładają:

  1. Że jest tylko jeden sposób, aby coś zrobić
  2. Lub że każdy programista musi to zrobić w ten sam sposób
  3. Lub że praktyki, których ludzie używają, są łatwe do zmiany
tp1
źródło
-2

Tak źle, jak to możliwe, aby biedny programista był ekspertem w dziedzinie kontroli wersji. Chodzi mi o to, że nie wiem, co robi kontrola wersji dla twoich umiejętności programowania lub umiejętności rozwiązywania problemów. To kwestia doświadczenia. Wiele mniejszych sklepów albo go nie używa, albo pozostawia osobnikom (którzy często pracują solo), aby sami to wymyślili.

aserwin
źródło
-2

Myślę, że nie chodzi tu o pytanie: „Jak można aktywnie rozwijać oprogramowanie przez 10-15 lat bez konieczności kontroli wersji?”, Ale „Jak można aktywnie rozwijać oprogramowanie przez ostatnie 10-15 lat potrzebujesz kontroli wersji? ”.

Pewne programowanie jest możliwe bez kontroli wersji, ale specjalista powinien być zaznajomiony z aktualnym stanem wiedzy i być w stanie wybrać odpowiednie narzędzia do wykonania zadania. Nieużywanie odpowiedniego oprogramowania do zarządzania wersjami powoduje, że praca jest ryzykowna i zawodna, a jednym z powodów, dla których chcesz zatrudnić profesjonalnego programistę, jest to, że powinien on być w stanie zarządzać ryzykiem.

Baza kodu, która jest odpowiednio opisana w VCS, jest warta znacznie więcej niż ta, która nie jest. Przyczynę każdej zmiany można śledzić i zrozumieć, dzięki czemu opiekunowie mogą lepiej zrozumieć to, co powinni wiedzieć. Niezastosowanie się do tego jest nieprofesjonalne, a jedynym usprawiedliwieniem byłoby, gdyby był / a ograniczany przez biednych menedżerów na poprzedniej pracy. Nawet wtedy, czy nie powinni używać wersji dla swoich prywatnych projektów?

Dominic Cronin
źródło