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.