È possibile che un buon programmatore non abbia mai usato il controllo di versione? [chiuso]

Ho lavorato per circa 11 anni in aziende che non utilizzavano il controllo del codice sorgente. Siamo riusciti (principalmente commentando le modifiche e mantenendo il codice su un server centrale che poteva essere ripristinato in qualsiasi data). Non abbiamo mai veramente chiesto se ci fosse un modo migliore. Detto questo, è stato anche nei giorni in cui ho avuto l'intera libreria MSDN in forma di libro sulla mia scrivania.

Sì, c'era la programmazione prima di Internet.

Faccio fatica a vedere come è possibile spendere oltre 10 anni nel settore ora senza avere accesso al controllo del codice sorgente. Ma avrei una certa simpatia, credo che fosse possibile e non rifiuterei il candidato su quel solo dettaglio. Vorrei sondare e scoprire come il candidato ha gestito questo.

In alternativa, potrei chiedermi se il mio processo di intervista fosse il problema. In che modo era il miglior candidato? Ci sono altre tecniche di programmazione moderne che non ha che io non sto solo facendo le domande giuste? Se ponessi le domande giuste, un altro candidato potrebbe brillare?

Come nota finale, però, non aver paura di rifiutare tutti i candidati se hai dubbi. È necessario ricominciare da capo, ma è più dispendioso in termini di tempo assumere la persona sbagliata.

Penso che dipenda dal suo atteggiamento. Se è un programmatore molto esperto e un buon programmatore, penso che sarebbe in grado di rilevare rapidamente un sistema di controllo della versione. Potrà parlarne in due modi:

• Buona

  I've never used version control, but I'm very excited to learn, and it seems like it would really help make development more efficient. I haven't needed it as much because I've worked on projects alone.

  

• Bad

  Version control is just a buzzword that's slowly dying in industry. I'm above version control.

Permettetemi di darvi una prospettiva dal fare sviluppo software in DOS e Windows per oltre 20 anni.

Il software di controllo delle versioni nel mondo Windows / PC era spesso inaffidabile nei primi anni '90. Visual Sourcesafe (VSS) era circa il migliore basato su Windows in giro ma poteva essere bizzarro e molti programmatori lo odiavano. Alcune squadre semplicemente non potrebbero intrattenere il loro uso dopo aver affrontato questa situazione.

La maggior parte delle altre opzioni VCS al momento non erano basate su Windows e, pertanto, venivano utilizzate raramente nei team di sviluppo di Windows. Alcuni di questi erano soluzioni costose e le soluzioni open source non erano così prontamente accettate come oggi.

In molti casi, durante la fine degli anni '90, i primi anni 00, se un team di Windows non utilizzava VSS, non utilizzavano nulla per il controllo del codice sorgente a parte le convenzioni interne. Alcuni di loro non usano ancora un VCS nonostante la sofisticazione di Team Foundation Server (TFS) e grandi opzioni gratuite come git e SVN.

È possibile che qualcuno che ha lavorato per anni in un piccolo team di sviluppo di Windows per anni non abbia utilizzato un VCS. Ho intervistato e ho persino lavorato a contratto in alcuni posti che non li usavano o che erano molto casuali riguardo al loro uso.

Quindi, non penso che la mancanza di esperienza del tuo candidato in questo settore sia definita un "no", ma probabilmente vorresti approfondire la loro precedente situazione lavorativa per scoprire perché questo manca della loro esperienza. Avrai anche voglia di esplorare il loro atteggiamento verso il controllo della versione. Pensano che sia una buona idea ma non gli è stato permesso di seguirlo nella loro posizione precedente o pensano che sia una perdita di tempo?

Non puoi avere il controllo della versione senza software di controllo della versione? Chiedi come hanno gestito il loro codice. Forse esisteva già un sistema interno.

Voler fare le cose manualmente, reinventare la ruota ed essere resistenti al cambiamento non sono una novità per la programmazione. Stai per sbavare su un candidato che utilizza Visual Source Safe e "solo" VSS?

Quando cerchi di trovare il talento, devi essere in grado di distinguere tra: non può, non averlo e non lo farò.

Non ci sono scuse per non usare il controllo della versione, anche per un piccolo progetto sviluppato da un singolo sviluppatore. L'impostazione del controllo della versione locale è al di là del semplice, ha enormi vantaggi. Qualsiasi sviluppatore non sapendo che non può essere considerato buono o esperto.

Come per le aziende che percepiscono il controllo della versione come "novità", che non sono disposti a introdurre:

• SCCS è stato rilasciato nel 1972 ( 40 anni fa )
• RCS è stato rilasciato nel 1982 ( 30 anni fa ) ed è completamente open source e gratuito
• CVS è stato rilasciato nel 1990 ( 21 anni fa ), anche completamente open source e gratuito

Un programmatore che non ha mai usato il controllo della versione probabilmente non ha mai collaborato con altri programmatori. Probabilmente non prenderei mai in considerazione l'assunzione di un programmatore come questo, indipendentemente da altre credenziali.

Sembra una bandiera rossa, ma approfondisci perché non l'ha usata. Mi aspetterei comunque che uno sviluppatore solista utilizzasse il controllo della versione, in particolare in dieci anni, ma sarei più clemente di lui se non lavorando in una squadra e non abbia mai provato a introdurre il controllo della versione.

Non sarei religioso riguardo alla mancanza di esperienza nel controllo della versione. È solo uno strumento. Alla fine, puoi raccogliere le basi di svn o git in un giorno o due. Il resto ti riprenderò con il tempo. E non posso credere che nessun candidato mezzo decente non sarebbe in grado di adattarsi se dovesse lavorare in un ambiente che usa il controllo del codice sorgente.

L'uso del controllo del codice sorgente è più un'abitudine che un'abilità. Qualcuno che non l'ha mai usato potrebbe esagerare lo sforzo richiesto e sottovalutare i benefici ottenuti. Dopo tutto, ha fatto bene fino ad ora. Solo dopo aver effettivamente usato il controllo del codice sorgente, crescerà per apprezzarlo.

La domanda che dovresti porre è, come ha gestito in assenza del controllo del codice sorgente? Questo potrebbe dirti qualcosa su di lui e su come gestisce il suo lavoro.

Lasciate molte informazioni sulla sua esperienza.

Fondamentalmente, direi che è molto probabile che un programmatore possa avere 10-15 anni di esperienza senza dover conoscere il controllo della versione. La codifica per 10 anni non è uguale all'apprendimento costante di nuove tecniche di programmazione per 10 anni.

Sono molto giovane e ho visto ingegneri software vecchi e "esperti" il cui codice non vorrei mai toccare. Detto questo, potrebbe avere molto talento, ma suppongo che dalle poche informazioni fornite non lo sia.

Buona fortuna.

Personalmente, la cosa più allarmante per me è che il candidato non ha mai incontrato i sistemi di controllo della versione come concetto, o ha deciso che non vale la pena utilizzarlo. Trovo altamente improbabile il primo scenario, ma se questo è il caso, allora mi induce a pensare che il candidato sia stato significativamente isolato per tutta la durata della sua carriera, il che metterebbe seriamente in dubbio il loro valore come parte di una squadra. Nello specifico, possono avere concetti molto bizzarri su come fare certe cose e non conoscere il modo "giusto" di fare le cose.

Se è il secondo caso, dove hanno deciso attivamente contro il controllo della versione, allora mi viene da pensare che non hanno mai lavorato su qualcosa di significativo, o sono estremamente arroganti. O, nel migliore dei casi, hanno modi davvero terribili di mantenere il codice come commentare i blocchi e attribuire ogni riga di codice a un autore, una data e un numero di bug.

Qui vedo delle risposte piuttosto giudicate che in realtà non prendono in considerazione la persona che viene giudicata.

Personalmente trovo che il software di controllo delle versioni sia uno strumento inestimabile. Ma non tutti abbiamo scelta e controllo sugli strumenti e sui processi utilizzati nei nostri ambienti di lavoro. Ho lavorato nello sviluppo di Windows dal 1990. Come pubblicato da altri, in quel momento non c'era molto disponibile per VCS in Windows. Non avremmo portato i server UNIX solo per ottenere un VCS. Mi ha fatto diventare un cattivo programmatore? Più tardi nella mia carriera, ho lavorato per un'azienda con un prodotto commerciale di mercato verticale in cui il controllo della versione era un processo non uno strumento. Mi ha fatto diventare un cattivo programmatore? I miei ultimi tre lavori sono tutti basati su strumenti VCS. Questo mi rende un buon programmatore?

Sarebbe fantastico se tutti noi usassimo solo gli strumenti, i linguaggi e le tecnologie più recenti e migliori. Ma la professione dello sviluppo del software non sempre funziona in questo modo. È un po 'idealistico dire "vorrei lasciare immediatamente il lavoro, se non lo facessero ..." o "non farei mai un lavoro che non usasse ..." o "li forzerei a usare. .. ". Non siamo tutti circondati da un'infinita quantità di opportunità di lavoro in cui tutto funziona esattamente come vogliamo. Abbiamo le fatture da pagare e abbiamo bisogno di un lavoro, quindi ci occupiamo di ciò che ci circonda.

Alla fine, la risposta alla tua domanda è questa: giudica questo programmatore dalle sue capacità, dalle sue filosofie e dalle sue decisioni, non dalle (forse errate) decisioni prese dai responsabili del suo precedente lavoro.

Non mi sono mai considerato un "programmatore" fino a quando non ho iniziato a fare soldi facendolo professionalmente.

Ho guadagnato un bel po 'di soldi creando sistemi che hanno reso i clienti ancora più ricchi. Indipendentemente dal fatto che io sia un "buono" sviluppatore è soggettivo.

Posso GSD (Get Something Done) in modo rapido, che per lo sviluppo web di solito è piaciuto ai miei clienti. Potrebbero non vedere un brutto codice dietro le quinte, mancanza di commenti, ecc.

Non avevo usato Git e non avevo un profilo Github fino a quest'anno, che ritengo sia un modo "dietro i tempi" in termini di moderni standard di programmazione. Ho anche appena iniziato a fare progetti Rails e Django dopo aver fatto solo PHP, Flash e iOS in passato. Da allora ho contratto i contratti per lo sviluppo di siti sia per i clienti che per me, non è stato troppo doloroso per imparare qualcosa di nuovo a 30 anni e qualche anno fuori dalla programmazione.

Troppo nella società moderna si concentra nel tenere il passo con i Jones e nel prendersi cura di ciò che pensano gli altri. Se riesci a spezzare quelle catene e prendere in considerazione ciò che ti serve per lo sviluppo del tuo software (velocità / time to market, gestione ottimizzata delle risorse, codice ben documentato, scalabilità, ecc.), Allora potrebbe essere molto più importante che qualcuno lo conosca. Mercurial, SVN , Git o qualsiasi altro sistema di controllo della versione.

Preferisco chiedere ai candidati degli sviluppatori ciò di cui sono appassionati, quale è il sistema più bello che abbiano mai fatto nella loro opinione e su come trascorrono il loro tempo libero a sviluppare le loro competenze. Se le persone non avanzano le loro abilità nel loro proprio tempo, che mi spaventa di più delle altre cose, ma non significa che debba spaventarti.

Penso che tu abbia già ottime risposte a questa domanda da parte delle persone qui presenti e questo dovrebbe aiutarti a prendere la tua decisione informata in base alle tue esigenze.

Trovo incredibile che un professionista del software non abbia mai usato il controllo del codice sorgente e sarei molto preoccupato di assumerlo.

Quale esperienza ha? Mi chiedo che altro non sappia che finora non l'hai scoperto.

Qual è la tua esperienza di sviluppo del software da solo? Sei in grado di chiedergli informazioni su architettura, modelli di progettazione, problemi comuni di sviluppo del software, domande sulle prestazioni del sistema, domande sulla sicurezza del sistema ecc.?

Se è uscito strong su quel tipo di cose, allora forse potrei trascurare la mancanza di conoscenza del controllo del codice sorgente.

Is it possible for a good programmer to have never used version control?

Sì. Molte piccole aziende con programmatori autodidatti non la usano.

How is it possible to actively develop software for 10-15 years without ever needing version control?

Ho introdotto personalmente il controllo delle versioni in 2 piccole aziende, ho aggiornato 1 società media da qualcosa di terribile a SVN (la migliore opzione in quel momento) e ho lavorato in un'altra piccola azienda che aveva solo qualche VC, ho scritto la loro soluzione VC per un po 'di codice e aveva un sacco di codice non solo in qualsiasi VC.

Is the fact itself of not looking for a solution to the problem of tracking changes a sign of a wrong attitude to programming?

Beh, non è un fallimento immediato, ma di certo vorrei fare molte domande di follow-up. Cose come:

Hai mai provato un software VC? Che cosa? Cosa ne pensi? C'è qualche ragione per cui non lo useresti? Che cosa hai usato prima gestire il codice? Hai mai lavorato con qualcuno sullo stesso codice base e quali metodi hai usato per evitare gli scontri?

Mi piacerebbe essere d'accordo con Explosion Pills (ma il mio rappresentante è troppo basso, atm ...) ... l'atteggiamento è molto più importante.

Ci sono alcune cose da cercare, che credo costituiscano per l'eccellenza della programmazione:

1. Comunicazione
2. Creatività
3. Compassione (dì cosa?)

E, spesso, più di un piccolo OCD.

Conosci il tipo ... quelli che siedono lì a martellare un problema, perdendosi completamente nel codice mentre esplorano le opzioni. Questi sono quelli che prendono appunti mentre vanno avanti, lasciano commenti nel loro codice per assicurarsi che capiscano i propri percorsi logici (e per illuminare la strada per se stessi o per altri programmatori che potrebbero avere a che fare con il codice in futuro. .. così, "compassione" nella mia lista qui sopra!), e rapidamente e chiaramente trasmettere idee complesse ai decisori lungo la catena in modo che i problemi possano essere affrontati in modo efficiente.

Un programmatore eccellente potrebbe essere rimasto bloccato per anni in un ambiente che non comprendeva l'idea di VCS, ha avuto brutte esperienze con VCS (a la VSS) che li ha resi impotenti a provare nuovi sistemi, ma io garantirebbe che un programmatore eccellente in quella situazione avrebbe comunque creato una sorta di routine per proteggersi dal perdere tutto il lavoro a causa di un paio di iterazioni di progettazione sbagliate.

Il tipo di programmatore da cui fare attenzione, quindi, è colui che dichiara di non aver mai necessario VCS, né alcuna misura di protezione da inevitabili fallimenti. Il loro atteggiamento è uno di "bene, l'ho costruito, quindi non può essere sbagliato". Quelli sono quelli che temo più di ogni noviziato appena uscito dal college, perché un principiante può imparare ad apprezzare i punti di forza di VCS perché si rendono conto di quanto poco sappiano.

How is it possible to actively develop software for 10-15 years without ever needing version control?

Se viene da squadre di vecchia scuola dove piccoli progetti sono gestiti da una sola persona, è molto possibile. Potrebbe avere 10 anni di esperienza nello stesso set di tecnologie senza imparare e migliorare se stesso.

Is the fact itself of not looking for a solution to the problem of tracking changes a sign of a wrong attitude to programming?

Se il candidato è stato in un ambiente di sviluppo del team (almeno 4 o più programmatori), allora è una domanda banale. Tuttavia, potrebbe esserci una divisione del lavoro tra i programmatori, lavorata su moduli assegnati esclusivamente a loro, che potrebbero ridurre la necessità di controllare il codice sorgente.

Tuttavia, non essere ascoltati sul controllo della fonte nell'era di Internet è una situazione davvero sorprendente. Quindi, guarderei la sua volontà di imparare cose nuove (riguardo al tuo ambiente di sviluppo) e quanto sia aperto a un ambiente di lavoro dinamico.

L'esperienza conta e hai ragione che i meccanismi di utilizzo degli strumenti di controllo del codice sorgente possono essere appresi abbastanza velocemente. Ma hai ragione a vedere una bandiera rossa.

• Il tuo candidato è isolato dalla professione e dalle sue tendenze?
• Anche i molti altri aspetti del lavoro in una squadra devono essere appresi?

Per me, il problema del controllo della versione è più un sintomo che la malattia. La causa può variare ed essere abbastanza benigna. Un sacco di programmatori ad hoc hanno appena iniziato a fare ciò che pensavano avesse senso, iniziando con alcuni libri sulla programmazione e non facendo uno studio sistematico sullo sviluppo del software. A volte, a maggior ragione ai vecchi tempi, i laureati in informatica si sarebbero laureati senza aver mai utilizzato un sistema di controllo sorgente perché tutti i loro progetti erano progetti individuali e sono andati a società con un processo software estremamente immaturo.

Tuttavia, se è arrivato lì, se è stato un lupo solitario per un decennio o più, potrebbe rendere difficile vivere con persone.

Potrebbe valere la pena di chiedere se il tuo candidato ha qualche altra domanda di approfondimento.

• Parlami di una volta che hai lavorato come parte di un team?
• Dimmi di un periodo in cui una squadra a cui hai lavorato ha avuto un conflitto tra i membri del team?
• Parlami di un momento in cui hai ricevuto il codice da un altro sviluppatore e hai portato avanti il suo progetto?
• Dimmi in che modo tu e gli altri membri del tuo team avete tenuto lontani gli uni dagli altri quando create codice insieme?
• Parlami di un problema segnalato da un cliente relativo a una funzione che funzionava, ma che non funzionava in una versione successiva? Come l'hai risolto?
• Che cosa ti piace del lavorare in un team?

Potrebbe anche essere abituato ad avere un controllo quasi completo sui suoi metodi, sui suoi processi e sul ruolo in cui è l'unico esperto di software. Vorrà qualcuno che sarà aperto a un nuovo modo di fare le cose. Altre domande:

• Parlami di un periodo in cui hai utilizzato o aiutato a creare uno standard di codifica?
• Che tipo di cose vuoi vedere in uno standard di codifica?
• Come ti senti a riscrivere il codice di qualcun altro?
• Dimmi di una volta in cui sei stato coinvolto in revisioni tra pari di software o documentazione?
• Puoi parlarmi di una proposta o di un contratto per lo sviluppo di software in cui sei stato coinvolto nella scrittura?
• Parlami del tuo software manager o supervisore preferito?
• Parlami del tuo collega o collaboratore preferito?

Nell'anno 2012, per qualcuno con 15 anni di esperienza nel settore, non aver mai usato il controllo della versione è una bandiera rossa. Potrebbe non essere una tale bandiera rossa se l'anno fosse il 1982, o anche il 1992. Ma oggi, sarebbe meglio essere una spiegazione eccellente per questa lacuna sconcertante nel background di questo sviluppatore.

Le situazioni straordinarie richiedono spiegazioni straordinarie.

Questo è un po 'come un meccanico automobilistico che sostiene di aver aggiustato le macchine per 15 anni, ma non ha mai avuto nemmeno una goccia di grasso su se stesso.

Ovviamente, imbrattarsi di grasso non risolverà la trasmissione e nessuno dei passaggi del manuale di riparazione richiede una cosa del genere, ma non è questo il punto. Il punto è che essere perfettamente puliti è incredibilmente incoerente con ciò che i meccanici di macchina effettivamente sembrano quando stanno lavorando. In quel lavoro, ti ingrassi.

Se stai intervistando qualcuno con esperienza che ammette di non avere esperienza nel controllo della versione, probabilmente sta esagerando o fabbricando parte della sua esperienza (e non sa nemmeno che il controllo della versione è qualcosa di ampiamente usato e importante, e qualcosa che dovrebbe anche mentire su!)

È possibile vedere tutti i tipi di jolly nelle interviste. Ho visto persone che non possono disegnare un diagramma di un elenco collegato o scrivere una funzione che inserisce un nodo in testa a un elenco collegato. Eppure hanno richiesto 20 anni di esperienza lavorativa.

Anche i nuovi laureati in informatica possono avere una familiarità passiva con il controllo della versione, anche se non ne hanno ancora fatto ampio uso.

Lo troverei strano, ma non impossibile per un programma esperto non aver mai usato il controllo del codice dedicato. In una società con cui ho lavorato, hanno utilizzato estesamente il controllo del codice sorgente per i loro codici C # e VB tradizionali. Ma il puro codice di database (stored procedure e script e definizioni delle tabelle) non erano nel controllo del codice sorgente, nonostante disponessero di due sviluppatori SQL professionisti il cui compito principale era scrivere, mantenere ed eseguire codice di database puro. Ho sostenuto il controllo del codice sorgente per le entità del database e ho avuto solo parzialmente successo.

In un'altra azienda, il team di sviluppo era piccolo (un negozio per un lungo periodo, poi due). Il controllo sorgente dello sviluppatore precedente aveva più copie dei file sorgente con una data aggiunta alla fine. A parte la mancanza di un migliore sistema di controllo del codice sorgente, il mio predecessore era decisamente competente e intelligente.

Prima di diventare professionista, ero un hobbista e non usavo alcun controllo del codice sorgente, sapevo vagamente cosa fosse ma non mi dava fastidio.

In breve, penso che sia strano che un professionista non lo conosca molto bene, ma soprattutto se è abituato a gruppi molto piccoli è certamente possibile essere competente senza di esso. Nell'assunzione, non lo terrei contro di lui. Avrei assolutamente una certa riluttanza a imparare e iniziare a usarlo sul lavoro contro di lui anche se ...

Il mio 2c è che dipende da come ha reagito alla domanda su VC. Le possibili reazioni potrebbero essere:

1. Eh? Che cos'è questo
2. No, invece abbiamo
3. No shuffle imbarazzato , la gestione non ci consentirebbe
4. No shuffle imbarazzato , ma ho studiato un po 'me stesso e ho pensato che fosse qualcosa che dovremmo fare.

Nel caso di 4, il ragazzo otterrebbe un passaggio da me, ha l'atteggiamento giusto e probabilmente lo prenderà bene. Nel caso di 3, ottiene credito per la comprensione che è qualcosa che dovrebbe essere fatto ma non tanto credito quanto 4. Se fosse in grado di nominare un paio di factoid su VC (elencare alcuni dei pacchetti VC là fuori) I ' Prendilo come prova di una certa curiosità e potresti superarlo.

Se rispondesse 1 o 2, cioè, se lo sapesse e non gli interessasse sapere di VC, metterei seriamente in dubbio il giudizio del candidato. Ci saranno altri strumenti (bug tracking, metriche di qualità, build automation ecc. Ecc.) Con cui dovrà lavorare e probabilmente scoprirai di avere una dura battaglia su tutti questi problemi se non è aperto a provare nuovi approcci.

Come molte persone qui, penso che sarebbe ingiusto svantaggiare il candidato solo perché il loro datore di lavoro non era al passo; per me, tutto dipende da come hanno reagito ad esso.

Scrivere ciò che è cambiato è buono quando si guarda indietro. Mi ha risparmiato un sacco di volte quando ho capito cosa c'è che non va e molti problemi sono stati risolti velocemente perché l'ho annotato. A mio parere, è bene tenere un registro. Soprattutto se stai programmando con più persone di te stesso.

Se si sta scrivendo un'app Web, è possibile continuare ad aggiungere funzioni senza controllo della versione perché si aggiungono continuamente nuove cose. Ma forse scriverai un diario o un post di notizie con le cose nuove.

Tutto dipende da cosa stai programmando.

Ho lavorato in luoghi in cui il processo di approvazione del software era da 12 a 18 mesi. Se non era già presente nell'elenco dei software approvati, non c'era modo di scaricarlo sulle macchine. Le unità CD / DVD sono state bloccate e le macchine non erano collegate a Internet.

Il primo posto in cui mi sono imbattuto nel controllo del codice sorgente della soluzione era che uno sviluppatore scrivesse il proprio, quando era pronto per testare il progetto pluriennale stava per finire. Hanno scommesso sul fatto che scriverlo da zero fosse più veloce del processo di approvazione.

Il 2 ° posto in cui mi sono imbattuto in questo problema usava il controllo del codice sorgente per i primi mesi, ma poi il cliente voleva che tutto lo sviluppo fosse fatto sulla loro rete interna. Hanno di nuovo bloccato tutto, quindi è tornato a un sacco di cartelle compresse.

Conosco sviluppatori che hanno lavorato solo in queste condizioni. Vogliono utilizzare questi strumenti, a loro piacerebbe utilizzare questi strumenti, ma non sono autorizzati a utilizzare questi strumenti.

Indagare perché non li hanno usati. Non capire le procedure a causa dell'esperienza zero, è molto diverso dal rifiutare gli strumenti.

Sto sviluppando da 15 anni. Utilizzato il controllo della versione solo poche volte. Sto ancora usando i miei script e programmi programmati per eseguire il backup di tutte le cartelle di sviluppo in modo incrementale. Non so cosa dire Se qualcuno mi chiede Se uso Controllo versione. Non ho mai avuto bisogno di un sistema di controllo delle versioni, ho sempre lavorato su piccoli progetti. Voglio dire che non sono il miglior programmatore là fuori, ma sono sicuro di non essere il peggiore. Il più delle volte sono imbarazzato nel dire alle persone che non uso regolarmente il sistema di controllo delle versioni, ma è così che è per me.

Parlando della mia esperienza come programmatore su sistemi IBM MVS: per i primi dieci anni della mia carriera lavorativa, il sistema operativo con cui ho lavorato aveva esattamente un tipo di file versionable disponibile per il programmatore: il set di dati di generazione. Questo era essenzialmente un file con un numero fisso di versioni, e dovevi ricordare quale versione era ciò - praticamente inutile per il controllo della versione moderna. Accoppiato con un filesystem che non aveva directory reali, solo più o meno qualificatori (di 8 caratteri), il concetto di un sistema di gestione del codice sorgente era completamente estraneo a chiunque lavorasse in quell'ambiente.

In realtà non ho visto un sistema di controllo del codice sorgente finché non mi sono spostato su SunOS 3 e ho usato RCS. A quel punto ero un programmatore di sistemi IBM estremamente facile, altamente produttivo e molto bravo nel mio lavoro. Tutte le versioni sono state gestite copiando i backup su nastro e registrando ciò che era dove.

Se stavo ancora lavorando su mainframe a questo punto, è del tutto possibile che non avrei mai potuto essere esposto a un sistema di controllo di versione formale; le alternative che sono specificamente supportate sono ClearCase e Rational, nessuno dei quali è gratuito (e in effetti sono entrambi piuttosto costosi).

Quindi dire che qualcuno è per definizione incompetente perché non ha mai usato il controllo della versione è un argomento specioso. È necessario scavare e guardare i dettagli. Se affermano di essere uno sviluppatore Linux / Unix / Mac OS ma non hanno mai usato il controllo della versione, per loro non parla bene, e potresti dover valutare se la loro esperienza complessiva è così buona che saresti disposto a addestrarli nella moderna ingegneria del software. Se sono programmatori di mainframe della vecchia scuola - e questo è quello che ti serve - allora concentrati sul fatto che abbiano esattamente le abilità di programmazione necessarie che desideri e rassegnati al fatto che dovrai insegnarglielo. Come altri hanno già detto, la loro risposta al concetto sarà il fattore decisivo in quel caso.

Abbastanza per favore! La totalità della nostra comunità non vive in comunità sociali altamente sviluppate dove geeky hangouts e gli eventi hacky sono eccessivamente abbondanti, né lavoriamo tutti nelle società di sviluppo software e alcuni di noi non riescono nemmeno a trovare risorse pubblicate pertinenti o aggiornate nelle nostre lingue native, stampate o online, incontriamo mai un compagno programmatore nella carne.

Per quanto posso capire, se è uno sviluppatore di software esperto come dici tu, è probabile che sia stato un lupo solitario che lavora come freelance per le piccole imprese.

Ci sono alcuni possibili motivi per non utilizzare il controllo della versione:

1. Lavorare in aziende che non stanno sviluppando software come loro principale linea di business.
2. O se lo sviluppatore ha deciso di utilizzare un altro sistema, valido solo per quelli esperti.
3. O se lo sviluppatore non ha ancora appreso come funziona ogni sistema
4. Oppure è un problema di atteggiamento nei confronti degli strumenti che non hanno familiarità con

Ma dovresti stare attento quando incontri persone che presumono:

1. Che esiste un solo modo per fare qualcosa
2. O che ogni programmatore deve farlo nello stesso modo in cui lo fa
3. O che le pratiche che le persone stanno utilizzando sono facili da modificare

Il più possibile, così come lo è per un povero programmatore essere un esperto nel controllo della versione. Il mio punto è che non so cosa faccia il controllo di versione per le tue capacità di programmazione o di problem solving. È una questione di esperienza. Molti negozi più piccoli non lo usano o lo lasciano ai singoli (che spesso lavorano da soli) per capirlo da soli.

Penso che non sia tanto una questione di "Come è possibile sviluppare attivamente software per 10-15 anni senza aver mai bisogno del controllo della versione?", ma "Come è possibile sviluppare attivamente software per l'ultimo 10-15 anni senza mai aver bisogno del controllo della versione? ".

La programmazione sicura è possibile senza il controllo della versione, ma un professionista dovrebbe avere familiarità con lo stato attuale della tecnica e essere in grado di selezionare gli strumenti giusti per svolgere il lavoro. Il mancato utilizzo del software di gestione delle versioni appropriato rende il tuo lavoro rischioso e inaffidabile, e uno dei motivi per cui vuoi assumere uno sviluppatore professionista è che dovrebbero essere in grado di gestire il rischio.

Un codice base correttamente annotato in un VCS vale molto di più di quello che non lo è. La ragione di ogni cambiamento può essere tracciata e compresa, rendendo possibile per i manutentori ottenere una comprensione più profonda di ciò che devono sapere. Non farlo non è professionale, e l'unica scusa sarebbe se lui / lei fosse stato costretto da manager poveri al suo precedente lavoro. Anche allora, non avrebbero dovuto usare il controllo delle versioni per i loro progetti privati?