Cosa fai con uno sviluppatore che non verifica il suo codice? [chiuso]

https://stackoverflow.com/questions/139228

02-07-2019
|

Domanda

Uno dei nostri sviluppatori scrive continuamente codice e lo mette nel controllo della versione senza testarlo. La qualità del nostro codice sta soffrendo di conseguenza.

Oltre a sbarazzarsi dello sviluppatore, come posso risolvere questo problema?

Modifica

Ne ho parlato diverse volte e gli ho persino dato un avvertimento scritto

Soluzione

Se esegui sistematicamente revisioni del codice prima di consentire a uno sviluppatore di eseguire il commit del codice, il problema è per lo più risolto. Ma questo non sembra essere il tuo caso, quindi è quello che raccomando:

Parla con lo sviluppatore. Discuti le conseguenze per gli altri nel team. La maggior parte degli sviluppatori vuole essere riconosciuta dal loro pari, quindi questo potrebbe essere sufficiente. Sottolinea inoltre che è molto più semplice correggere i bug nel codice che hai in mente rispetto al codice vecchio di settimane. Questa parte ha senso se hai una qualche forma di possedere codice .
Se questo non funziona dopo un po 'di tempo, prova a mettere in atto una politica che renderà spiacevole il commit del codice buggy per l'autore. Un modo popolare è rendere la persona che ha rotto la build responsabile delle faccende della creazione di quella successiva. Se il tuo processo di generazione è completamente automatizzato, cerca invece un'altra attività umile da gestire. Questo approccio ha l'ulteriore vantaggio di non individuare nessuno in particolare, rendendolo più accettabile per tutti.
Utilizza misure disciplinari . A seconda delle dimensioni del tuo team e della tua azienda, questi possono assumere molte forme.
licenzia lo sviluppatore. C'è un costo associato alla conservazione delle mele cattive. Quando arrivi così lontano, lo sviluppatore non si preoccupa dei suoi colleghi sviluppatori e hai già un problema di persone nelle tue mani. Se l'ambiente di lavoro diventa avvelenato, potresti perdere molto di più - dal punto di vista della produttività e delle persone - rispetto a questo singolo cattivo sviluppatore.

Altri suggerimenti

Se riesci a fare recensioni di codice, è un posto perfetto per catturarlo.

Sono necessarie revisioni prima della fusione con il trunk di iterazione, quindi in genere tutto viene intercettato in quel momento.

Pestaggi rituali! Per ogni insetto, una sferza di frusta!

(Uno scherzo per chiunque non lo capisca)

Come sviluppatore che verifica raramente il proprio codice, posso dirti l'unica cosa che mi ha fatto spostare lentamente il mio comportamento ...

Visibilità

Se l'ambiente consente di estromettere il codice, in attesa che gli utenti trovino problemi, e in sostanza chiedendo " Che ne dici ora? " dopo aver apportato una modifica al codice, non vi è alcun reale incentivo a testare le tue cose.

Le revisioni del codice e la collaborazione ti incoraggiano a lavorare per creare un prodotto di qualità molto più che se stavi semplicemente offrendo "Widget X" mentre i tuoi colleghi lavorano su "Widget Y" e "Widget Z"

Più il tuo lavoro è visibile, più è probabile che ti interessi a come funziona.

Revisione del codice. Metti tutti i tuoi sviluppatori in una stanza ogni lunedì mattina e chiedi loro di portare il loro più orgoglioso risultato basato sul codice della settimana precedente insieme a loro alla riunione.

Lascia che prendano i riflettori e si emozionino per spiegare cosa hanno fatto. Chiedi loro di portare copie del codice in modo che altri sviluppatori possano vedere di cosa stanno parlando.

Abbiamo iniziato questo processo qualche mese fa ed è sorprendente vedere la quantità di controlli di qualità subcoscienti che hanno luogo. Dopotutto, se agli sviluppatori viene semplicemente chiesto di parlare di ciò di cui sono più entusiasti, saranno totalmente entusiasti di mostrare alle persone il loro codice. Quindi, altri sviluppatori vedranno gli errori di qualità e discuteranno pubblicamente del motivo per cui sono sbagliati e come il codice dovrebbe davvero essere scritto.

Se questo non induce il tuo sviluppatore a scrivere un codice di qualità, probabilmente non è adatto alla tua squadra.

Rendilo parte dei suoi obiettivi di revisione annuale. Se non lo raggiunge, nessun aumento di stipendio.

A volte anche se devi solo accettare che qualcuno non è giusto per la tua squadra / ambiente, dovrebbe essere l'ultima risorsa e può essere difficile da gestire, ma se hai esaurito tutte le altre opzioni, potrebbe essere la cosa migliore in a lungo termine.

Comunica allo sviluppatore che vorresti vedere un cambiamento nelle loro pratiche entro 2 settimane o inizierai la procedura disciplinare della tua azienda. Offri tutto l'aiuto e l'assistenza che puoi, ma se non puoi cambiare questa persona, non è adatto alla tua azienda.

Usando il controllo della velocità di crociera o uno strumento simile, puoi effettuare il check-in automaticamente attivando una build e test unitari. Dovresti comunque assicurarti che ci siano test unitari per qualsiasi nuova funzionalità che aggiunge, cosa che puoi fare guardando i suoi check-in. Tuttavia, questo è un problema umano, quindi una soluzione tecnica può andare solo così lontano.

Perché non parlare con lui? Probabilmente non ti morderà davvero.

Fallo "fare da babysitter" la build e diventa il gestore della build. Questo gli darà meno tempo per sviluppare il codice (aumentando così le prestazioni di tutti) e insegnargli perché una buona build è così necessaria.
Applica casi di test - il codice non può essere inviato senza casi di test unitari. Modifica il sistema di compilazione in modo tale che se i casi di test non vengono compilati ed eseguiti correttamente o non esistono, l'intero check-in dell'attività viene negato.

-Adam

Pubblica le statistiche sulla copertura del codice di prova per sviluppatore, questo dopo aver parlato con lui.

Ecco alcune idee da una baracca di mare.

Intro
   What shall we do with a drunken sailor, (3×)
   Early in the morning?
Chorus
   Wey–hey and up she rises, (3×)
   Early in the morning!
Verses
   Stick him in a bag and beat him senseless, (3×)
   Early in the morning!
   Put him in the longboat till he’s sober, (3×)
   Early in the morning!

ecc. Sostituisci "marinaio ubriaco" con uno "sviluppatore sciatto".

A seconda del tipo di sistema di controllo versione che si sta utilizzando, è possibile impostare criteri di check-in che impongano al codice di soddisfare determinati requisiti prima di essere autorizzato a effettuare il check-in. Se si utilizza un sistema come Team Foundation Server, è possibile specificare i requisiti di copertura del codice e test delle unità per i check-in.

Sai, questa è un'opportunità perfetta per evitare di individuarlo (anche se sono d'accordo che devi parlare con lui) e implementare internamente un processo Test-first. Se le regole non sono chiare e le aspettative sono note a tutti, ho scoperto che ciò che descrivi non è poi così insolito. Trovo che fare lo schema di sviluppo test-first funzioni bene per me e migliora la qualità del codice.

Possono essere eccessivamente focalizzati sulla velocità piuttosto che sulla qualità.

Questo può indurre alcune persone a correre attraverso i problemi per cancellare il loro elenco e vedere cosa ritorna nelle segnalazioni di bug in seguito.

Per correggere questo equilibrio:

assegna solo un paio di elementi alla volta nel tuo sistema di tracciamento dei problemi,
rivedi il codice e testa tutto ciò che ha "completato" il più presto possibile, quindi tornerà immediatamente con loro in caso di problemi
parla con loro delle tue aspettative su quanto tempo impiegherà un articolo a funzionare correttamente

La programmazione tra pari è un'altra possibilità. Se è con un altro sviluppatore esperto nel team che muore soddisfa gli standard di qualità e conosce la procedura, questo ha alcuni vantaggi:

Con uno sviluppatore esperto alle sue spalle imparerà cosa ci si aspetta da lui e vedrà la differenza tra il suo codice e il codice che soddisfa le aspettative
L'altro sviluppatore può applicare una prima politica di test: non consentire la scrittura del codice fino a quando i test non sono stati scritti per esso
Allo stesso modo, l'altro sviluppatore può verificare che il codice sia conforme allo standard prima che venga effettuato il check-in, riducendo così la quantità di check-in non validi

Tutto ciò ovviamente richiede che la società e gli sviluppatori siano ricettivi a questo processo che potrebbero non essere.

Sembra che le persone abbiano escogitato molte risposte fantasiose e subdole a questo problema. Ma il fatto è che questo non è un gioco. Elaborare elaborati sistemi di pressione tra pari in "nome e vergogna" lui non sta per arrivare alla radice del problema, vale a dire. perché non sta scrivendo test?

Penso che dovresti essere diretto. So che dici di avergli parlato, ma hai provato a scoprire perché non sta scrivendo test? Chiaramente a questo punto sa che dovrebbe essere, quindi sicuramente ci deve essere qualche ragione per cui non sta facendo quello che gli è stato detto di fare. È pigrizia? Indugio? I programmatori sono famosi per il loro ego e le loro opinioni forti - forse è convinto per qualche motivo che il test è una perdita di tempo o che il suo codice è sempre perfetto e non necessita di test. Se è un programmatore immaturo, potrebbe non comprendere appieno le implicazioni delle sue azioni. Se è "troppo maturo" potrebbe essere troppo impostato nei suoi modi. Qualunque sia il motivo, affrontalo.

Se si tratta di una questione di opinione, è necessario fargli capire che deve mettere da parte la propria opinione personale e seguire semplicemente le regole. Metti in chiaro che se non riesce a fidarsi di seguire le regole, verrà sostituito. Se continua a non farlo, fai proprio questo.

Un'ultima cosa: documenta tutte le discussioni insieme agli eventuali problemi che si verificano a seguito delle sue modifiche. Se si tratta del peggio, potresti essere costretto a giustificare le tue decisioni, nel qual caso avere prove documentali sarà sicuramente prezioso.

Attaccalo sul suo ramo di sviluppo e porta le sue cose nel bagagliaio solo quando sai che è stato accuratamente testato. Questo potrebbe essere un luogo in cui uno strumento di gestione del controllo del codice sorgente distribuito come GIT o Mercurial eccellerebbe. Sebbene con il supporto di ramificazione / fusione aumentato in SVN, potresti non avere troppi problemi a gestirlo.

Modifica

Questo è solo se non riesci a liberarti di lui o a farlo cambiare. Se semplicemente non riesci a fermare questo comportamento (cambiando o sparando), il meglio che puoi fare è bufferizzare il resto della squadra dai cattivi effetti della sua codifica.

Se ci si trova in un luogo in cui è possibile influire sulle politiche, apportare alcune modifiche. Esegui revisioni del codice prima di effettuare il check-in e fai in modo che i test facciano parte del ciclo di sviluppo.

Sembra abbastanza semplice. Rendilo un requisito e se non può farlo, sostituiscilo. Perché dovresti tenerlo?

Di solito non lo sostengo a meno che tutto il resto fallisca ...

A volte, un grafico visualizzato pubblicamente del conteggio dei bug per sviluppatore può applicare una pressione dei pari sufficiente per ottenere risultati favorevoli.

Prova la carota, rendila un gioco divertente.
Ad esempio il plug-in del gioco di integrazione continua per Hudson
http://wiki.hudson-ci.org/ display / HUDSON / Il + continuo + Integrazione + Game + plug

Metti i tuoi sviluppatori su rami del tuo codice, in base a una logica come, per funzione, per correzione di bug, per team di sviluppo, qualunque cosa. Quindi i check-in non validi vengono isolati in tali rami. Quando arriva il momento di fare una build, unire a un ramo di test, trovare problemi, risolvere e quindi unire nuovamente la versione in un ramo principale.

Oppure rimuovi i diritti di commit per quello sviluppatore e invia loro il loro codice a uno sviluppatore più giovane per la revisione e il test prima che possa essere eseguito il commit. Ciò potrebbe motivare un cambiamento nella procedura.

Potresti mettere insieme un rapporto con errori trovati nel codice con il nome del programmatore che era responsabile di quel software.

Se è una persona ragionevole, discuti il ??rapporto con lui.

Se si prende cura della sua "reputazione" pubblica il rapporto regolarmente e lo mette a disposizione di tutti i suoi colleghi.

Se ascolta solo l '"autorità", fai il rapporto e inoltra il problema al suo manager.

In ogni caso, ho visto spesso che quando le persone sono consapevoli di quanto possano sembrare cattive dall'esterno, cambiano il loro comportamento.

Ehi, questo mi ricorda qualcosa che ho letto su xkcd :)

Ti riferisci alla scrittura di test di unità automatizzati o test di unità manualmente prima del check-in?

Se il tuo negozio non scrive test automatici, il suo check-in del codice che non funziona è sconsiderato. Sta influenzando la squadra? Hai un dipartimento di controllo qualità formalizzato?

Se state creando tutti i test di unità automatizzati, suggerirei che parte del processo di revisione del codice includa anche i test di unità. Sarà ovvio che il codice non è accettabile per i tuoi standard durante la tua revisione.

La tua domanda è piuttosto ampia, ma spero di aver fornito una direzione.

Concordo con Phil sul fatto che il primo passo è parlare individualmente con lui e spiegare l'importanza della qualità. La scarsa qualità può spesso essere collegata alla cultura del team, del dipartimento e dell'azienda.

Rendi i casi di test eseguiti uno dei risultati prima che qualcosa venga considerato "fatto."

Se non hai eseguito casi di test, allora il lavoro non è completo e se la scadenza passa prima che tu abbia l'esecuzione documentata del caso di test, allora non ha consegnato in tempo e le conseguenze sarebbero le stesse di se non avesse completato lo sviluppo.

Se la cultura della tua azienda non lo consentirebbe, e valorizza la velocità sull'accuratezza, allora questa è probabilmente la radice del problema e lo sviluppatore sta semplicemente rispondendo agli incentivi esistenti - viene premiato per averlo fatto molte cose a metà piuttosto che meno correttamente.

Rendi la persona pulita latrine. Ha lavorato nell'esercito. E se lavori in gruppo con persone che mangiano molto cibo indiano, non ci vorrà molto perché si allineino.

Ma sono solo io ...

Ogni volta che uno sviluppatore controlla qualcosa che non viene compilato, metti dei soldi in un barattolo. Ci penserai due volte prima di fare il check-in.

Sfortunatamente se gli hai già parlato molte volte e gli hai dato avvisi scritti direi che è giunto il momento di eliminarlo dalla squadra.

Puoi trovare alcune risposte utili qui: Come far scrivere test ai programmatori junior ?

Autorizzato sotto: CC-BY-SA insieme a attribuzione

Non affiliato a StackOverflow