IDI @localhost
25 Jun 2020
at online
Talk comments
Great!
Very interesting... It's a takeaway
Nice talk
Interesting talk, to be better investigated how to apply it to company realities more than open source applications
Buona presentazione, realizzabile a pieno nel campo dell'opensource e dei test, da comprendere le reali applicabilità in situazioni aziendali
Bravo Mattia, ottima talk, ben spiegata con le giuste parole, e giusto approccio mentale e pratico.
Slideshow TOP
very interesting, argument of general interest I'd say
Thank you
good argument and good speaker but speaker not too much engaging..
Top Davvero!
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