Come posso convincere i programmatori cowboy a utilizzare il controllo del codice sorgente?

Non è un problema di formazione, è un problema di fattori umani. Non vogliono e stanno creando blocchi stradali. Affrontare le dinamiche di gruppo rotte, qual è la causa della loro obiezione - di solito la paura, è solo la paura del cambiamento, o è più sinistra.

Nessuno sviluppatore professionista oggi o negli ultimi 20 anni ha resistito al controllo del codice sorgente. Una volta, circa 30 o 40 anni fa, quando i computer erano lenti, il controllo del codice sorgente ancora più lento e i programmi consistevano in un file di 500 righe, era un problema e c'erano validi motivi per non usarlo. Queste obiezioni possono venire solo dal peggior tipo di cowboy che riesco a pensare.

Il sistema è forzato su di loro a rendere le loro vite difficili in qualche modo? Scopri di cosa si tratta e modifica il sistema per invalidare l'obiezione. Ripeti fino al termine.

Suggerisco di consultare GIT o Mercurial. È possibile creare un repository in ogni albero del codice sorgente, che non si accorgono nemmeno e possono continuare a hacker nel modo in cui lo fanno ora. Puoi tenere traccia delle modifiche che hanno violato nella base di codice, eseguire commit, unirli in altri alberi di origine, ecc. Quando vedono che fai una settimana di sforzi in un altro prodotto in pochi secondi, potrebbero cambiare le loro idee. Quando rispondi a uno dei loro errori con un comando, e salva il loro sedere, potrebbero persino ringraziarti (non contare su di esso). Nel peggiore dei casi, hai un bell'aspetto di fronte al boss e, per un bonus, fai sembrare i cowboys che sono.

Merging would take not only a great knowledge of the project

In tal caso, temo che tu ti trovi nel proverbiale torrente senza pagaia. Se la fusione non è un'opzione, nessuno la sta implementando, quindi stai dicendo che non puoi più aggiungere funzionalità che hai già in un ramo (termine usato in modo approssimativo) a un altro.

Se fossi in te, riconsidererei le mie prospettive di carriera ...

Sometimes, real world issues make it impractical to use.

False.

If the team is not used to using source control, training problems can arise

Questo non ha nulla a che fare con il controllo del codice sorgente e tutto ciò che riguarda l'allenamento. La formazione è facile, economica, efficiente e fatta in poche ore. Il mancato utilizzo del controllo del codice sorgente è costoso, rischioso, inefficiente e i problemi persistono per sempre .

If a team member directly modifies code on the server, various issues can arise.

Questo è il problema della formazione. Ancora. Niente a che fare con il controllo del codice sorgente e tutto ciò che riguarda l'allenamento.

Developers continue to have a distrust of source control and therefore compound the issue by not using source control

Devono essere istruiti su come utilizzare il controllo del codice sorgente. Riduce i costi, riduce i rischi, semplifica le cose ed è più efficiente. È un investimento una tantum che paga dividendi ogni momento.

What can possibly be done in this type of situation?

Inizia a formare tutti su come utilizzare il controllo del codice sorgente.

Aggiorna

Developers argue that directly modifying source control saves time.

Poiché sono sbagliati, è importante raccogliere dati per dimostrare con precisione quanto questo sia sbagliato.

Purtroppo, tuttavia, la gestione sembra ricompensare una risposta immediata che è costosa a lungo termine.

L'unico modo per superare questo sistema di ricompensa è

A) Identifica che il costo a lungo termine è più alto rispetto al valore apparente a breve termine.

B) Identifica i premi effettivi effettivamente presenti che rendono la corruzione a breve termine (ad esempio, le modifiche dirette) più preziosa del corretto controllo a lungo termine del codice sorgente. Chi si prende una pacca sulla testa per fare la cosa sbagliata? Che tipo di pacca sulla testa ottengono? Chi lo dà? Per sistemare le cose, devi nominare le cose sbagliate e il / i manager / i specifico / i che è (sono) realmente incoraggiando la gente.

C) Raccomanda un sistema di ricompense rivisto che valuti il valore a lungo termine invece di una risposta rapida a breve termine. Diversi colpi sulla testa per diversi motivi.

D) Addestra gente nei premi che hai trovato per il valore a lungo termine; valore che è chiaramente maggiore della risposta rapida a breve termine.

Gli sviluppatori che si rifiutano di utilizzare il controllo di origine / versione dovrebbero essere licenziati, semplice. Come hai già sottolineato, i rischi e i costi intrinseci di NON utilizzarlo superano le spese generali sostenute da molti, molti ordini di grandezza. Chiunque stia cercando di arguire questo semplicemente non dovrebbe essere coinvolto nello sviluppo del software e io rifiuterei categoricamente di lavorare con queste persone.

Abbiamo risolto il problema prima, impostando un server di integrazione continuo per creare il nostro controllo del codice sorgente in dev. In secondo luogo, blocca l'accesso alla cartella in sola lettura, per impedire alle persone di aggirare il controllo del codice sorgente e modificare direttamente i file.

È un PITA nei giorni in cui non è possibile riprodurre il bug localmente, ma a parte questo è più bello poter lavorare, effettuare il check-in e andare avanti, sapendo che verrà spinto a devare automaticamente dal server CI.

Ho sentito il tuo dolore. Sono entrato in un paio di postazioni di lavoro per scoprire che "il controllo del codice sorgente" era una cartella condivisa su un'unità di rete. Generalmente il problema non è perché credono che l'approccio sia superiore a qualsiasi altra cosa, semplicemente funziona e non è mai stato introdotto in un flusso di lavoro che integri correttamente il controllo del codice sorgente.

Con la struttura del team di terra piatta hai spiegato che il cambiamento spinto dall'alto verso il basso potrebbe non essere il modo migliore per affrontare la situazione. Un metodo che vale la pena provare è quello di ottenere l'acquisto direttamente da uno o due degli altri sviluppatori per consentire al concetto di acquisire slancio. Una volta che avrai a bordo anche un altro dev, sarà molto più facile estenderlo al resto della squadra. Presentali lentamente al concetto, ad esempio inizia a lavorare su un piccolo progetto collaterale, prendilo e vai in Git , o persino diramai qualcosa ospitato su < a href="http://github.com/"> GitHub .

Inizia semplice, introduce i concetti lentamente e separatamente dal loro flusso di lavoro quotidiano. Gli esseri umani sono bravi a imparare cose e ad adattarsi ai cambiamenti, specialmente quando questo cambiamento fornisce loro un beneficio diretto (pensa all'evoluzione). Tuttavia, quando viene presentato con una serie di piccoli cambiamenti contemporaneamente diventa alienante. Una volta che hanno compreso come funziona il controllo del codice sorgente e i vantaggi che offre, prova a integrarlo in uno dei tuoi progetti interni (se inizi un nuovo progetto, non è il momento giusto per introdurlo). Lascia che gli altri progetti funzionino nel modo già esistente, se lo desideri, questo sarà particolarmente efficace nel mettere in evidenza i vantaggi del controllo decente del codice.

Se fallisce, corri.

Ovviamente hai le capacità tecniche per identificare e correggere la tua situazione, i tuoi problemi sono umani e relativi ai processi.

Le persone tendono a rispondere molto meglio all'esempio della visione, quindi suggerirei di "correggerlo" da soli:

Prendi una copia della fonte più recente, ri-strutturala in modo che sia controllabile dalla versione, crea un nuovo progetto con una struttura utile e orientata al futuro (scopri come gestirai i branch, dove metti le dipendenze di terze parti eccetera). Probabilmente dovrai farlo nel tuo tempo.

Quindi trascina i tuoi colleghi e la direzione in una stanza e mostra loro come appare lo sviluppo del software nel 21 ° secolo. Illustra i fallimenti con il tuo sistema attuale e mostra come vengono eliminati con la tua nuova struttura.

Dovrai anche metterti come Custode della Sorgente - dato che sembri essere l'unico a cui importi, spetta a te forzare le persone (con qualsiasi mezzo tecnico o psicologico a tua disposizione) attenersi al piano. Assicurati che la sola cosa che sta per un cliente provenga da una macchina costruita fuori dal controllo del codice sorgente. Umiliate ritualmente le persone che infrangono le regole e causano il caos. Corromperli con ciambelle ... qualunque cosa funzioni.

Se tutto ciò sembra troppo impegnativo allora (come è stato detto in quasi ogni altra risposta) - trova un altro lavoro. Non valgono il tuo tempo.

Questo è un buon esempio di un progetto in cui le cattive pratiche sono state utilizzate in modo così pervasivo da rendere praticamente impossibile risolverlo. La sua soluzione richiederebbe un congelamento, quindi tutto può essere ripulito senza interruzioni. Sfortunatamente, tali progetti di solito sono (per ovvi motivi) troppo bacati per essere congelati per diversi mesi, errori critici devono essere risolti a giorni alterni.

Potresti essere tentato di eseguire il fork del progetto per creare una versione pulita mentre la versione dirty viene trattata con quelle correzioni quotidiane; ma il risultato più probabile è che dopo diversi mesi, quando la versione "pulita" è finita, nessuno può dirti quali correzioni di bug e modifiche sono state incorporate dal fork (perché la stessa mentalità che permette alle persone di scivolare in tali pratiche rende improbabile che tengono dei registri sui cambiamenti che fanno). La versione pulita è obsoleta, la versione sporca funziona ancora, quindi cosa succede? La versione pulita viene scaricata, gli naysays hanno avuto ragione.

Passaggio 1: licenzia il manager incompetente!

Se non riesci a eseguire il passaggio 1, prova a far sì che il gestore limiti la distribuzione a prod e solo agli script presi dal controllo del codice sorgente. Se gli sviluppatori (che non dovrebbero avere diritti di produzione su prod, vedere il punto 1 se lo desiderano) vogliono che i loro contenuti vengano distribuiti devono provenire dal controllo del codice sorgente. Questo ha risolto il nostro problema di non usare il controllo del codice sorgente molto bene quando abbiamo prima utilizzato il file per il database e il codice C #.

Come può qualcuno non desiderare versioni diverse dei propri file e la capacità di vedere le differenze? Dimentica la ramificazione e qualcuna delle cose complesse. Non hanno nemmeno le basi. La modifica diretta di un file di produzione senza apportare le modifiche più rudimentali in un ambiente di test è folle. Ho lavorato con alcune persone e per fortuna non abbiamo mai lavorato agli stessi progetti.

I tuoi colleghi sono troppo stupidi per essere pigri. Questa è una perdita di tempo. Tutto quello che puoi sperare di fare è allenare il tuo manager. La gestione dovrebbe come il controllo del codice sorgente perché gradisce tutte le forme di controllo. Li fa sentire importanti. Avvitare gli altri; fissare il leader è la tua unica speranza dal momento che non sei in grado di sostituirlo. Inizia a lavorare in rete con altri sviluppatori competenti e prova a convincerli a unirti al tuo team quando hai un'opportunità o indurli ad assumerti nel loro negozio.

Oltre all'ovvio Trova un nuovo lavoro, penso che la risposta sia più completa di quanto sopra.

Per prima cosa vai in gestione per metterli a bordo con il passaggio e l'applicazione del controllo del codice sorgente. Quindi vai a ciò che deve essere fatto per far funzionare le cose, anche se questo significa lavorare direttamente sul server. Inizia la procedura per ottenere tutto nel controllo del codice sorgente.

Un'altra opzione è assicurarsi che l'ultimo sia sul server (cosa che devi fare a prescindere) e avviare un nuovo repository completamente dal più recente. Perderai la storia, ma a questo punto sono piccole patate.

Dalla tua descrizione sembra che ci siano uno o più problemi con la situazione: il team di sviluppo è fuori controllo o è stata implementata una soluzione di controllo del codice sorgente errata. In ogni caso, è compito del team di sviluppo utilizzare una soluzione di controllo del codice sorgente - la modifica diretta del codice sorgente nel servizio di produzione è solo un'ipotesi che i problemi si verifichino.

Dalla mia esperienza, il primo passo che deve avvenire immediatamente è sincronizzare il controllo del codice sorgente con il server di produzione. Questo passaggio può essere semplice come prendere una copia del codice di produzione e verificarlo - il codice prod è presumibilmente la base che sta sviluppando il tuo team. Questo passaggio potrebbe dover essere aumentato da un'unione con codice che sta fluttuando nel sistema di controllo del codice sorgente esistente. Il codice dovrebbe passare da dev a integrazione / QA (o entrambi) e quindi a uno stadio oa uno stage / produzione.

Successivamente, la gestione deve imporre l'uso del controllo del codice sorgente. Molto semplicemente, se la build non proviene dal sistema di controllo del codice sorgente, il codice non dovrebbe essere distribuito alla produzione. L'accesso alla produzione deve essere limitato al solo team di supporto, con accesso limitato a dev per la risoluzione dei problemi di produzione. Gli sviluppatori generalmente non devono mai eseguire hot deployment di codice in produzione - i problemi di produzione potrebbero sicuramente accadere, in particolare se gli sviluppatori sono sotto pressione.

La gestione ha sicuramente bisogno di gestire meglio i problemi qui - sarà quasi impossibile sostenere lo sviluppo se il codice viene applicato direttamente ai prodotti (e non nel controllo del codice sorgente).

Il vero problema non è che i codificatori dei cowboy non usano il controllo della versione. Il vero problema è che hanno già scelto un modo di fare le cose e tu stai cercando di cambiare il loro processo. Il processo scelto non include il controllo della versione. Tutte le modifiche al processo sono difficili, a meno che gli stessi programmatori notino un problema. Se c'è la sensazione che il sistema esistente sia abbastanza buono, provare a imporre un sistema diverso è semplicemente inutile. Noi siamo il borg, sarai assimilato. Certo che stanno cercando di combattere diventando borg.

Blocca tutti i server tranne il loro sviluppo. Utilizzare un Configuration Manager. Crea build regolari identificabili (rispetto ai tag). Tagga ogni set di modifiche (cioè 1 set di modifiche per bug). Mettiamo anche un tag su ogni build. Avere un sistema di tipo QA tra dev e produzione (come minimo). Costruisci sul sistema QA usando il tag build corretto. Dai loro il dolore per "rompere la costruzione".

Non mi sono mai imbattuto in una situazione in cui non potevo ricreare / risolvere un problema (che mostra solo sulla produzione). Sì, ho impiegato ore a risolvere il problema su un sistema di sviluppo (in più quando lo capisci puoi aggiungerlo al tuo test di regressione).

Abbiamo fatto un progetto con un gruppo di appaltatori di cowboy che hanno fatto tutte quelle cose brutte. Trascorro 4 settimane dopo la pulizia e poi metto in atto le pratiche di cui sopra. Da allora il progetto non ha avuto problemi con nessuna di quelle cose.

Per la tua sanità mentale, ti suggerisco di configurare Git o un altro DVCS sulla tua macchina in modo da poter tenere traccia delle modifiche. Importa spesso le modifiche dei tuoi colleghi nel tuo repository. Risolvi i conflitti nel miglior modo possibile. Questo ti proteggerà parzialmente dalla follia dei tuoi colleghi.

Hai menzionato che la direzione ha detto che gli sviluppatori dovrebbero usare il controllo del codice sorgente. Se si desidera essere malvagi, è possibile applicarlo controllando le modifiche in TFS e pubblicando periodicamente il repository, in modo da evitare eventuali modifiche non presenti in TFS. (Se stai anche mantenendo il tuo DVCS, dovresti mantenere i due sincronizzati.) La tua giustificazione è che stai seguendo gli ordini dalla direzione. Se i tuoi colleghi si stancano di aver sovrascritto le loro modifiche, invitali a utilizzare TFS. E continua a cambiare le modifiche che non sono state archiviate. Continua fino a quando i tuoi colleghi non cessano di licenziare.

Quote:

The team is not used to using TFS

TFS risulta essere Microsoft Team Foundation Server.

Il mio primo istinto dice: "questa è l'ultima versione di Microsoft Visual SourceSafe"

Sarei dalla parte dei tuoi colleghi e andare davvero contro questo.