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

Sto cercando un programmatore esperto per aiutare a risolvere una situazione difficile.

Finora le interviste sono state sorprendentemente deludenti. Il miglior candidato finora è un programmatore di grande esperienza che non ha mai usato un software di controllo versione.

Il problema in sé potrebbe non essere troppo grave perché è qualcosa che può essere appreso in breve tempo.

Ma c'è un aspetto più profondo, che mi preoccupa:

Come è possibile sviluppare attivamente software per 10-15 anni senza mai aver bisogno del controllo della versione?

Il fatto stesso di non cercare una soluzione al problema di tracciare i cambiamenti è un segno di un atteggiamento sbagliato nei confronti della programmazione?

Ho lavorato per circa 11 anni in aziende che non utilizzavano il controllo del codice sorgente. Siamo riusciti (principalmente commentando le modifiche e conservando il codice su un server centrale che potrebbe essere recuperato in qualsiasi data). Non abbiamo mai veramente chiesto se esistesse un modo migliore. Detto questo, questo era anche nei giorni in cui avevo l'intera libreria MSDN in forma di libro sulla mia scrivania.

Sì, c'era programmazione prima di Internet.

Faccio fatica a vedere come puoi passare più di 10 anni nel settore ora senza aver avuto il controllo del codice sorgente. Ma avrei avuto un po 'di simpatia, avrei creduto che fosse possibile e non avrei rifiutato il candidato da solo. 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? Esistono altre tecniche di programmazione moderne che non possiede e per le quali non sto facendo le domande giuste? Se facessi le domande giuste, un altro candidato potrebbe brillare?

Come nota finale, però, non temere di rifiutare tutti i candidati in caso di dubbi. Ricominciare da capo, ma richiede più 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 scegliere rapidamente un sistema di controllo della versione. Potrebbe parlarne in due modi:

• Buono

  Non ho mai usato il controllo delle versioni, ma sono molto entusiasta di apprendere e sembra che contribuirebbe davvero a rendere lo sviluppo più efficiente. Non ne ho avuto bisogno tanto perché ho lavorato su progetti da solo.

• Male

  Il controllo della versione è solo una parola d'ordine che sta lentamente morendo nel settore. Sono al di sopra del controllo della versione.

Lascia che ti dia una prospettiva dal fare lo sviluppo del software in DOS e Windows per oltre 20 anni.

Il software di controllo della versione nel mondo Windows / PC era spesso inaffidabile all'inizio della metà degli anni '90. Visual Sourcesafe (VSS) era il migliore basato su Windows in circolazione, ma poteva essere bizzarro e molti programmatori lo odiavano. Alcuni team semplicemente non si divertirebbero 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. Alcune di queste erano soluzioni costose e le soluzioni open source non erano accettate così prontamente come lo sono oggi.

In molti casi, alla fine degli anni '90, all'inizio degli anni 00, se un team di Windows non utilizzava VSS, non utilizzava nulla per il controllo del codice sorgente oltre alle convenzioni interne. Alcuni di loro non usano ancora un VCS nonostante la raffinatezza di Team Foundation Server (TFS) e ottime 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 usato un VCS. Ho intervistato e persino svolto lavori su contratto in alcuni luoghi che non li usavano o che erano molto casuali sul loro uso.

Quindi, non credo che la mancanza di esperienza del candidato in questo settore sia un "no" definito, ma probabilmente vorrai approfondire la sua precedente situazione lavorativa per scoprire perché questo non è presente nella sua esperienza. Ti consigliamo anche di esplorare il loro atteggiamento nei confronti del controllo delle versioni. Pensano che sia una buona idea ma non sono stati autorizzati a perseguirla nella loro posizione precedente o pensano che sia una perdita di tempo?

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

Volere fare le cose manualmente, reinventare la ruota e resistere 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 un talento, devi essere in grado di distinguere tra: impossibile, non hai e non lo farai.

Non ci sono scuse per non utilizzare il controllo versione, anche per un piccolo progetto sviluppato da un singolo sviluppatore. L'impostazione del controllo della versione locale è al di là di banale, con enormi vantaggi. Qualsiasi sviluppatore che non sa che non può essere considerato buono né esperto.

Per quanto riguarda le aziende che percepiscono il controllo di 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 versione probabilmente non ha mai collaborato con altri programmatori. Probabilmente non prenderei mai in considerazione l'assunzione di un tale programmatore, indipendentemente da qualsiasi altra credenziale.

Sembra una bandiera rossa, va bene, ma approfondisci il motivo per cui non l'ha usata. Mi aspetterei comunque che uno sviluppatore solista utilizzi il controllo delle versioni soprattutto tra dieci anni, ma me ne perdonerei di più che se stesse lavorando in una squadra e non provassi nemmeno a introdurre il controllo delle versioni.

Non sarei religioso riguardo alla mancanza di esperienza nel controllo delle versioni. È solo uno strumento. Alla fine, puoi raccogliere le basi di svn o git in un giorno o due. Il resto lo riprenderai con il tempo. E non posso credere che nessun candidato decente non sarebbe in grado di adattarsi se dovesse lavorare in un ambiente che utilizza 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 può esagerare lo sforzo richiesto e sottovalutare i benefici ottenuti. Dopotutto, ha fatto bene fino ad ora. Solo dopo aver effettivamente utilizzato il controllo del codice sorgente, lo apprezzerà.

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

Lasci 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 del software vecchi ed "esperti" il cui codice non avrei mai voluto toccare. Detto questo, potrebbe avere molto talento, ma immagino dalle poche informazioni fornite che non lo è.

In bocca al lupo.

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 il primo scenario altamente improbabile, ma se è così, allora mi porta a supporre che il candidato sia stato significativamente isolato per la durata della sua carriera, il che metterebbe seriamente in dubbio il suo valore come parte di una squadra. In particolare, possono avere concetti molto bizzarri su come fare determinate cose e non conoscere il modo "giusto" di fare le cose.

Se è il secondo caso, in cui hanno attivamente deciso contro il controllo della versione, allora mi fa supporre che o non abbiano mai lavorato su qualcosa di significativo o siano estremamente arroganti. O, nella migliore delle ipotesi, 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.

Vedo qui delle risposte piuttosto giudiziarie che in realtà non tengono conto della persona giudicata.

Personalmente trovo che il software di controllo versione sia uno strumento prezioso. Ma non tutti abbiamo scelta e controllo sugli strumenti e sui processi utilizzati nei nostri ambienti di lavoro. Lavoro nello sviluppo di Windows dal 1990. Come pubblicato da altri, a quel tempo non c'era molto disponibile per VCS in Windows. Non avremmo portato 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 sul mercato verticale in cui il controllo delle versioni era un processo non uno strumento. Mi ha fatto diventare un cattivo programmatore? I miei ultimi tre lavori si sono basati fortemente sugli strumenti VCS. Questo mi rende un buon programmatore?

Sarebbe bello se tutti potessimo usare solo gli strumenti, le lingue e le tecnologie più recenti e migliori. Ma la professione di sviluppo software non funziona sempre in questo modo. È un po 'idealistico dire "Vorrei lasciare immediatamente il lavoro, se non lo facessero ..." o "Non farei mai un lavoro che non usava ..." o "Li costringerei ad usare. .. ". Non siamo tutti circondati da una scorta infinita di opportunità di lavoro in cui tutto funziona esattamente come vogliamo. Abbiamo le bollette 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 in base alle sue capacità, alle sue filosofie e alle sue decisioni, non alle decisioni (forse errate) prese dalle persone incaricate nei suoi precedenti lavori.

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

Ho guadagnato parecchi soldi creando sistemi che hanno reso i clienti ancora più soldi. Che io sia o meno uno sviluppatore "buono" è soggettivo.

Posso fare rapidamente GSD (Get Something Done), che di solito ha soddisfatto i miei clienti per lo sviluppo web. Potrebbero non vedere qualche 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 molto "indietro rispetto ai 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 ottenuto contratti per lo sviluppo di siti sia per i clienti che per me, non è stato troppo doloroso imparare qualcosa di nuovo a 30 anni e alcuni anni fuori dalla programmazione.

Troppo nella società moderna si concentra sul tenere il passo con i Jones e prendersi cura di ciò che pensano gli altri. Se riesci a rompere quelle catene e considerare ciò di cui hai bisogno per lo sviluppo del tuo software (velocità / time-to-market, gestione delle risorse ottimizzata, codice ben documentato, scalabilità, ecc.), Ciò potrebbe avere molta più importanza che qualcuno conosca Mercurial, SVN , Git o qualsiasi altro sistema di controllo della versione.

Preferisco chiedere ai candidati degli sviluppatori di cosa sono appassionati, qual è il sistema più bello che abbiano mai fatto secondo la loro opinione e in che cosa trascorrono il loro tempo libero sviluppando le loro abilità. Se le persone non avanzano nel tempo, questo mi spaventa più di altre cose, ma non significa che debba spaventarti.

Penso che tu abbia già delle ottime risposte a questa domanda da parte delle persone qui e che dovrebbero 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 nervoso per assumerlo.

Che esperienza ha. Mi chiedo cos'altro non sa che finora non hai scoperto.

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

Se fosse uscito forte su quel tipo di cose, forse avrei potuto trascurare la mancanza di conoscenza del controllo delle fonti.

È possibile che un buon programmatore non abbia mai usato il controllo della versione?

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

Come è possibile sviluppare attivamente software per 10-15 anni senza mai aver bisogno del controllo della versione?

Ho introdotto personalmente il controllo della versione a 2 piccole aziende, ho aggiornato 1 azienda media da qualcosa di terribile a SVN (la migliore opzione al momento) e ho lavorato in un'altra piccola azienda che aveva solo qualche VC, ha scritto la propria soluzione VC per alcuni codici e aveva un sacco di codice ma non in nessun VC.

Il fatto stesso di non cercare una soluzione al problema di tracciare i cambiamenti è un segno di un atteggiamento sbagliato nei confronti della programmazione?

Beh, non è un fallimento immediato, ma certamente farei molte domande di follow-up. Cose come:

Hai mai provato un software VC? Che cosa? Cosa ne pensi? C'è qualche motivo per non usarlo? Cosa hai usato prima per gestire il codice? Hai mai lavorato con qualcuno sulla stessa base di codice e quali metodi hai usato per evitare scontri?

Vorrei 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 contribuiscano all'eccellenza della programmazione:

1. Comunicazione
2. creatività
3. Compassione (dire cosa?)

E, spesso volte, più di un piccolo disturbo ossessivo compulsivo.

Conosci il tipo ... quelli che siedono lì martellando un problema, perdendo completamente se stessi nel loro codice mentre esplorano le opzioni. Questi sono coloro che prendono appunti man mano che vanno avanti, lasciano commenti nel loro codice per assicurarsi di comprendere i propri percorsi logici (e di aprire la strada a se stessi o ad altri programmatori che potrebbero dover gestire il codice in futuro. .. così, "compassione" nella mia lista sopra!), e trasmettere rapidamente e chiaramente idee complesse ai decisori della 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 o non si è accorto dell'idea di VCS, ha avuto brutte esperienze con VCS (alla VSS) che li ha resi timidi per provare nuovi sistemi, ma garantirei che un eccellente programmatore in quella situazione avrebbe comunque impostato una sorta di routine per proteggersi dalla perdita di tutto il lavoro a causa di un paio di iterazioni di progettazione errate.

Il tipo di programmatore di cui fare attenzione, quindi, è quello che afferma di non aver mai avuto bisogno di VCS, né di alcuna misura di protezione da inevitabili truffe . Il loro atteggiamento è uno dei "beh, l'ho costruito, quindi non può essere sbagliato". Quelli sono quelli che temo più di qualsiasi noviziato appena uscito dal college, perché un novizio può imparare ad apprezzare i punti di forza del VCS perché si rendono conto di quanto poco sanno effettivamente.

Come è possibile sviluppare attivamente software per 10-15 anni senza mai aver bisogno del controllo della versione?

Se proviene da squadre della vecchia scuola in cui i piccoli progetti sono gestiti da una sola persona, è molto possibile. Può avere 10 anni di esperienza nella stessa serie tecnologica senza apprendere e migliorare se stesso.

Il fatto stesso di non cercare una soluzione al problema di tracciare i cambiamenti è un segno di un atteggiamento sbagliato nei confronti della programmazione?

Se il tuo candidato è stato in un ambiente di sviluppo di gruppo (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 potrebbe ridurre la necessità di controllare il codice alla fonte.

Tuttavia, non essere ascoltati sul controllo delle fonti nell'era di Internet è una situazione davvero sorprendente. Pertanto, osserverei la sua volontà di apprendere nuove cose (riguardanti l'ambiente di sviluppo) e quanto sia aperto a un ambiente di lavoro dinamico.

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

• Il tuo candidato è isolato dalla professione e dalle sue tendenze?
• Sarà necessario imparare anche molti altri aspetti del lavoro in gruppo?

Per me, il problema del controllo della versione è più un sintomo che la malattia. La causa può variare ed essere piuttosto benigna. Molti programmatori ad hoc hanno appena iniziato a fare ciò che pensavano avesse senso, iniziando con alcuni libri sulla programmazione, e non hanno studiato sistematicamente lo sviluppo del software. A volte, tanto più ai vecchi tempi, i maggiori in informatica si diplomavano senza mai aver usato un sistema di controllo del codice sorgente perché tutti i loro progetti erano progetti individuali e andavano in aziende con processi software estremamente immaturi.

Comunque sia arrivato lì, se è stato un lupo solitario per un decennio o più, può rendere difficile vivere con le persone.

Potrebbe valere la pena di chiedere se al tuo candidato qualche altra domanda di sondaggio.

• Mi parli di una volta in cui hai lavorato come parte di una squadra?
• Mi parli di un momento in cui una squadra su cui hai lavorato ha avuto un conflitto tra i membri della squadra?
• Mi parli di un momento in cui hai ricevuto il codice da un altro sviluppatore e portato avanti il ​​suo progetto?
• Dimmi in che modo tu e gli altri membri del vostro team vi siete tenuti lontani gli uni dagli altri durante la creazione del codice?
• Mi parli di un cliente segnalato un problema relativo a una funzionalità che funzionava, ma non funzionava in una versione successiva? come l'hai risolto?
• Cosa ti piace lavorare in gruppo?

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

• Mi parli di un periodo in cui hai usato o contribuito 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?
• Mi parli 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 che eri coinvolto nella scrittura?
• Parlami del tuo manager o supervisore software preferito?
• Mi parli del tuo collega o subordinato preferito?

Nel 2012, per qualcuno con 15 anni di esperienza nel settore che non ha mai usato il controllo della versione è una bandiera rossa. Potrebbe non essere una tale bandiera rossa se l'anno fosse il 1982, o addirittura il 1992. Ma oggi, sarebbe meglio che ci fosse una spiegazione eccellente per questo divario enigmatico nel background di quello sviluppatore.

Situazioni straordinarie richiedono spiegazioni straordinarie.

È un po 'come un meccanico che sostiene di aver riparato le auto per 15 anni, ma non ha mai avuto una macchia di grasso su se stesso.

Naturalmente, spalmarsi di grasso non risolverà una 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 è incoerentemente incompatibile con l'aspetto dei meccanici delle auto quando lavorano. In quel lavoro, ottieni grasso su te stesso.

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

È possibile vedere tutti i tipi di jolly nelle interviste. Ho visto persone che non sono in grado di disegnare un diagramma di un elenco collegato o di scrivere una funzione che inserisce un nodo all'inizio di un elenco collegato. Eppure hanno affermato 20 anni di esperienza lavorativa.

Persino i neolaureati dell'informatica possono aspettarsi di avere familiarità passiva con il controllo delle versioni, anche se non ne hanno ancora fatto largo uso.

Troverei strano, ma non impossibile per un programma esperto non aver mai usato il controllo del codice sorgente dedicato. In una società con cui ho lavorato, hanno usato ampiamente il controllo del codice sorgente per il loro codice C # e VB tradizionale. Ma il codice del database puro (stored procedure e script, nonché le definizioni di tabella) non erano nel controllo del codice sorgente nonostante avessero due sviluppatori SQL professionisti il ​​cui compito principale era scrivere, gestire ed eseguire codice di database puro. Ho sostenuto il controllo del codice sorgente per le entità del database lì e ho avuto solo parzialmente successo.

In un'altra azienda, il team di sviluppo era piccolo (un negozio per lungo tempo, poi due). Il controllo del codice 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 un uomo intelligente.

Prima di diventare professionista, ero un hobbista e non utilizzavo alcun controllo del codice sorgente, sapevo vagamente di cosa si trattasse, ma non mi preoccupavo.

In breve, penso che sia strano che un professionista non ne abbia molta familiarità, ma soprattutto se è abituato a squadre molto piccole è sicuramente possibile essere competenti senza di esso. Nell'assumere, non lo terrei contro di lui. Avrei assolutamente una riluttanza a imparare e iniziare a usarlo sul lavoro contro di lui però ...

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

1. Eh? Cos'è quello
2. No, invece, l'abbiamo fatto
3. Nessun riordino imbarazzato , la direzione non ci permetterebbe
4. Nessun rimbalzo imbarazzato , ma ho investigato un po 'me stesso e ho pensato che sembrava 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 capire che è qualcosa che dovrebbe essere fatto, ma non tanto quanto 4. Se fosse in grado di nominare un paio di factoidi su VC (elencare alcuni dei pacchetti VC là fuori) I ' lo prenderei come prova di una certa curiosità e potrebbe passarlo.

Se avesse risposto a 1 o 2, cioè se avesse saputo e non gli importasse sapere di VC, avrei seriamente messo in discussione il giudizio del candidato. Ci saranno altri strumenti (tracciamento dei bug, metriche di qualità, automazione della costruzione ecc.) Con cui dovrà lavorare e probabilmente scoprirai che hai una battaglia in salita su tutti questi problemi se non è aperto a provare nuovi approcci.

Come la maggior parte delle persone qui, penso che sarebbe ingiusto svantaggiare il candidato solo perché il suo datore di lavoro non è stato all'altezza; per me, tutto dipende da come hanno reagito ad esso.

Scrivere ciò che è cambiato è buono quando si guarda indietro. Mi ha salvato molte volte quando ho capito cosa non andava e molti problemi sono stati risolti rapidamente perché l'avevo scritto. Secondo me, è bene tenere un registro. Soprattutto se stai programmando con più persone di te stesso.

Se stai scrivendo un'app Web, puoi continuare ad aggiungere funzionalità senza controllo della versione perché aggiungi costantemente solo nuove cose. Ma forse scriverai un registro o un post di notizie con le cose nuove.

Si tratta di ciò su cui stai programmando.

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

Il primo posto in cui mi sono imbattuto nel controllo del codice sorgente è stato quello di far scrivere a uno sviluppatore, quando era pronto per testare il progetto pluriennale stava finendo. Hanno scommesso che scriverlo da zero era più veloce del processo di approvazione.

Il secondo posto in cui mi sono imbattuto in questo problema ha utilizzato il controllo del codice sorgente per i primi mesi, ma poi il cliente ha voluto che tutto lo sviluppo fosse effettuato sulla propria rete interna. Hanno nuovamente bloccato tutto, quindi era tornato a molte cartelle zippate.

Conosco sviluppatori che hanno lavorato solo in queste condizioni. Vogliono usare questi strumenti, vorrebbero usare questi strumenti, ma non sono autorizzati a usare questi strumenti.

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

Sto sviluppando da 15 anni. Ho usato il controllo 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 il controllo versione. Non ho mai avuto bisogno del sistema di controllo della versione, ho sempre lavorato su piccoli progetti. Voglio dire, non sono il miglior programmatore, ma sono sicuro di non essere il peggiore. La maggior parte delle volte sono imbarazzato nel dire alle persone che non uso regolarmente il sistema di controllo delle versioni, ma è così 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 versionabile 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 cosa - praticamente inutile per il controllo delle versioni moderne. Insieme a 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 fino a quando non sono passato a SunOS 3 e non 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 dove fosse.

Se stavo ancora lavorando su mainframe a questo punto, è del tutto possibile che non sarei mai stato esposto a un sistema formale di controllo della versione; le alternative specificamente supportate sono ClearCase e Rational, nessuna delle quali è gratuita (e in effetti sono entrambe piuttosto costose).

Quindi dire che qualcuno è per definizione incompetente perché non ha mai usato il controllo della versione è un argomento controverso. È 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, parla meno bene per loro e potresti dover valutare se la loro esperienza complessiva è così adatta che saresti disposto a addestrarli nella moderna ingegneria del software. Se sono programmatori di mainframe della vecchia scuola - ed è quello di cui hai bisogno - quindi concentrati sul fatto che abbiano esattamente le competenze 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! Tutta la nostra comunità non vive in comunità sociali altamente sviluppate in cui i luoghi di ritrovo e gli eventi hacky sono eccessivamente abbondanti, né lavoriamo tutti in 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 in carne e ossa.

Per quello che posso capire, se è uno sviluppatore di software esperto come dici tu, allora probabilmente è stato un lupo solitario che lavora come libero professionista per le piccole imprese.

Esistono alcuni motivi possibili per non utilizzare il controllo versione:

1. Lavorare in aziende che non stanno sviluppando software come attività principale.
2. O se lo sviluppatore ha deciso di utilizzare qualche altro sistema - valido solo per quelli esperti.
3. O se lo sviluppatore non ha ancora imparato come funziona ciascun sistema
4. O è un problema di atteggiamento nei confronti degli strumenti che non hanno familiarità

Ma dovresti stare attento quando incontri persone che presumono:

1. Che c'è solo un 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 usando sono facili da cambiare

Altrettanto possibile come è per un programmatore scadente essere un esperto nel controllo delle versioni. Il mio punto è che non so quale controllo della versione fa per le tue capacità di programmazione o capacità di problem solving. È una questione di esperienza. Molti negozi più piccoli non lo usano o non lo lasciano agli individui (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 mai aver bisogno del controllo della versione?", Ma "Come è possibile sviluppare attivamente software negli ultimi 10-15 anni senza mai hai bisogno del controllo della versione? ".

Sicuramente la programmazione è possibile senza il controllo della versione, ma un professionista dovrebbe avere familiarità con lo stato dell'arte attuale ed essere in grado di selezionare gli strumenti giusti per fare il lavoro. Il mancato utilizzo del software di gestione della versione appropriato rende il lavoro rischioso e inaffidabile e uno dei motivi per cui si desidera assumere uno sviluppatore professionista è che dovrebbero essere in grado di gestire il rischio.

Una base di codice correttamente annotata in un VCS vale molto più di una che non lo è. La ragione di ogni cambiamento può essere tracciata e compresa, consentendo ai manutentori di avere una comprensione più profonda di ciò che devono sapere. Non farlo è poco professionale, e l'unica scusa per questo sarebbe se fosse stato costretto da poveri manager nel suo precedente lavoro. Anche allora, non avrebbero dovuto usare il versioning per i loro progetti privati?