Standard su come gli sviluppatori lavorano sulle proprie workstation

" Se non è nel controllo del codice sorgente, non esiste. "

Questa è una delle poche cose nella nostra professione di cui sono al limite dogmatico. Per i seguenti motivi:

1. Anche se la workstation è una proprietà aziendale, ammettiamolo - c'è un po 'di una regola non scritta che la workstation di un programmatore è il suo castello. Sono solo a disagio con una cultura del posto di lavoro in cui chiunque può abitualmente accedere a esso e andare attraverso di esso.
2. Ognuno ha il proprio flusso (come hai detto tu stesso). Cercare di imporre a tutti gli sviluppatori di organizzare i propri spazi di lavoro locali in un certo modo potrebbe andare contro il loro particolare modo di lavorare e interrompere il loro flusso e renderli meno efficienti.
3. La roba che non è nel controllo del codice sorgente è un codice mezzo cotto. Se il codice è completamente cotto e pronto per il rilascio, dovrebbe essere nel controllo del codice sorgente. Che ritorna di nuovo al punto principale ....
4. "Se non è nel controllo del codice sorgente, non esiste."

Un modo possibile per mitigare il problema di voler guardare il codice sulle postazioni di lavoro delle persone è promuovere una cultura dei check-in regolari. Ho lavorato in un'azienda dove una volta - anche se non c'era un mandato ufficiale per farlo - è stato visto una sorta di motivo di orgoglio per avere sempre tutto controllato per il weekend. Nelle fasi di manutenzione e rilascio del candidato, gli articoli CR erano volutamente a grana molto fine per consentire modifiche minime e chiaramente visibili e controlli regolari per tenerne traccia.

Inoltre, avere tutto registrato prima di andare in vacanza era obbligatorio .

TL; Versione DR : il rifling attraverso le workstation delle persone è una cattiva forma. Piuttosto che cercare di promuovere una cultura che faciliti il passaggio attraverso le postazioni di lavoro delle persone per trovare ciò che vogliamo, è meglio praticare una cultura di uso sensibile del controllo delle fonti e controlli regolari. Forse anche i check-in iper-regolari e le attività a grana fine quando si trovano in fasi critiche dei progetti.

Invece di imporre uno standard per il modo in cui i tuoi sviluppatori organizzano le loro workstation, applica uno standard in cui viene eseguito il check in di tutto il lavoro alla fine di ogni giorno . I check-in potrebbero essere alle filiali se ancora incompleti.

In questo modo nessuno dovrebbe mai aver bisogno di accedere alla workstation di un altro sviluppatore.

Immagino che questa politica incontrerebbe qualche opposizione, ma nulla in confronto a ciò che mi aspetterei se applicassi delle regole sull'organizzazione di quelle workstation.

In verità ti dico che mi sento a disagio per l'idea che qualcuno possa accedere alla mia macchina e navigare tra le mie cose. Certo, è l'attrezzatura e la proprietà dell'azienda, ma è semplicemente una brutta cosa da fare.

L'ultima volta che sono partito per un fine settimana i ragazzi hanno riconfigurato i server con il database e il controllo del codice sorgente e per qualche ragione ho ritenuto necessario accedere alla mia macchina e riconfigurare il sistema per la nuova impostazione.

Peccato che non avevano idea di cosa stessero facendo e hanno cancellato un prototipo su cui stavo lavorando da due mesi.

Non sarebbe successo se fosse stata stabilita la corretta comunicazione. Questo è quello che ti serve pure. Raggiungi lo sviluppatore e scopri lo stato delle cose. Ancora meglio, chiedi alle persone di fare un rapporto prima di andare in ferie, in modo da prendere una decisione informata se hai bisogno di qualcosa o no.

Ma non scherzare con le workstation delle persone.

P.S. Abbiamo una convenzione per una struttura di directory, ma la ragione principale dell'esistenza è un mix di cronologia / configurazione - mettilo da un'altra parte e non verrà compilato.

Alcuni mesi fa stavo lavorando a un progetto piuttosto ampio e ho dovuto lasciare il lavoro all'improvviso quando ho scoperto che ero ricoverato in ospedale. Non ho avuto il tempo di controllare il mio ultimo codice per il progetto.

Fortunatamente, qui è convenzione (anche se non "necessaria") memorizzare codice in /var/www/ourdomain.com per simulare la produzione. Con una convenzione così logica e facile da seguire, è stato facile per un collega accedere alla mia macchina e recuperare le ultime modifiche.

Penso che alcune convenzioni siano buone. Anche se sono d'accordo con Bobby quando dice

"Se non è nel controllo del codice sorgente, non esiste."

Inoltre, un'utile aggiunta a qualsiasi spazio di lavoro dei programmatori potrebbe essere un'unità SATA hot-swap frontale su cui archiviare tutti i progetti di origine e di sviluppo. In questo modo, se si presenta un problema di questo tipo, un dipendente può recuperare facilmente nuove modifiche di origine al progetto senza la necessità di accedere alla workstation degli sviluppatori.

La prima parte della tua domanda identifica chiaramente i problemi di comunicazione all'interno della tua squadra. Hai provato stand up giornalieri ?

Sono d'accordo con te quando dici che gli standard porteranno probabilmente all'inefficienza se sono troppo rigidi. Gli standard devono essere definiti dal team , che coinvolge tutti.

Nel tuo caso, aspetterei alcuni giorni dopo il ritorno dello sviluppatore interessato al lavoro. Quindi organizza un incontro per parlare di questi standard.

Per evitare blocchi psicologici e resistenza, non nominare persone o cose specifiche che hai visto. Tenerlo generale, l'obiettivo qui è quello di ottenere input da tutti, compreso lo sviluppatore che si ritiene debba migliorare il proprio modo di lavorare. Il ragazzo potrebbe considerare anche la tua organizzazione come un disastro.

Durante la riunione presenta il problema e chiedi chiaramente in che modo il team potrebbe migliorare la situazione.

The (whole) team decide what to do.

Quell'utente probabilmente soffriva della mancanza di strumenti adeguati. In particolare, l'uso di un sistema di controllo della versione distribuita avrebbe eliminato per lui la necessità di avere diverse directory di codice in diversi stati. Avrebbe potuto tenerlo tutto in rami e sarebbe stato molto più felice.

Al punto principale, però, no, non voglio che gli standard vengano applicati a me su come organizzo la mia workstation. Attualmente sto facendo pressione sul mio dipartimento standardizzando un IDE (il mio capo VERAMENTE ci vuole tutti in Eclipse perché è quello che usa e conosce bene, anche se IMO non è lo strumento migliore per il lavoro mio ) .

Lascia che gli sviluppatori facciano tutto ciò che li rende comodi. Uno sviluppatore comodo è più produttivo di uno scomodo. E se qualcuno NON è produttivo e sospetti che stiano armeggiando a livello locale con gli strumenti, è un'opportunità per l'allenamento, non un buon momento per creare nuove regole.

Nel mio vecchio posto di lavoro, avevamo un sistema in cui ogni attività nella nostra tracciatura dei bug aveva il proprio ramo nel controllo del codice sorgente. Si è capito che la maggior parte delle volte, un bug / task è stato schiacciato da uno sviluppatore in modo che il codice non funzionante potesse essere controllato nel controllo del codice sorgente.

Una volta che il codice era in uno stato che era stabile sul ramo di sviluppo, era stato eseguito un rebase che trascinava il codice dal ramo con il quale avevi intenzione di integrarlo. Una volta che hai verificato l'unione, sarebbe semplicemente il caso di commettere il codice nel ramo dell'integrazione - non richiederebbe l'unione come hai già fatto nell'unione sul ramo.

In questo modo, risparmi il problema degli sviluppatori che si preoccupano di commettere un codice non funzionante e puoi iniziare ad applicare la politica sociale per renderlo super-accettabile per controllare il codice prima di lasciare l'ufficio di notte, bello e sicuro.

Nella questa situazione particolare chiama la persona a casa, rendi molto chiaro che non stai dubitando di essere malato, ma devi avere qualcun altro che continui il suo lavoro e chiedi dove sono le ultime cose è e in quale stato.

Quindi devi considerare cosa fare da qui. Se il problema è che le persone effettuano il check-in troppo raramente, considera l'utilizzo di un sistema di controllo del codice sorgente distribuito che consenta alle persone di lavorare nei rami senza disturbarsi a vicenda.

Se il problema è che non ti piacciono gli sviluppatori che hanno più spazi di lavoro sul loro computer, allora passaci sopra. Lo stile di lavoro è individuale e in pratica si deve stare lontani dai loro sistemi purché funzionino correttamente con le regole del repository di origine. Personalmente guardo una nuova copia molto spesso per progetti diversi e pulisco solo una volta ogni tanto.

Se il problema è che non sai cosa sta facendo il tuo sviluppatore, il problema è politico, non tecnico, e devi cambiare il tuo stile di gestione. Per favore ricorda che gli sviluppatori sono persone altamente qualificate che raramente amano il microgestione e che tu devi delegare . Altrimenti spingerai via le persone più abili.

Quindi, consiglierei di incoraggiare un modo migliore per lavorare con il repository di fonti comuni - diciamo che va bene che le persone lavorino nelle filiali e che si impegnino di frequente fintanto che si sincronizzano quotidianamente la loro copia locale con il repository principale (come faranno sempre i lavori di sviluppo in un ramo questo non influenzerà gli altri).

So how do you handle situations like this?

È possibile risolvere questo problema con un sistema di controllo del codice sorgente che supporta i rami instabili personali e il mantenimento di commit frequenti. Un commit non deve venire quando viene risolto un intero problema. Dovrebbe venire ogni volta che si beneficia del controllo del codice sorgente. La fine della giornata è uno dei tanti punti in cui dovrebbe accadere un commit in modo che tu possa vedere dove sono state apportate le modifiche, eseguirne il backup e spiegarle al tuo sé futuro o ad altri.

Or do you ask developers to adhere to standards in this area - use of specific directories, naming standards, notes on a wiki or whatever?

Abbiamo un immenso documento di configurazione dell'ambiente che denota convenzioni, ma non uno standard. Gli standard sono per codice di produzione e ambienti. Tuttavia molti dei nostri strumenti di sviluppo sono configurati per supportare le convenzioni e la maggior parte degli sviluppatori non impiega sforzi in controtendenza.