Trattare con uno sviluppatore ignorando continuamente casi limite nel suo lavoro

Ho un problema interessante, abbastanza comune, immagino, con uno degli sviluppatori del mio team. Il ragazzo è un grande sviluppatore, lavora veloce e produttivo, produce codice di qualità abbastanza buona e tutto il resto. Bravo ingegnere. Ma c'è un problema con lui - molto spesso non riesce a risolvere i casi limite nel suo codice.

Ne abbiamo parlato con lui molte volte e ci sta provando, ma credo che non la pensi così. Quindi ciò che finisce è che il QA troverebbe molti problemi con il suo codice e lo restituirebbe per lo sviluppo ancora e ancora, con conseguente scadenze scadute e tutti i membri del team infelici.

Non so cosa fare con lui e come aiutarlo a superare questo problema. Forse qualcuno con più esperienza potrebbe consigliare?

Richiedigli di scrivere test di unità automatizzati per il suo codice. Scrivere test unitari costringe a pensare attraverso i casi limite.

Alcuni particolari:

1. Per assicurarsi che non si senta individuato, questo dovrebbe essere istituito per l'intera squadra. Richiedi a tutti di scrivere test di unità automatizzati per il nuovo codice o il codice che modificano.
2. Richiede che i nomi dei test unitari siano descrittivi sul caso in cui stanno testando.
3. Coprire i test unitari automatizzati nella revisione del codice ad alto livello. Chiedi ai revisori di cercare i casi di test persi (ad esempio quei casi limite che gli mancano perennemente). Dopo una certa quantità di feedback da parte del suo team sui casi limite persi, probabilmente imparerà a considerare quelli prima della revisione.
4. Applica questa regola per l'intero team: se il QA rileva un bug, lo sviluppatore responsabile deve il test automatizzato che conferma l'errore e quindi dimostra di averlo corretto. (prima di fare qualsiasi altro lavoro)

Dagli una lista di controllo, ad es

• ingressi nulli
• ingressi a estremi estremi della gamma
• ingressi a limite estremamente piccolo dell'intervallo
• combinazioni
• input che violano gli invarianti presunti (ad es. se x = y)

La gente di QA può aiutare a elaborare l'elenco di controllo

Dai la checklist a tutti gli sviluppatori, non solo a questo.

Bravo ingegnere.

Va bene.

Ma c'è un problema con lui - molto spesso non riesce a risolvere i casi limite nel suo codice.

È una qualità che i buoni ingegneri non condividono.

Prestare attenzione ai casi limite è una caratteristica presente o meno nelle persone. Non ha nulla a che fare con l'essere un ingegnere o un programmatore. Lo sviluppo di questa caratteristica è influenzato dal background culturale, dall'ambiente di vita, dagli eventi dell'infanzia e dalle esperienze di vita. Quindi l'atteggiamento viene semplicemente applicato a qualsiasi lavoro svolto da un individuo.

Ciò di cui hai bisogno è scoprire se il tuo ragazzo è di quel tipo che non ha sviluppato questo certo senso (forse ancora). È anche molto probabile che non gli importi per un motivo o per l'altro. Devi analizzare l'intera situazione, se è felice nel suo lavoro. In caso contrario, forse dovresti fare qualcosa per aiutarlo prima.

Se sta bene con il lavoro ma non ha ancora sperimentato il pericolo di casi limite, allora puoi iniziare a educarlo. Se lo prende sul serio, potrebbe cambiare nel tempo. Anche se sono scettico su questo, potresti ancora provarlo.

Se comunque si rivelerà essere quel tipo di persona che non è brava nei casi limite, allora non avrai altro che rimuoverlo dalla squadra. Questa caratteristica è essenziale per la programmazione pratica. Purtroppo, senza di essa nemmeno una persona eccezionale non produrrebbe un buon lavoro.

Potresti fare revisioni del codice o revisioni del progetto in precedenza nel processo?

Insegnagli a programmare il test prima. Abbinalo a lui. Scriverai i casi di test e lui scriverà il codice per superare i test.

Poter coinvolgere il QA abbastanza presto nello sviluppo delle funzionalità può fornirgli un elenco di casi limite vicino all'inizio per coprire? Mentre alcuni potrebbero vedere questo come non aspettandosi che lo sviluppatore copra tutto, questo potrebbe essere un modo per aggirare questo problema se tende a perdere quei casi limite che un tester potrebbe benissimo catturare inizialmente.

L'altra idea che avrei qui è come vede questo problema. È davvero infastidito e ha fatto il segno di se stesso per questo schema o lo vede come normale e non qualcosa di cui preoccuparsi di risolverlo? Ammesso che ciò richieda molta fiducia e che sia aperto sulla sua prospettiva, ma penso che ci sia un certo grado di empatia che può aiutare se riesci a vedere le cose dalla sua prospettiva.

Esistono infiniti casi limite, coprirli è impossibile. E se qualcuno lo fa #define TRUE FALSE? Aggiunge casi limite, li controllerai anche tu?

Inoltre, non prenderei in considerazione l'impermeabilità di ogni funzione di una classe privata o di una funzione interna.

L'approccio che scelgo per il codice che deve essere molto solido e stabile è:

if(conditions_met)
{
DoStuff();
}
else
{
CrashAppAndDumpMemory();
}

In questo modo ottieni solidi dump delle applicazioni nel QA e, quando arrivi a una versione, l'app è solida e sicura.

Risolvere gli errori è male. Ok, potresti salvare una funzione se l'handle del file è null e restituisce null, ma nella maggior parte dei casi, c'è un errore di progettazione da qualche parte e l'arresto anomalo dell'app è un modo migliore per forzarti a trovare la causa. La maggior parte dei casi limite mascherano l'errore nascondendo un problema, ad esempio - il pulsante ha smesso di funzionare. Crash ti dice che alcune ipotesi sul prodotto sono sbagliate e devi rivedere la logica che ha causato il crash.

Se si tratta di un caso limite, deve anche essere preso in considerazione? Se i casi limite sono importanti, i casi limite devono essere inseriti nei requisiti / funzionalità / storia utente.

Se le custodie per bordi sono state considerate come parte di un pezzo di lavoro e i dispositivi devono essere messi in atto, allora dovrebbero essere parte dell'elemento di lavoro e per definizione l'elemento di lavoro non è completo fino a quando il meccanismo per la gestione della custodia per bordi è a posto.

Questo ti dà come Lead Team qualcosa su cui verificare dopo che il lavoro è stato completato durante la discussione post lavoro e dà allo sviluppatore qualcosa su cui verificare mentre completa il lavoro.

I casi di cattura sono il motivo per cui esiste il QA. I programmatori hanno la responsabilità di espellere il lavoro in modo tempestivo. Trascorrere tutto il loro tempo alla ricerca di casi limite è molto inefficiente. Se hai un ciclo iterativo ragionevolmente veloce, questo non dovrebbe essere affatto un problema. I casi limite sono quasi infiniti. Se fosse un problema con i casi "Core", sarei un po 'preoccupato. Proprio come gli sviluppatori sono esperti nello sviluppo, un tester dovrebbe essere un esperto nei test. Quando un tester rileva un problema, lo rimandano allo sviluppo. Lo sviluppatore risolve il problema. Problema risolto. Il tempo impiegato dallo sviluppatore per rintracciare ogni caso limite è molto più lungo di quanto dovrebbe impiegare il ciclo di test iterativo. Inoltre, quando parlo di test, non intendo test di unità in scatola bianca, ma test rigorosamente in scatola nera.

Questo è uno dei casi in cui credo che lo sviluppo guidato dai test venga in soccorso perché aiuta a pensare in termini di casi limite e tutto ciò che può violare il codice.