Quando eseguire la revisione del codice

15

Di recente siamo passati a una mischia e stiamo lavorando su attività e storie degli utenti all'interno degli sprint. Vorremmo fare frequentemente revisioni del codice per renderle meno scoraggianti. Pensiamo che lo facciano a livello di user story ma non siamo sicuri su come ramificare il nostro codice per tenere conto di ciò.

Stiamo usando VS e TFS 2010 e siamo un team di 6.

Attualmente stiamo ramificando le funzionalità, ma stiamo lavorando per passare alla ramificazione per la mischia.

Al momento non utilizziamo scaffali e non vogliamo davvero implementarli se sono disponibili altre tecniche.

Come consigliate di implementare la revisione del codice per la storia dell'utente?

agile code-reviews scrum

— mcass20
fonte

3

Dipende dalla natura delle storie degli utenti.

Può essere efficace creare un ramo per ogni user story, sono visibili progressi su storie diverse, possono essere passati se necessario, se le storie non sono completate nello sprint, i progressi possono rimanere nel ramo per lo sprint successivo . Le revisioni finali possono quindi essere eseguite alla fine di una user story nel ramo use story e unite se il codice è standard.

Per lavorare nel modo in cui le storie devono essere accuratamente studiate per evitare ingestibili compiti di fusione al termine di uno sprint. Piccole storie consentiranno un costante aggiornamento del ramo di sviluppo attraverso lo sprint da cui gli sviluppatori che lavorano su altre storie di utenti devono costantemente attingere (VCM di base).

Questo crea sovraccarichi di processo che devono creare e unire costantemente i rami che in alcuni casi possono essere risolti con script di automazione, ma il team deve ancora essere molto a suo agio con il VCS.

Alla fine di uno sprint unisci il tuo ramo di sviluppo in integrazione / produzione ecc.

Ho anche lavorato in team in cui tutti lavorano al di fuori di un ramo di sviluppo, al termine di una storia utente il codice viene inviato a quel ramo per la revisione e il test e se qualcuno spinge qualcosa che interrompe lo sviluppo degli sviluppatori, deve far entrare le birre del team.

13

Il modo più efficace per rivedere il codice è alzarsi, trovare qualcuno e chiedere loro di venire a discutere del codice che hai appena sviluppato.

Non utilizzare uno strumento a meno che non sia possibile trovare qualcuno per rivedere il codice localmente.

È possibile evitare del tutto le revisioni del codice accoppiando.

— Ryan Cromwell
fonte

Mi chiedevo quando qualcuno avrebbe menzionato l'associazione. Tra questo e il test unitario avrai molte recensioni.

— JeffO

Ho letto questo come "alzati, licenzia qualcuno e chiedi loro di venire a discutere del codice che hai appena sviluppato". Grazie per aver reso la mia giornata.

— Will Morgan,

4

Tutti i membri del team sono locali? In tal caso, basta chiedere a qualcuno di venire a dare un'occhiata prima che il codice venga archiviato. Non locale? Accendi il tuo programma di condivisione dello schermo preferito e chiama qualcuno. Personalmente lo faccio spesso. A volte lo faccio solo per dire "Ehi, guarda cosa ho fatto!"

Preferisco di gran lunga questo stile di revisioni del codice ad hoc rispetto allo stile in cui qualcuno si alza in piedi e presenta il proprio codice al team. Le revisioni ad hoc possono darti molti (tutti?) Vantaggi dell'accoppiamento senza l'imbarazzo. Inoltre, è più probabile che il tuo "revisore" faccia domande e suggerisca miglioramenti in un ambiente informale e individuale.

— jgrim
fonte

1

Credo che la revisione del codice non sia una parte formale di SCRUM, tuttavia le revisioni sono una tattica indipendente per raggiungere la qualità e migliorare i tuoi progetti / team.

Quindi, useresti SCRUM (o altra metodologia di sviluppo agile) per garantire / migliorare la qualità del PROGETTO e rispettare i tempi. Inoltre, una buona tattica è fare la revisione del prodotto (non il codice) in modo indipendente dalle normali attività di controllo qualità / test. Se questa attività potesse essere svolta davanti al tuo team / partner / clienti / pubblico, sarebbe meglio.

Dovresti usare le revisioni del codice (o altre specifiche) principalmente per migliorare il tuo TEAM, aspettandoti risultati a medio / lungo termine. Ciò influirà sui PROGETTI, ma a lungo termine come prodotto del miglioramento del TEAM.

Quindi, per rispondere alla tua domanda, credo che tu stia provando a spingere troppo da SCRUM, e dovresti considerare meglio le revisioni solo così come sono.

— Ron-Damon
fonte

Scrum non dice né consiglia nulla riguardo al programma. Si aspetta che tu fornisca valore su base regolare. Fornisce anche momenti in cui è possibile ispezionare e adattare il processo in modo da migliorare (meglio non necessariamente significa più velocemente).

— Ryan Cromwell,

Sì, Scrum non dichiara di fare un programma completo come parte di esso. Tuttavia, intendevo "pianificazione" quando mi riferivo alla pianificazione, pianificazione nel senso che il tuo cliente si aspetta un certo valore in un determinato momento, in modo da poter eseguire lo scambio tra valore v / s del denaro (se consideri che stai fornendo servizi di sviluppo / programmazione ).

— Ron-Damon,

In questo caso, il tuo cliente dovrebbe avere un budget da spendere in un determinato momento (per pagarti, per esempio) e potrebbe avere un programma a cui occuparsi. Lavoro come fornitore di servizi, ecco perché non posso lasciare da parte questo fatto.

— Ron-Damon,

Contratti a parte, i team Scrum forniscono valore non servizi. Sviluppiamo / programmiamo come mezzo per offrire quel valore.

— Ryan Cromwell,

Non credo che potresti separare i termini "valore" e "servizio" amico. Credo anche che ora sia molto fuori tema.

— Ron-Damon,

0

Non è ovvio fare revisioni del codice prima di registrarlo?

TFS non funziona come GIT, quindi ogni volta che esegui il check-in di un ramo o del trunk, è disponibile per tutti.

Ciò significa che la revisione dovrebbe avvenire al momento del check-in, quindi le modifiche non valide non vengono propagate alla copia di lavoro di tutti.

— Byron Whitlock
fonte

Penserei che, in generale, i test unitari siano ciò che impedirebbe cambiamenti errati.

— John Saunders,

@ John Saunders: considera le revisioni del codice come un altro tipo di test unitario.

— Gilbert Le Blanc,

@Gilbert: potrei farlo, ma poi non trarrebbero beneficio dai test di regressione. Preferirei dedicare del tempo a scrivere di più e migliori unit test.

— John Saunders,

@ John Saunders, @Gilbert Le recensioni del codice Le Blanc vengono eseguite da un altro sviluppatore, i test unitari vengono generalmente eseguiti dallo sviluppatore originale, la nuova prospettiva può essere vitale.

Ho avuto buona fortuna con i test unitari (le liste dei test sono state concordate in anticipo) e l'analisi del codice automatizzata, possibilmente combinata con uno strumento di analisi dello stile come StyleCop. Ma poi, non lavoro spesso con sviluppatori junior.

— John Saunders,