Talk in Italian at IDI @localhost
Short URL: https://joind.in/talk/175ab
(QR-Code (opens in new window))
Tutti dicono che "bisogna fare code review", poi però nel mondo reale non c'è tempo per farle, oppure le si fa in modo sbagliato. Questo talk spiega perché dovresti introdurle nel tuo team e qualche modo per farle nel miglior modo possibile per massimizzarne gli effetti positivi. Se partecipo, cosa imparo? Perché esattamente le code review sono una buona pratica (e non solo "perché tutti dicono che sono una buona pratica"), le differenze tra una buona review e una cattiva review, e qualche consiglio tattico per ottenere più valore possibile nel farle.
Comments
Comments are closed.
Top Davvero!
very interesting, argument of general interest I'd say
Thank you
Bravo Mattia, ottima talk, ben spiegata con le giuste parole, e giusto approccio mentale e pratico.
Slideshow TOP
Great!
Molto bravo nell'esposizione dell'argomento. Talk scorrevole e apprezzabile. Non essendo troppo tecnico come gli altri talk della giornata forse gli è stato anche più semplice riuscire a raccontare con più chiarezza le cose. Potrebbero risultare argomenti banali, ma spesso le questioni più scontate sono anche quelle più sottovalutate. Personalmente lavoro spesso in pair (facendo agile, anche in questi ultimi mesi di lavoro @ localhost ) e il paio d'occhi in più quindi c'è già durante lo sviluppo e lo rende più efficace di una code review a posteriori. Il pair programming però non lo facciamo volontariamente per ogni attività di sviluppo, ad esempio quelle più semplici le porta avanti il singolo.
Magari invece capita che inevitabilmente si è costretti a dover lavorare da soli in mancanza di un collega libero. A quel punto preferiamo rivedere il codice con qualcuno prima di portarlo in produzione.
Avendo la possibilità, preferisco farlo vedere potendo spiegare di persona l'attività che ho svolto che credo renda la code review più produttiva con uno scambio diretto, immediato e sincero.
Infine, oltre alla code review implicita con il collega con cui lavoro in pair, c'è il momento in cui l'attività viene validata in un ambiente di stage da parte del cliente che ha richiesto la funzionalità (dal PO allo stakeholder fino ad un collega di un altro team).
In questa fase l'accettazione viene quindi fatta ad opera di una persona estranea al team che valida l'attività da un altro punto di vista che non sia quello tecnico. Tecnicamente appunto il lavoro potrebbe essere ineccepibile e rispettare tutti i principi di clean code, ma in questa fase potremmo scoprire che c'erano dei casi non previsti o fraintendimenti con quello che era stato richiesto.
Anche questa parte di review spesso viene sottovalutata anche se non è esattamente "code review" ma forse più "sprint review". Ancora complimenti per il talk. Grazie