Rifiuta di ascoltare il team e recentemente ha interrotto le revisioni del codice, i test delle unità, condividendo i dettagli dell'implementazione ...
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 storia di 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 salta fuori da te. Prendi i suoi check-in abbastanza velocemente e se trovi un problema, puoi ripristinare il commit e inviarlo via e-mail in tal senso. Ti è permesso chiamare i tuoi compagni di squadra, anche come programmatore junior, quando vedi qualcosa che ovviamente non va.
Sì, "codifica" velocemente, ma il suo codice è solo un generatore di bug. Gli altri membri del team e io siamo in una "fase di correzione degli errori" e l'80% dei bug proviene dal suo codice. Non voglio riparare i suoi bug. E il management è cieco, o non vuole vederlo, o forse gli piace la sua "velocità".
Il codice deriva dai requisiti. I requisiti comportano test eseguibili che verificano che i requisiti siano stati soddisfatti. Tali test possono essere ulteriormente suddivisi e possono essere scritti prima che vengano apportate modifiche per verificare che le modifiche soddisfino i requisiti (refattore rosso-verde; l'essenza del TDD).
Aggiungi una metrica "copertura del codice" al server di build del tuo team (si spera che tu ne abbia uno; in caso contrario, questo è il tuo primo problema). Il semplice controllo del superamento dei test unitari non colpirà 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 generazione dovrebbe idealmente aver eseguito ogni riga di codice, ma in realtà ci sono alcune cose che non si possono testare. Realisticamente, dovresti comunque aspettarti una copertura del 95% o superiore (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 lo chiami.
E per quanto riguarda la "velocità", la velocità è la velocità con cui fai "fare" le cose, e non viene "fatto" fino a quando non viene fatto 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, si dimentica di rimettere il tappo della coppa dell'olio, e di conseguenza tutto il nuovo olio fuoriesce prima ancora di uscire dal garage. Certo, il cambio dell'olio è durato solo cinque minuti, ma il gestore non se ne preoccuperà quando il motore della sua auto si bloccherà sulla strada di casa. Si preoccuperà che il meccanico abbia perso un passo, che gli costerà molto tempo e denaro in più da sistemare. In questo momento, sta pagando un cowboy per fare il lavoro molto velocemente, e poi ' s pagando al resto della squadra una somma molto più grande per entrare e rifare il lavoro correttamente. Qual è, in realtà, il vantaggio di continuare a lasciare che il cowboy faccia la sua cosa?
C'è un modo in cui io (come suo collega più giovane per età, non come capo) posso fare qualcosa al riguardo?
Chiamalo fuori. Quando trovi qualcosa che ha rovinato, mostragli come il suo codice non sta funzionando, come avrebbe potuto prevenire il problema in primo luogo (inclusi design appropriato, TDD, recensioni di codice) e cosa dovevi o ti sarà richiesto di fare di conseguenza per correggere il suo codice non funzionante.
Mi sento come se fossi l'ultimo a cui interessa davvero il progetto.
i clacson squillano, le luci lampeggiano, le sirene gemono - se ti senti davvero come se fossi l'unica persona che si preoccupa della qualità del codice prodotto dal team, allora c'è un problema SERIO. Se senti che stai cercando di trascinare l'intera squadra a calciare e urlare nell'era del buon codice, ed è troppo pesante da trasportare, quindi lascialo cadere. Se c'è un altro team dell'azienda che lo sta facendo nel modo giusto, chiedi un trasferimento, altrimenti esci.