Standard per il modo in cui gli sviluppatori lavorano sulle proprie workstation

Abbiamo appena incontrato una di quelle situazioni che si presentano occasionalmente quando uno sviluppatore si ammala per qualche giorno a metà progetto.

Ci sono state alcune domande sul fatto che avesse eseguito il commit dell'ultima versione del suo codice o se ci fosse qualcosa di più recente sul suo computer locale che dovremmo esaminare e abbiamo ricevuto una consegna a un cliente in attesa, quindi non potevamo aspettare lui per tornare.

Uno degli altri sviluppatori ha effettuato l'accesso come lui per vedere e ha trovato un casino di aree di lavoro, molti apparentemente degli stessi progetti, con timestamp che hanno reso poco chiaro quale fosse "attuale" (stava prototipando alcuni bit su versioni del progetto diverse da il suo "core").

Ovviamente questo è un dolore al collo, tuttavia l'alternativa (che sembrerebbe essere standard rigorosi su come ogni sviluppatore lavora sulla propria macchina per garantire che qualsiasi altro sviluppatore possa raccogliere le cose con il minimo sforzo) è probabile che rompa molte i flussi di lavoro personale degli sviluppatori portano a inefficienza a livello individuale.

Non sto parlando di standard per il codice di check-in, o anche di standard di sviluppo generali, sto parlando di come uno sviluppatore lavora localmente, un dominio generalmente considerato (nella mia esperienza) come quasi interamente sotto il controllo degli sviluppatori.

Quindi, come gestite situazioni come questa? È una di quelle cose che accadono e che devi affrontare, il prezzo che paghi per gli sviluppatori può lavorare nel modo che meglio si adatta a loro?

O chiedi agli sviluppatori di aderire agli standard in questo settore - uso di directory specifiche, standard di denominazione, note su un wiki o altro? E se sì, quali sono i tuoi standard, quanto sono severi, come li controlli e così via?

O c'è un'altra soluzione che mi manca?

[Supponiamo per amor di discussione che lo sviluppatore non può essere contattato per parlare di ciò che stava facendo qui - anche se potesse sapere e descrivere quale area di lavoro è quale dalla memoria non sarà semplice e impeccabile e talvolta le persone possono davvero essere contattato e vorrei una soluzione che copra tutte le eventualità.]

Modifica: Capisco che passare attraverso la workstation di qualcuno sia una cattiva forma (anche se è una domanda interessante - e probabilmente fuori tema - sul perché proprio quello) e certamente non sto guardando un accesso illimitato. Pensa di più sulla falsariga di uno standard in cui le loro directory di codice sono impostate con una condivisione di sola lettura: nulla può essere modificato, nient'altro può essere visto e così via.

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

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

1. Anche se la workstation è di proprietà dell'azienda, ammettiamolo: esiste un po 'di una regola non scritta secondo cui la workstation di un programmatore è il suo castello. Sono solo a disagio con una cultura del posto di lavoro in cui chiunque può accedere regolarmente e passarci attraverso.
2. Ognuno ha il proprio flusso (come hai detto anche tu). Cercare di forzare tutti gli sviluppatori a organizzare le proprie aree di lavoro locali in un certo modo può andare contro il loro particolare modo di lavorare e interrompere il loro flusso e renderli meno efficienti.
3. Le cose che non sono nel controllo del codice sorgente sono codice mezzo cotto. Se è un codice completamente cotto 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 esaminare il codice sulle postazioni di lavoro delle persone è promuovere una cultura di check-in regolari. Una volta ho lavorato in un'azienda dove - anche se non c'era un mandato ufficiale per farlo - è stato visto una sorta di orgoglio avere sempre tutto registrato per il fine settimana. Nelle fasi di manutenzione e rilascio dei candidati, gli oggetti CR sono stati deliberatamente a grana fine per consentire piccole modifiche ben visibili e check-in regolari per tenerne traccia.

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

Versione TL; DR : la ricerca di proiettili attraverso le stazioni di lavoro delle persone è una cattiva forma. Piuttosto che cercare di promuovere una cultura per rendere più semplice passare attraverso le stazioni di lavoro delle persone per trovare ciò che vogliamo, è meglio fare pratica per promuovere una cultura dell'uso ragionevole del controllo delle fonti e dei check-in regolari. Forse anche check-in iper-regolari e attività a grana fine nelle fasi critiche dei progetti.

Piuttosto che applicare uno standard per il modo in cui gli sviluppatori organizzano le proprie workstation, applicare uno standard in cui tutto il lavoro viene archiviato alla fine di ogni giornata . I check-in potrebbero essere alle filiali se ancora incompleti.

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

Immagino che questa politica incontrerebbe un po 'di opposizione, ma nulla in confronto a quello che mi aspetterei se tu imponessi regole sull'organizzazione di quelle workstation.

Ti dirò la verità che mi sento a disagio all'idea stessa che qualcuno accederà alla mia macchina e scorrerà le mie cose. Certo, sono le attrezzature e le 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 motivo ho ritenuto necessario accedere al mio computer e riconfigurare il sistema per la nuova impostazione.

Peccato che non avessero idea di cosa stessero facendo e hanno cancellato un prototipo su cui avevo lavorato negli ultimi due mesi.

Non sarebbe successo se fosse stata messa in atto la comunicazione corretta. Questo è anche quello di cui hai bisogno. Raggiungi quello sviluppatore e scopri lo stato delle cose. Ancora meglio, chiedi alle persone un rapporto prima di andare in congedo in modo da prendere una decisione informata se ne hai bisogno o meno.

Ma non scherzare con le stazioni di lavoro delle persone.

PS Abbiamo una convenzione per una struttura di directory ma il motivo principale dell'esistenza è un mix di storia / configurazione: mettilo altrove e non verrà compilato.

Qualche mese fa stavo lavorando a un progetto piuttosto ampio e ho dovuto abbandonare il lavoro bruscamente quando ho scoperto di essere ricoverato in ospedale. Non ho avuto il tempo di controllare il mio ultimo codice per il progetto.

Fortunatamente, qui è convenzione (anche se non "necessario") archiviare il codice /var/www/ourdomain.comper imitare la produzione. Con una convenzione così logica e facile da seguire, è stato facile per un collega accedere alla mia macchina e recuperare le mie 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 area di lavoro dei programmatori potrebbe essere un'unità SATA hot-swap front-bay su cui archiviare tutti i progetti di origine e sviluppo. In questo modo, se si verifica un problema del genere, un dipendente può recuperare facilmente nuove modifiche alla fonte nel progetto senza la necessità di accedere alla workstation degli sviluppatori.

La prima parte della tua domanda identifica chiaramente i problemi di comunicazione all'interno del tuo team. Hai provato standup giornalieri ?

Concordo con te quando dici che gli standard porteranno probabilmente a inefficienza se sono troppo rigidi. Gli standard devono essere definiti dal team , coinvolgendo tutti.

Nel tuo caso, aspetterei qualche giorno dopo che lo sviluppatore interessato sarebbe tornato al lavoro. Quindi organizzare un incontro per parlare di tali standard.

Per evitare blocchi psicologici e resistenze, non nominare persone o cose specifiche che hai visto. Mantienilo generale, l'obiettivo qui è quello di ottenere input da tutti, incluso lo sviluppatore che pensi dovrebbe migliorare il suo modo di lavorare. Il ragazzo può considerare anche la tua organizzazione come un casino.

Durante l'incontro presenta il problema e chiedi chiaramente come il team potrebbe migliorare la situazione.

L'intero team decide cosa fare.

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

Al punto principale, no, non voglio che vengano applicati standard su come organizzare la mia workstation. Attualmente sto respingendo il 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 mio lavoro).

Consenti agli sviluppatori di fare tutto ciò che li rende a loro agio. 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 allenarsi, non è un buon momento per fare nuove regole.

Nel mio vecchio posto di lavoro, avevamo un sistema in cui ogni attività nel nostro bugtracking aveva il suo ramo nel controllo del codice sorgente. Resta inteso che la maggior parte delle volte, un bug / task viene schiacciato da uno sviluppatore, quindi il codice rotto può essere controllato nel controllo del codice sorgente.

Una volta che il codice era in uno stato stabile sul ramo di sviluppo, è stato effettuato un rebase trascinando il codice dal ramo con il quale si stava per integrare. Una volta che hai provato quell'unione, sarebbe semplicemente un caso di commit del codice nel ramo di integrazione - non richiederebbe l'unione come hai già fatto l'unione sul tuo ramo.

In questo modo, risparmi il problema degli sviluppatori che si preoccupano di commettere il codice che è rotto - e puoi iniziare ad applicare la politica sociale per rendere super accettabile il check-in del codice prima di uscire dall'ufficio di notte - bello e sicuro.

In questa particolare situazione chiama la persona a casa, chiarisci che non stai dubitando che sia malato, ma devi fare in modo che qualcun altro continui il suo lavoro e chiedere 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 di rado, prendi in considerazione l'uso di un sistema di controllo del codice sorgente distribuito che consenta alle persone di lavorare in filiali senza disturbarsi a vicenda.

Se il problema è che non ti piacciono gli sviluppatori che hanno più aree di lavoro sulla loro macchina, allora superalo. Lo stile di lavoro è individuale e dovresti sostanzialmente stare lontano dai loro sistemi fintanto che funzionano bene con le regole per il repository di origine. Personalmente, controllo una nuova copia molto frequentemente per diversi progetti 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. Si ricorda che gli sviluppatori sono personale altamente qualificato che raramente come microgestione e si deve delegare. Altrimenti allontanerai le persone più qualificate.

Pertanto, consiglierei di incoraggiare un modo migliore di lavorare con il repository di origine comune: dire che va bene per le persone lavorare nei rami e lasciare che si impegnino frequentemente fintanto che sincronizzano quotidianamente la loro copia locale con il repository principale (mentre farà sempre un lavoro di sviluppo in un ramo questo non influenzerà gli altri).

Quindi, come gestite situazioni come questa?

È possibile risolvere questo problema con un sistema di controllo del codice sorgente che supporta filiali instabili personali e mantenendo frequenti commit. Non è necessario un commit quando viene risolto un intero problema. Dovrebbe venire ogni volta che beneficiate del controllo del codice sorgente. La fine della giornata è uno dei tanti punti in cui dovrebbe avvenire un commit in modo da poter vedere dove sono state apportate le modifiche, eseguirne il backup e spiegarle al proprio sé futuro o ad altri.

O chiedi agli sviluppatori di aderire agli standard in questo settore - uso di directory specifiche, standard di denominazione, note su un wiki o altro?

Abbiamo un immenso documento di configurazione ambientale 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 spende sforzi per invertire la tendenza.