Revisione del codice avanzato e pratica di unit test

In qualità di team leader nella gestione di un gruppo di sviluppatori senza esperienza (e senza alcuna necessità) di revisione del codice e test delle unità, come è possibile avanzare nella pratica di revisione del codice e test delle unità?

Come hai intenzione di creare un modo per far sì che la revisione del codice e i test unitari si adattino naturalmente al flusso dello sviluppatore?

Una delle resistenze di queste due aree è che "siamo sempre stretti sulla linea di dati, quindi non c'è tempo per la revisione del codice e il test dell'unità".

Un'altra resistenza per la revisione del codice è che al momento non sappiamo come farlo. Dovremmo rivedere il codice ad ogni check-in o rivedere il codice a una data specifica?

I membri del tuo team concordano sul fatto che le revisioni del codice e i test delle unità sono buone cose, ma non c'è tempo per queste?

O cercano semplicemente di respingere l'idea con questa scusa?

Nel primo caso, la soluzione è iniziare a farlo ora . (OK, se sei negli ultimi giorni prima di un importante traguardo, forse puoi aspettare fino a dopo - ma non di più.) Abbiamo avuto quella situazione in un mio precedente posto di lavoro, dove ero Ingegnere della Qualità, responsabile del miglioramento delle pratiche di codifica e qualità complessiva. Abbiamo continuato a rinviare l'inizio delle revisioni del codice fino alla prossima settimana. Un giorno mi sono reso conto che lo stiamo facendo da circa un mese e probabilmente continueremo fino alla fine dei tempi a meno che non provi qualcosa di diverso. Quindi ho annunciato la prima revisione del codice per quella settimana. Ho detto ai ragazzi "nessun problema se sarà imperfetto, o se non sappiamo esattamente cosa fare ancora - inizieremo a farlo, vedremo come andrà e miglioreremo le cose mentre impariamo". Ha funzionato, almeno fino a quando ho lasciato la compagnia.

Nel secondo caso, potresti aver bisogno di più istruzione e discussione aperta con il team. Discutere i problemi di qualità del codice, chiedere loro che cosa essi vedono come problemi nel processo di sviluppo (o mancanza) / nel codice / test ecc E brainstorming insieme su come risolvere questi . L'obiettivo finale non è necessariamente quello di fare revisioni del codice - sono solo mezzi, mentre l'obiettivo è migliorare il processo di sviluppo e la qualità del suo output. Si può scoprire che ci sono altri problemi più dolorosi che potrebbero essere migliorati più facilmente, portando più benefici più velocemente; poi prendili prima. Possono anche essere banali cambiamenti nell'ambiente o nel processo; tutti questi miglioreranno il morale della squadra, costruiranno la fiducia reciproca e aiuteranno il legame della squadra.

La linea di fondo è che non puoi imporre la qualità a nessuno: puoi solo rimuovere gli ostacoli alla creazione di qualità . Applicando regole rigorose e pratiche obbligatorie senza previo consenso del team , è possibile alienare il team e, in definitiva, impedire il miglioramento della qualità a cui si sta mirando. OTOH attraverso una discussione aperta e mirando ad un accordo su quali siano i problemi più urgenti per la squadra e su come migliorare la situazione, è più probabile che tu ottenga il supporto della squadra. Ciò farà una differenza cruciale nel mantenere la spinta al miglioramento della qualità a lungo termine.

Il classico problema. Mai abbastanza tempo per farlo bene, sempre abbastanza tempo per rifare il lavoro. Fino a quando le persone non inizieranno a fare le migliori pratiche, non ci sarà mai abbastanza tempo per fare le migliori pratiche. Soprattutto perché le vittorie sono invisibili alle persone al di fuori dello sviluppo.

La chiave per la revisione del codice è che si desidera rivedere il minor codice possibile, il più immediatamente possibile. In questo modo è più facile trovare il tempo per esaminarlo, il codice è fresco nella mente delle persone e implementare i miglioramenti suggeriti sarà più facile. All'estremo si desidera rivedere ogni singolo check-in. Un buon strumento per automatizzare questo è http://code.google.com/appengine/articles/rietveld.html . È una variante dello strumento che Google utilizza internamente per forzare la revisione del codice a ogni check-in.

La sfida della revisione del codice è stata descritta decenni fa nel classico The Psychology of Computer Programming . Il problema è che i programmatori tendono a legare la propria immagine di sé alle proprie capacità di programmazione. Ciò significa che ogni volta che i programmatori devono confrontarsi con prove che le loro abilità non sono all'altezza, c'è la tendenza a prenderlo sul personale. Ciò può causare gravi conflitti. Se raccogli il classico sviluppo rapido di Steve McConnell, ti offre una serie di suggerimenti su come impostare un processo di revisione del codice che riduca le probabilità di tale conflitto. (Un elemento chiave è assicurarsi che la direzione non abbia mai alcun coinvolgimento nel processo.) Si noti che ciò riduce le probabilità di conflitto, ma non impedisce che si verifichino conflitti.

Detto questo, i benefici superano di gran lunga i costi. Giusto per citare una metrica, IBM ha scoperto che la revisione del codice era il modo più efficace per trovare ed eliminare i bug. Ciò non sostituisce in alcun modo il reparto QA. Ma comporta molti, molti meno problemi per loro da trovare. E questo è prima di ottenere benefici che coinvolgono quanto accelera l'apprendimento, diffonde conoscenza, ecc.

Non dare loro l'opzione. Rendere obbligatori test e recensioni. Se non collaborano, puoi ricorrere ad alcune tattiche rigide come il rifiuto di promozioni non testate o non riviste. Se le cose vanno davvero male, licenzia il tuo peggior trasgressore.

Ho visto casi in cui un team è sempre in ritardo perché correggono sempre bug che avrebbero dovuto essere scoperti da test e recensioni. Un po 'più di lavoro in anticipo consente di risparmiare molto di più a lungo termine e prima metterai in linea la tua squadra, migliore sarà la tua squadra.

Sfortunatamente, questo può richiedere del tempo per vedere davvero i risultati. Per incoraggiare la pratica, puoi iniziare a tracciare la percentuale di segnalazioni di bug, il tempo medio per la correzione di bug e la velocità di implementazione delle funzionalità. Di solito scopro che dopo circa sei mesi di test e recensioni, queste metriche miglioreranno e il tuo team finalmente riuscirà.

Presentare tdd contro la volontà degli sviluppatori è difficile. È un modo difficile per imparare ad amare tdd.

Dal momento che tdd è più efficace in un campo verde (o duro, costoso, inefficiente se i test sono svaniti dopo le onde), inizierei con un piccolo team che implementa qualcosa di nuovo. Se trovi due devellopper nella squadra che sono meno contrari a quelli degli altri, questo è un buon punto di partenza. tenere presente che la produttività dei tdd-developper ne risentirà mentre non hanno esperienza con tdd.

Questo sviluppo tdd è un buon punto di partenza per una visualizzazione codere. Discutere su come il tdd ha influenzato l'architettura del programma e come facilita la manutenzione del software.