Come disarmate un codificatore di cowboy? [chiuso]

36

Ho trovato una domanda (codice cowboy del team), ma era più correlato a "Ninja Coder", quindi il problema che ho.

Ho un membro del team che è un puro esempio vivente di " Codificatore di cowboy " . Capisco che non si può cambiare la gente, ma è un modo per farlo smettere di comportarsi come un "codardo Cowboy"?

Si rifiuta di ascoltare la squadra e di recente ha interrotto le revisioni del codice, i test delle unità, condividendo i dettagli di implementazione, ecc.

Sì, "codifica" velocemente, ma il suo codice è solo un generatore di bug. Altri membri del team e io siamo in una "fase di bug fixing" e l'80% dei bug proviene dal suo codice. Non voglio sistemare i suoi bug. E la gestione è cieca, o non vuole vederlo, o forse gli piace la sua "velocità".

C'è un modo in cui io (come il suo più giovane collega per età, non il suo capo) può fare qualcosa al riguardo?

Come posso disattivare questo codificatore di cowboy?

Mi sento come se fossi l'ultimo a cui importa davvero del progetto.

    
posta Adronius 18.07.2012 - 17:26
fonte

5 risposte

21

Vedo alcune opzioni:

  • Avvicinati al programmatore con le tue preoccupazioni. Deve essere fatto come critica costruttiva con punti specifici. Prima di compiere passi più grandi è opportuno sollevare preoccupazioni direttamente e in privato per dare alla persona l'opportunità di cambiare.
  • Raccogliere informazioni e statistiche e portarle alla direzione. La gestione potrebbe non sembrare interessata, ma spesso è importante fare lo sforzo comunque nel caso in cui funzioni. Possibili conseguenze negative includono alienare gli altri che non apprezzano i reclami alla direzione.
  • Trova un peer del coder cowboy e discuterlo in privato. Lui / lei potrebbe avere una migliore possibilità di far ascoltare la persona.
  • Chiedi di lavorare su un'altra squadra. Non risolverà il problema ma manterrai la tua sanità mentale. Per lo meno lavora sempre al meglio delle tue capacità e non lasciarti trascinare giù.
  • Lascia l'organizzazione se nessuno ascolterà. Sembra un brutto ambiente.
risposta data 18.07.2012 - 17:45
fonte
6

He refuses to listen to the team, and he recently stopped code reviews, unit testing, sharing the implementation details...

Le revisioni del codice non richiedono necessariamente che il programmatore invii il lavoro per la revisione.

Un modo semplice per tenere traccia di ciò che fa è tenere d'occhio la cronologia VCS, cercando i suoi check-in. Se sei preoccupato per il suo codice, questo è un modo semplice per trovarlo. Ottieni una cronologia delle differenze, guarda cosa ha inserito e vedi se qualche bandiera rossa ti salta addosso. Prendi i suoi assegni abbastanza velocemente e se trovi un problema, puoi ripristinare il commit e inviarlo via e-mail in tal senso. Hai il permesso di chiamare i tuoi compagni di squadra, anche se sei un programmatore junior, quando vedi qualcosa di chiaramente sbagliato.

Yes, he "codes" fast, but his code is just a bug generator. Other team members and I are in a "bug fixing phase" and 80% of bugs comes from his code. I don't want to fix his bugs. And management is blind, or doesn't want to see this, or maybe they like his "speed".

Il codice deriva dai requisiti. I requisiti si traducono in test eseguibili che verificano i requisiti sono stati soddisfatti. Questi test possono essere ulteriormente suddivisi e possono essere scritti prima che vengano apportate modifiche per verificare che le modifiche soddisfino i requisiti (red-green-refactor, l'essenza del TDD).

Aggiungi una metrica di "copertura del codice" al server di build della tua squadra (si spera che ne abbia una; in caso contrario, questo è il tuo primo problema). Semplicemente controllando che i test delle unità passino, non colgono i problemi con il suo nuovo codice non TDDed, realizzato in aree che non hanno test unitari. Dopo aver eseguito tutti i test unitari, il server di build dovrebbe idealmente aver eseguito ogni riga di codice, ma ci sono davvero alcune cose che non puoi semplicemente testare unitamente. Realisticamente, dovresti comunque essere in grado di aspettarti una copertura del 95% o migliore (o escludere determinate biblioteche o tipi di file dalla copertura). Prima o poi, il tuo cowboy controllerà qualcosa che rompe la build perché ha abbassato il livello di copertura sotto la soglia e tu lo chiami.

E per quanto riguarda la "velocità", la velocità è quanto velocemente si "fanno" le cose, e non si "fa" fino a quando non viene eseguito correttamente. Puoi metterlo ai tuoi manager in questo modo; considera un meccanico che, quando il manager prende la sua BMW per ottenere un cambio d'olio, dimentica di reinserire il tappo della coppa dell'olio, e di conseguenza tutto l'olio nuovo si riversa prima ancora di uscire dal garage. Certo, il cambio d'olio ha richiesto solo cinque minuti, ma il manager non si preoccuperà di questo quando il motore della sua macchina si blocca sulla via di casa. Si preoccuperà del fatto che il meccanico abbia saltato un passo, e questo gli costerà un sacco di tempo e denaro aggiuntivi da riparare. In questo momento, paga un cowboy per fare il lavoro molto velocemente, e poi paga al resto della squadra una somma molto più grande per entrare e rifare il lavoro correttamente. Che cosa, in realtà, è il vantaggio di continuare a lasciare che il cowboy faccia la sua cosa?

Is there any way that I (as his younger colleague by age, not his boss) can do something about it?

Chiamalo. Quando trovi qualcosa che ha rovinato, mostragli come sta fallendo il suo codice, come potrebbe aver prevenuto il problema in primo luogo (incluso il corretto design, TDD, recensioni del codice) e cosa avresti o dovresti fare come risultato per riparare il suo codice rotto.

I feel like I'm the last one who really cares about the project at all.

klaxon a tutto volume, luci lampeggianti, sirene ululanti - se davvero ti senti come se fossi l'unico a preoccuparsi della qualità del codice prodotto dal team, allora c'è un problema SERIO. Se senti che stai cercando di trascinare l'intera squadra a calci e urla nell'era della buona codifica, ed è semplicemente troppo pesante da trasportare, allora lascia perdere. Se c'è un altro team in azienda che lo fa bene, chiedi un trasferimento, altrimenti vai fuori di testa.

    
risposta data 18.07.2012 - 20:39
fonte
5

Vai al management con le tue statistiche su quanti bug / problemi provengono da questo sviluppatore. Spiega loro che la correzione dei bugs influisce sulla produttività della tua squadra. Se infatti l'80% dei problemi proviene da una sola persona, questo deve essere sicuramente affrontato. Finché lo spieghi al management in termini che possono essere d'accordo (ad esempio "il tempo sprecato è denaro sprecato"), interverranno.

Inoltre, questo sviluppatore dovrebbe risolvere i propri bug / problemi, quindi potrebbe essere utile assegnare loro questi problemi. La tua squadra non dovrebbe occuparsi di questa persona.

    
risposta data 18.07.2012 - 17:34
fonte
4

Is there any way that I (as his younger colleague by age, not his boss) can do something about it?

La pressione dei pari e la guida con l'esempio sono gli unici buoni modi. I modi migliori sono fatti dal loro capo / capo. Se non sei il loro capo / capo, parla con quelli che sono. Ma alla fine è il loro lavoro prendersene cura, non il tuo. Assicurati di fare un buon lavoro e le cose tendono a funzionare da sole.

    
risposta data 18.07.2012 - 17:45
fonte
0

He refuses to listen to the team, and he recently stopped code reviews, unit testing, sharing the implementation details...

Non hai un percorso documentato per il codice tramite revisione, test e implementazione? In caso contrario, hai un problema più ampio. Se lo fai, allora questo è qualcosa che deve essere intensificato.

    
risposta data 18.07.2012 - 18:20
fonte