Esaminare la revisione del codice e la pratica dei test unitari

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

O cercano solo di rifiutare l'idea con questa scusa?

Nel primo caso, la soluzione è Inizia 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 di Qualità, responsabile del miglioramento delle pratiche di codifica e qualità complessiva. Abbiamo continuato a rimandare l'inizio delle revisioni del codice fino alla prossima settimana. Un giorno ho realizzato che lo stavamo facendo da circa un mese e probabilmente continueremo fino alla fine dei tempi a meno che non provi qualcosa di diverso. Così 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 semplicemente a farlo, vediamo come va e miglioriamo le cose man mano che impariamo". Ha funzionato, almeno fino a quando non ho lasciato la compagnia.

Nel secondo caso, potresti aver bisogno di più istruzione e discussioni aperte con il team. Discutere dei problemi relativi alla qualità del codice, chiedere a loro quali hanno come problemi nel processo di sviluppo (o meno) / nel codice / test ecc. E fare brainstorming 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à della sua produzione. Potrebbe anche risultare che ci sono altri problemi più dolorosi che potrebbero essere migliorati più facilmente, portando più benefici più velocemente; quindi prendi questi prima. Possono persino essere cambiamenti banali nell'ambiente o nel processo; tutto ciò migliorerà il morale della squadra, rafforzerà la fiducia reciproca e aiuterà il legame della squadra.

La linea di fondo è, non puoi forzare la qualità su nessuno: puoi solo rimuovere gli ostacoli alla creazione di qualità . Applicando regole rigide e pratiche obbligatorie senza un precedente consenso del team , potresti alienare il team e in definitiva prevenire il miglioramento della qualità che stai mirando. OTOH con 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 l'impulso di miglioramento della qualità nel lungo periodo.

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 dal momento che le vincite sono invisibili alle persone esterne allo sviluppo.

La chiave per la revisione del codice è che si desidera rivedere il meno codice possibile, il più immediatamente possibile. In questo modo è più facile avere il tempo di esaminarlo, il codice è fresco nella mente delle persone e l'implementazione dei miglioramenti suggeriti sarà più semplice. All'estremo si desidera rivedere ogni singolo check-in. Un buon strumento per automatizzare questo è link . È una variante dello strumento che Google utilizza internamente per forzare la revisione del codice ad 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. Il che significa che in qualsiasi momento i programmatori sono confrontati con la prova che le loro capacità non sono all'altezza, c'è la tendenza a prenderlo sul personale. Questo può causare gravi conflitti. Se prendi in mano il classico Rapid Development di Steve McConnell, 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 gestione non abbia mai alcun coinvolgimento nel processo.) Nota che questo riduce le probabilità di conflitto, ma non impedisce il verificarsi di conflitti.

Detto questo, i benefici superano di gran lunga i costi. Solo per citare una metrica, IBM ha scoperto che la revisione del codice era dollaro per dollaro il modo più efficace per trovare ed eliminare i bug. Questo non sostituisce il tuo dipartimento QA con qualsiasi mezzo. Ma si traduce in molti, molto meno problemi da trovare. E questo prima di entrare in benefici che coinvolgono quanto accelera l'apprendimento, diffonde conoscenze, ecc.

Non dare loro l'opzione. Effettuare test e recensioni obbligatorie. Se non collaborano, puoi ricorrere ad alcune tattiche hardline come rifiutare promozioni non verificate o non verificate. Se le cose vanno davvero male, licenzia il tuo peggior criminale.

Ho visto casi in cui un team è sempre in ritardo sulla pianificazione perché sta sempre correggendo i bug che avrebbero dovuto essere rilevati da test e recensioni. Un po 'di lavoro in più risparmia molto di più a lungo termine, e prima porti la tua squadra in linea, migliore sarà il tuo team.

Sfortunatamente, questo può richiedere tempo per vedere veramente i risultati. Per incoraggiare la pratica, puoi iniziare a tracciare la frequenza delle segnalazioni di bug, il tempo medio per correggere i bug e il tasso di implementazione delle funzionalità. Di solito trovo che dopo circa sei mesi di test e recensioni, queste metriche miglioreranno e il tuo team riuscirà a ottenerlo.

L'introduzione di tdd contro la volontà degli sviluppatori è difficile. È un modo difficile per imparare ad amare tdd.

Dato che tdd è il più efficace in un campo verde (o duro, costoso, inefficiente se i test sono seguiti in seguito), inizierei con un piccolo team che implementa qualcosa di nuovo. Se trovi due sviluppatori nella squadra che sono meno contrari a TDD degli altri, questo è un buon punto di partenza. ricorda che la produttività degli sviluppatori di tdd ne risentirà mentre non hanno esperienza con tdd.

Questo sviluppo di tdd è un buon punto di partenza per una visione del codice. Discutere di come il tdd abbia influenzato l'architettura del programma e di come si possa facilitare la manutenzione del software.