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

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?

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.

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.

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?

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.

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

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.

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.

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

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.

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.

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.

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.

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.

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?

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

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.

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?

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.

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

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.

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.

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.

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.

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.

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.

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

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.

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?