Come guida un team di tecnici, come devo gestire gli errori di codifica e le cattive pratiche dei membri del team? [duplicare]

5

Sono un team leader tecnologico in un team di circa 5 sviluppatori. La dimensione del team è piuttosto dinamica dato che i membri del team partono periodicamente per altri progetti e altri si uniscono al team da altri progetti.

Periodicamente mi imbatto nel codice dei membri del mio team, sia quando apporto modifiche, scrivendo qualcosa nelle vicinanze, o semplicemente rivedendo il loro codice. A volte (spesso abbastanza per scrivere questo post, immagino) il loro codice è scritto male, con piccoli errori (come la conversione di due oggetti Date in stringhe per poterli confrontare) o più grandi (scrivendo 2+ quasi identici medio-grandi funzioni dimensionate con una sola differenza di linea, invece di una funzione in grado di gestire entrambi i casi.)

Qual è il modo migliore per migliorare le loro capacità e segnalare loro questi errori? A volte vado oltre questi segmenti di codice con loro, spiegando perché dovrebbero essere scritti in modo diverso. Ma non voglio essere pignolo e farli venire troppo spesso a rivedere il loro codice. Il codice esamina la risposta qui? Se sì, come dovrebbero essere organizzati? Dovrebbero includere tutti i membri del team o essere individuali? Quante volte dovrebbero essere tenuti? Qualche altro consiglio?

C'è un'altra domanda che si legge in modo simile, ma in realtà è diversa, perché oltre ad essere curiosa delle revisioni del codice, mi piacerebbe anche conoscere altri possibili modi per migliorare le capacità di codifica dei membri del mio team. Inoltre, le scadenze non hanno un ruolo nella mia domanda perché possiamo facilmente rivedere e / o correggere il codice prima o dopo il rilascio di una versione successiva.

    
posta Val Schuman 02.06.2015 - 23:28
fonte

3 risposte

6

Ci sono alcune cose che puoi fare per questa situazione. In primo luogo, fai ciò che puoi per avere un libro delle regole a cui fare riferimento. In altre parole, quando emergono cose come questa, è meglio dire: "Dai un'occhiata alla pagina 6 della guida allo stile". Oppure, "Ecco un link a un sito Web che spiegherà qualcosa che voglio farti sapere" e salvare quel link per la tua biblioteca. Come leader tecnologico, fa parte del tuo lavoro per evitare il debito tecnico, quindi questo è un obbligo per loro.

In secondo luogo, piuttosto che indicare cosa hanno fatto di sbagliato, ponete loro domande sul loro codice. Ad esempio, il mio mentore mi ha sorpreso a copiare gli array quando non avevo bisogno di farlo, così mi ha chiesto: "Cosa pensi che questo codice qui stia davvero facendo?" Avevamo una cultura del rispetto reciproco che rendeva tali domande stimolanti, piuttosto che pignoli.

Se governate da una politica, mantenete il vostro ruolo di gatekeeper e trattate le persone con rispetto, i buoni impiegati lo adoreranno e quelli cattivi troveranno un altro lavoro. Ricordati di elogiare pubblicamente, ma di criticare in privato. E il feedback è un regalo; i bravi programmatori ti diranno come stai se glielo chiedi.

    
risposta data 03.06.2015 - 03:03
fonte
2

Ecco le mie opinioni sulle recensioni del codice.

Ottima idea in teoria ma devi gestire le cose con attenzione. I programmatori sono creativi, egoisti e può essere estremamente sottile. Una revisione del codice di squadra aperta può facilmente trasformarsi nel Colosseo romano. I programmatori possono scegliere a vicenda il lavoro a pezzi in modo malevolo e improduttivo. Anche se lo fai uno contro uno, può ancora trasformarsi in un'esperienza negativa. Il consiglio di Gavin di criticare in privato è un ottimo consiglio e qualcosa che è difficile da mantenere quando ci sono recensioni di codice aperte.

Il suggerimento di Gavin (di nuovo) sulla stesura di una guida di stile o di un documento sugli standard di codifica è di nuovo ottimo, ma devi avere l'autorità per rafforzarlo. Suggerisco caldamente di trovare un buon modello online e di adattarlo, altrimenti ci sarà sangue tra le fazioni di coloro che mettono l'apertura "{" sulla stessa linea e coloro che la mettono sulla propria linea, ecc. Ho visto (seriamente) un strumento di formattazione del codice da riga di comando incorporato nel flusso di lavoro di check-in per rinforzare lo stile aziendale (buono - suppongo) ma poi ho visto anche i codificatori rinnegati della stessa azienda usano lo stesso strumento con diversi parametri di stile per formattare il codice "a modo loro" al check-out (non così buono).

Attendi il nuovo contenuto, acquista una libreria di buoni libri sulla programmazione, ad es. "Pulisci codice", "Pulisci codice" e "Codice completo" e prova ad avviare una cultura dell'apprendimento e del miglioramento.

    
risposta data 03.06.2015 - 03:30
fonte
0

Non sono un caposquadra, quindi non l'ho usato in pratica.
Ma, a mio modo di vedere, una gara sana è la strada da percorrere.
Chiedi ai tuoi sviluppatori di risolvere una sfida non correlata al lavoro. Stessa sfida per tutti gli sviluppatori.
Assicurati di spiegare in anticipo cosa rende una buona soluzione (funzioni brevi, nomi significativi, efficienza ecc.).
Quando tutti hanno finito, vota per la migliore implementazione.
Il fatto che tutti stiano lavorando sullo stesso problema consentirà discussioni più profonde, poiché tutti hanno pensato alla soluzione.
Il fatto che non sia correlato al lavoro ridurrà l'ansia del fallimento e renderà le persone più sensibili alla critica.
Rendere tali contenuti una tradizione migliorerà gradualmente le capacità di codifica dell'intero team senza la necessità di passare attraverso il processo di revisione del codice.

    
risposta data 03.06.2015 - 04:02
fonte

Leggi altre domande sui tag