Pratiche agili: revisione del codice - Fallire la revisione o sollevare un problema?

Alla fine di uno sprint di 2 settimane e un'attività ha una revisione del codice, nella revisione scopriamo una funzione che funziona, è leggibile, ma è piuttosto lunga e ha pochi odori di codice. Semplice lavoro di refactoring.

Altrimenti l'attività si adatta alla definizione di done.

Abbiamo due scelte.

• Fallire la revisione del codice, in modo che il biglietto non si chiuda in questo sprint, e prendiamo un piccolo colpo sul morale, perché non possiamo passare il biglietto.
• Il refactor è un piccolo pezzo di lavoro e verrebbe svolto nel prossimo sprint (o anche prima che inizi) come una storia minuscola, a mezzo punto.

La mia domanda è: ci sono problemi o considerazioni inerenti alla raccolta di un biglietto dal retro di una recensione, invece di fallire?

Le risorse che riesco a trovare e ho letto recensioni di codici di dettaglio come 100% o niente, di solito, ma trovo che di solito non sia realistico.

ci sono problemi o considerazioni inerenti alla raccolta di un biglietto dal retro di una recensione, invece di fallire?

Non intrinsecamente. Ad esempio, l'implementazione dell'attuale modifica potrebbe aver portato alla luce un problema che era già lì, ma fino ad ora non era noto / apparente. Fallire il biglietto sarebbe ingiusto in quanto lo falliresti per qualcosa non correlato all'attività effettivamente descritta.

nella recensione scopriamo una funzione

Tuttavia, suppongo che la funzione qui sia qualcosa che è stato aggiunto dalla modifica corrente. In questo caso, il biglietto dovrebbe essere fallito poiché il codice non ha superato il test degli odori.

Dove disegneresti la linea, se non dove l'hai già disegnata? Chiaramente non pensi che questo codice sia sufficientemente pulito per rimanere nella base di codice nella sua forma attuale; quindi perché dovresti prendere in considerazione l'idea di dare un biglietto al pass?

Fallire la revisione del codice, in modo che il biglietto non si chiuda in questo sprint, e prendiamo un piccolo colpo sul morale, perché non possiamo passare il biglietto.

Mi sembra che tu stia sostenendo indirettamente che stai provando a dare a questo biglietto un pass per il morale della squadra, piuttosto che per la qualità della base di codice.

Se è così, allora hai le tue priorità miste. Lo standard del codice pulito non dovrebbe essere modificato semplicemente perché rende la squadra più felice. La correttezza e la pulizia del codice non dipendono dall'umore della squadra.

Il refactor è un piccolo pezzo di lavoro e verrebbe svolto nel prossimo sprint (o anche prima che inizi) come una storia minuscola, a mezzo punto.

Se l'implementazione del ticket originale ha causato l'odore del codice, è necessario indirizzarlo nel ticket originale. Dovresti creare un nuovo biglietto solo se l'odore del codice non può essere attribuito direttamente al biglietto originale (ad esempio, uno scenario "paglia che ha rotto il dorso del cammello").

Le risorse che riesco a trovare e ho letto recensioni di codici di dettaglio come 100% o niente, di solito, ma trovo che di solito non sia realistico.

Pass / fail è intrinsecamente uno stato binario , che è intrinsecamente tutto o niente.

Ciò a cui ti riferisci qui, penso, è più che interpreti le revisioni del codice come richiedono un codice perfetto o altrimenti falliscono, e non è così.

Il codice non dovrebbe essere immacolato, dovrebbe semplicemente rispettare il ragionevole livello di pulizia che il tuo team / azienda impiega. L'adesione a quello standard è una scelta binaria: aderisce (passa) o no (fallisce).

Sulla base della tua descrizione del problema, è chiaro che non pensi che questo aderisca allo standard di codice previsto, e quindi non dovrebbe essere superato per ulteriori motivi come il morale della squadra.

Altrimenti l'attività si adatta alla definizione di done.

Se "ottiene il lavoro fatto" fosse il miglior punto di riferimento per la qualità del codice, allora non avremmo dovuto inventare il principio del codice pulito e delle buone pratiche - il compilatore e i test delle unità sarebbero già il nostro processo di revisione automatizzata e non avresti bisogno di recensioni di codice o argomenti di stile.

Al termine di uno sprint di 2 settimane e un'attività ha una revisione del codice [...] Easy refactor job.

Perché viene visualizzato alla fine dello sprint? Una revisione del codice dovrebbe avvenire non appena si ritiene che il codice sia stato eseguito (o anche prima). Dovresti controllare la tua definizione di fatto con ogni storia che finisci.

Se ti ritrovi a finire le storie così poco prima della tua recensione demo / sprint che non puoi inserirla in un compito "minuscolo", allora devi migliorare nel valutare il tuo lavoro. Sì, quella storia non è finita. Non a causa di una revisione del codice, ma perché non si prevede di incorporare le modifiche dalla revisione del codice. È come stimare che il "test" richieda zero tempo, perché "se lo hai programmato correttamente, funzionerà, giusto?". Non funziona così. I test troveranno errori e la revisione del codice troverà cose da cambiare. Se non lo fosse, sarebbe una grande perdita di tempo.

Quindi, per riassumere: sì, il DoD è binario. Promosso o bocciato. Una revisione del codice non è binaria, dovrebbe essere più simile a un'attività in corso. Non puoi fallire . È un processo e alla fine è fatto. Ma se non pianifichi correttamente, non arriverai a quel livello "finito" in tempo e rimarrai bloccato in territorio "non fatto" alla fine dello sprint. Non va bene per il morale, ma devi tenerne conto nella pianificazione.

Semplice: rivedi la modifica . Altrimenti non rivedere lo stato del programma. Se correggo un bug in una funzione di 3.000 righe, allora controlli che le mie modifiche correggano il bug, e il gioco è fatto. E se la mia modifica risolve il bug, accetti la modifica.

Se ritieni che la funzione sia troppo lunga, inserisci una richiesta di modifica per accorciarla o suddividerla, dopo che la mia modifica è stata accettata e tale richiesta di modifica può quindi essere prioritaria in base alla sua importanza. Se viene presa la decisione che la squadra ha cose più importanti da fare, viene gestita in seguito.

Sarebbe ridicolo se tu potessi decidere le priorità di sviluppo durante una revisione del codice, e rifiutare il mio cambiamento per quel motivo sarebbe un tentativo di decidere le priorità di sviluppo.

In sintesi, è assolutamente accettabile accettare una modifica del codice e generare immediatamente un ticket in base a ciò che è stato visualizzato durante la revisione della modifica. In alcuni casi lo farai anche se la modifica stessa ha causato i problemi: se è più importante apportare le modifiche ora che risolvere i problemi. Ad esempio, se altri sono stati bloccati, in attesa della modifica, si desidera sbloccarli mentre è possibile migliorare il codice.

Fallire la revisione del codice, in modo che il biglietto non si chiuda in questo sprint, e prendiamo un piccolo colpo sul morale, perché non possiamo passare il biglietto.

Questo sembra essere il problema.
In teoria sai cosa dovresti fare, ma è vicino alla scadenza, quindi non vuoi fare quello che sai che dovresti fare.

La risposta è semplice: fai quello che faresti se avessi lo stesso codice per la revisione del codice il primo giorno dello sprint. Se sarebbe accettabile, allora dovrebbe ora. Se non lo fosse, non lo farebbe ora.

Una grande parte del processo è decidere cosa significa fare e attenersi alle pistole. Significa anche non impegnarsi eccessivamente e ottenere le revisioni tra pari in tempo utile per consentire ai test di assicurarsi che il lavoro sia anche funzionalmente completo.

Quando si tratta di problemi di revisione del codice, esistono alcuni modi per gestirlo e la scelta giusta dipende da alcuni fattori.

• Puoi semplicemente ripulire il codice da solo e far sapere alla persona cosa hai fatto. Fornisce alcune opportunità di tutoraggio, ma questo dovrebbe essere roba abbastanza semplice che può essere fatto in pochi minuti.
• Puoi respingerlo con commenti su ciò che è sbagliato. Se la gestione degli errori non viene eseguita correttamente o lo sviluppatore continua a ripetere gli stessi errori, ciò può essere giustificato.
• È possibile creare un biglietto e incorrere in debiti tecnici. Il biglietto è lì per assicurarti di pagarlo in seguito. Potrebbe essere che sei in una crisi di tempo e nel processo di revisione delle modifiche vedi un problema più grande non direttamente correlato alla modifica.

La linea di fondo è che quando hai finito con il lavoro devi averlo fatto. Se ci sono problemi più grandi di quelli su cui lo sviluppatore ha lavorato, alza il flag e vai avanti. Ma non dovresti trovarti in una posizione in cui ci sono ore prima della fine dello sprint e ora stai per fare una revisione tra pari. Odora di impegnare eccessivamente le tue risorse o di procrastinare le revisioni tra pari. (un odore di processo).

Non ci sono problemi intrinseci con la deprioritizzazione dei problemi di revisione del codice, ma sembra che i problemi principali che devi concordare, come gruppo, sono:

1. Qual è lo scopo della tua revisione del codice?
2. In che modo i risultati della revisione del codice sono correlati alla definizione di Fine per un elemento di lavoro?
3. Se la revisione del codice si applica come test di gating, quali problemi vengono considerati "bloccanti"?

Tutto ciò si riduce a ciò che il team ha concordato come definizione di Fatto. Se passare la revisione del codice con Zero Issues è la definizione di done per un articolo di lavoro, non è possibile chiudere un articolo che non ha soddisfatto questo requisito.

È come se durante un test unitario un test unitario fallisse. Dovresti correggere il bug, non ignorare il test unitario, se superare i test unitari fosse un requisito per essere Fatto.

Se il team non ha accettato che le revisioni del codice siano una definizione di Fine, le revisioni del codice non sono un test di accettazione del gating dell'elemento di lavoro. Sono un'attività di gruppo che fa parte del processo di backlog per cercare lavoro aggiuntivo che potrebbe essere necessario. In tal caso, tutti i problemi rilevati non sono correlati ai requisiti dell'elemento di lavoro originale e sono nuovi elementi di lavoro a cui il team deve dare la priorità.

Ad esempio, potrebbe essere del tutto accettabile che un team deprioritizzi la correzione di errori di battitura in alcuni nomi di variabili in quanto non influisce sulla funzionalità aziendale che è stata consegnata, anche se il team odia davvero vedere il nome della variabile "myObkect".

Le risposte più votate qui sono molto buone; questo affronta l'angolo di refactoring.

Nella maggior parte dei casi, la maggior parte del lavoro di refactoring comprende il codice esistente; cambiarlo dopo questo è generalmente la parte più piccola del lavoro per uno dei due motivi:

1. Se solo rendi il codice più chiaro e / o conciso, le modifiche necessarie sono evidenti. Spesso hai acquisito la tua comprensione del codice provando cambiamenti che sembravano più puliti e vedendo se effettivamente funzionavano o se mancavano un po 'di sottigliezza nel codice più complesso.

2. Hai già in mente un design o una struttura particolare di cui hai bisogno per semplificare la costruzione di una nuova funzionalità. In quel caso, il lavoro per sviluppare quel design faceva parte della storia che ne ha generato la necessità; è indipendente da te che devi fare il refactoring per arrivare a quel design.

L'apprendimento e la comprensione del codice esistente è una buona dose di lavoro per un beneficio non permanente (tra un mese è probabile che qualcuno abbia dimenticato molto del codice se non continua a leggere o lavorare con esso per quel tempo), e quindi non ha senso farlo se non su aree di codice che ti stanno causando problemi o che stai pianificando di cambiare nel prossimo futuro. A sua volta, poiché questo è il lavoro principale del refactoring, non dovresti eseguire il refactoring sul codice a meno che non ti stia causando problemi o non prevedi di cambiarlo nel prossimo futuro.

Ma c'è un'eccezione a questo: se qualcuno ha attualmente una buona conoscenza del codice che colerà nel tempo, usare quella comprensione per rendere il codice più chiaro e più rapidamente compreso in seguito può essere un buon investimento. Questa è la situazione in cui si trova qualcuno che ha appena finito di sviluppare una storia.

Il refactor è un piccolo pezzo di lavoro e verrebbe svolto nel prossimo sprint (o anche prima che inizi) come una storia minuscola, a mezzo punto.

In questo caso che stai pensando di creare una storia separata per il refactoring è un segnale di avvertimento su diversi fronti:

1. Non stai pensando al refactoring come parte della codifica, ma come un'operazione separata, che a sua volta fa probabilmente cadere sotto pressione.

2. Stai sviluppando un codice che richiederà più lavoro per capire la prossima volta che qualcuno dovrà lavorare con esso, rendendo le storie più lunghe.

3. Potresti sprecare tempo ed energia per il refactoring di cose da cui non ottieni molti benefici. (Se una modifica si verifica molto più tardi, qualcuno dovrà ancora ri-comprendere il codice, comunque; ciò è combinato in modo più efficiente con il lavoro di refactoring. Se una modifica non si verifica in seguito, il refactoring non ha funzionato scopo a tutti, tranne forse estetico.)

Quindi la risposta qui è fallire l'articolo per chiarire che qualcosa nel tuo processo è fallito (in questo caso, è lo sviluppatore o il team che non sta allocando il tempo per la revisione e implementando le modifiche che escono dalla revisione) e fanno sì che lo sviluppatore continui immediatamente a lavorare sull'oggetto.

Quando si va a stimare per la prossima iterazione, rivalutare la storia esistente poiché qualsiasi quantità di lavoro sembra essere lasciata per farla passare la revisione e aggiungerla alla prossima iterazione, preservando la stima dalla precedente iterazione. Quando la storia è completata alla fine della prossima iterazione, imposta la quantità totale storica di lavoro sulla somma della prima e della seconda stima in modo da sapere quanto lavoro stimato è stato realmente inserito. Ciò contribuirà a produrre stime più accurate di storie simili in futuro allo stato attuale del processo. (Vale a dire, non dare per scontato che la tua sottovalutazione apparente non accada di nuovo; supponi che accadrà di nuovo fino a quando non avrai completato con successo storie simili mettendo meno lavoro)

Sono sorpreso dalla mancanza di risposta nelle risposte e nei commenti all'idea di "non riuscire" a una revisione del codice, perché non è un concetto che personalmente conosco. Né mi sentirei a mio agio con quel concetto o con nessuno nella mia squadra che usa quella terminologia.

La tua domanda chiama esplicitamente "pratiche agili", quindi rivisitiamo il manifesto agile (enfasi sulla mia):

Stiamo scoprendo modi migliori per sviluppare software facendolo e aiutando gli altri a farlo. Attraverso questo lavoro siamo arrivati ​​a valutare:

• Individui e interazioni su processi e strumenti
• Software funzionante su documentazione completa
• Collaborazione con i clienti sulla negoziazione del contratto
• Rispondere al cambiamento seguendo un piano

Cioè, mentre c'è valore negli articoli a destra, valutiamo di più gli oggetti a sinistra.

Parla con la tua squadra. Discutere il codice in questione. Valutare i costi e i benefici e decidere - come gruppo coeso di esperti - se riformattare questo codice ora, più tardi o mai.

Inizia a collaborare. Smetti di fallire le revisioni del codice.

nella recensione scopriamo una funzione che funziona, è leggibile, ma è piuttosto lunga e ha pochi odori di codice ...

Ci sono problemi o considerazioni inerenti alla raccolta di un biglietto dal retro di una recensione, invece di fallire?

Nessun problema (secondo il mio team). Presumo che il codice soddisfi i criteri di accettazione indicati nel biglietto (vale a dire, funziona). Crea un elemento di backlog per indirizzare la lunghezza e gli odori di qualsiasi codice e assegnale le priorità proprio come qualsiasi altro ticket. Se è davvero piccolo, allora dai la priorità in alto per il prossimo sprint.

Uno dei detti che abbiamo è "Scegli il miglioramento progressivo rispetto alla perfezione posticipata".

Abbiamo un processo molto fluido e costruiamo un numero abbastanza buono di funzionalità di "proof of concept" (1 o 2 per sprint) che superano lo sviluppo e il test ma non superano mai la revisione interna degli stakeholder (hmm, possiamo farlo invece ?), alfa o beta ... alcuni sopravvivono, altri no.

Nel progetto attuale, ho perso la traccia di quante volte abbiamo creato una determinata funzionalità, l'ho presa nelle mani degli stakeholder e uno o due sprint in seguito, l'ho completamente rimossa perché la direzione del prodotto è cambiata o i requisiti hanno causato una rifusione completa di come la funzionalità dovrebbe essere implementata. Eventuali attività di "perfezionamento" rimanenti per una funzionalità eliminata o che non soddisfano i nuovi requisiti vengono eliminate nonché parte della gestione degli arretrati.

A mio avviso, ci sono due modi per esaminare questo problema:

1. Il modo accademico
2. La via del mondo reale

Dal punto di vista accademico, la maggior parte dei processi di revisione del codice non riesce a distribuire un PBI (prodotto backlog item) quando non viene rispettato lo standard di qualità del codice.

Tuttavia, nessuno nel mondo reale segue agile la T come per uno (per molte ragioni), industrie diverse hanno requisiti diversi. Pertanto, la correzione del codice ora o l'assunzione di un debito tecnico (molto probabilmente creeresti un nuovo PBI) dovrebbero essere decisi caso per caso. Se comprometterà lo sprint o un rilascio o introdurrà una quantità irragionevole di rischio, le parti interessate dovrebbero essere coinvolte nella decisione.

Nemmeno . Se la revisione del codice fallisce, l'attività non viene eseguita. Ma non puoi sbagliare recensioni di codice su opinioni personali. Il codice passa; passare al compito successivo.

Dovrebbe essere una chiamata facile e il fatto che non lo sia suggerisce che non hai abbastanza regole scritte per le revisioni del codice.

1. "La funzione è piuttosto lunga". Scrivere: Le funzioni devono essere inferiori a linee X lungo (io non suggerendo che le regole circa la lunghezza della funzione sono una buona cosa).

2. "Ci sono alcuni odori di codice". Annotare: le funzioni pubbliche devono avere unit test per funzionalità e prestazioni, sia l'utilizzo della CPU che della memoria devono rientrare nei limiti xey.

Se non riesci a quantificare le regole per passare una revisione del codice, otterrai questi casi di ciò che è fondamentalmente "codice che non ti piace".

Dovresti fallire 'codice che non ti piace'? Direi di no. Inizierai naturalmente a passare / fallire in base ad aspetti non di codice: ti piace la persona? Litigano fortemente per il loro caso o semplicemente fanno come gli viene detto? Passano il tuo codice quando ti esaminano?

Inoltre, si aggiunge un passaggio non quantificabile al processo di stima. Stimo un'attività in base a come penso debba essere programmata, ma alla fine devo cambiare lo stile di codifica.

Quanto tempo ci vorrà? Lo stesso revisore eseguirà la successiva revisione del codice e concorderà con il primo revisore o troverà ulteriori modifiche? E se non fossi d'accordo con il cambiamento e rimandassi mentre cerco una seconda opinione o discuto il caso?

Se desideri che le attività vengano eseguite rapidamente, devi renderle il più specifiche possibile. L'aggiunta di un cancello di qualità vaga non aiuterà la tua produttività.

Ri: È impossibile scrivere le regole !!

Non è poi così difficile. Intendi davvero "Non posso esprimere ciò che intendo per codice" buono " . Una volta che lo riconosci, puoi vedere che è ovviamente un problema di risorse umane se inizi a dire che il lavoro di qualcuno non è all'altezza, ma non puoi dire perché.

Scrivi le regole che puoi e discuti sulla birra su ciò che rende il codice "buono".