Benvenuti su Gitbar, il podcast dedicato al mondo dei full stack developer, i mezzo artigiani, i mezzo artisti che ogni giorno infilano le mani nel fango per creare nel modo più efficiente possibile quei prodotti digitali che quotidianamente usiamo.Bene, benvenuti in questo nuovo episodio di Gitbar e come da diverse settimane a questa parte non sono più da solo nonostante il lockdown continua a esserci un vai e vieni di persone super interessantissime anche oggi abbiamo un ospite qua con noi ma prima di presentarvelo sapete il mio ruolo è quello di ricordarvi i nostri contatti quindi info@gitbar.it mia email oppure @brainrepo su twitter per scrivermi direttamente.Naturalmente abbiamo il nostro gruppo Telegram che diventa sempre più numeroso nel quale discutiamo quotidianamente delle robe che più ci piacciono.Comunque bando alle ciance, non perdiamo troppo tempo e vi anticipo l'ospite di oggi ma lo farò subito dopo una piccola pausa.Eccoci qua l'ospite di oggi.L'ospite di oggi è Mattia Tommasone team lead presso Brandon Group o Brandon non lo so poi ci correggerà lui il mio inglese è uguale.Ormai lo sapete è un developer advocate è stato un developer advocate per Google se ricordo bene.Sei stato anche full stack engineer per e insomma hai fatto tantissime cose ma oggi è qua in veste di autore di uno dei media più importanti che seguo che è Soundwall quindi parliamo del tuo nuovo articolo su Young Signorino.No, scherzo.Potremmo anche farlo e potremmo passare ora intero se vuoi a parlare di Young Signorino.è una storia lunghissima e super divertente ma...- Siamo out of scope.- A te la scelta.Oggi infatti con Mattia parliamo di CodeReview.Ma prima di entrare nell'argomento, Mattia, la prima cosa che ti voglio chiedere è chi è Mattia, visto da Mattia? Ok, anche qui è una cosa su cui potrei andare avanti settimane quindi a un certo punto magari fermami.Però Mattia Vistodamattia è uno che anziché scrive codice da una buona quindicina d'anni, se non di più, e a cui questa cosa piace tantissimo, perché gli piace risolvere problemi, gli piace trovare soluzioni non banali e un po' se vuoi artistiche alle cose, ed è soprattutto un grande appassionato di spiegare le cose alle persone.Quindi c'è di mezzo quello che ci siamo detti rispetto alla mia attività di sedicente giornalista musicale.Mi piace raccontare al resto del mondo perché mi piace la musica che mi piace, ma mi piace anche raccontare al resto del mondo perché mi piace scrivere codice, perché mi piace tutto quello che mi piace della scrittura di codice.Credo che ci sia un po' una questione di DNA in questo, nel senso che mia mamma ha fatto l'insegnante, mia nonna ha fatto l'insegnante, mia zia ha fatto l'insegnante.Io ho una lunga tradizione di insegnamento in famiglia e infatti poi per un po' ho fatto anch'io l'insegnante.Subito dopo che mi sono laureato ho insegnato per un po' in università le materie su cui ho fatto la tesi e per 15 anni ho anche insegnato i bambini a giocare a calcio senza saperlo fare io tra l'altro.Ed è quella è stata un'esperienza dal contenuto formativo per me infinito.Ecco domanda, scusa se ti interrompo ma mi piace una curiosità di quell'esperienza quindi dell'insegnare ai bambini a giocare a calcio, alla tua professione, cosa è che ti porti dall'uno all'altro? Un sacco di cose.Anzitutto tieni conto che io ho passato 15 anni a essere la figura dell'allenatore in un gruppo di bambini.Quindi immaginati che io avevo un punto di vista privilegiato su una serie di dinamiche che sono le stesse che ci sono in un team di lavoro, ma che sono, siccome si tratta di bambini che hanno dai 6 ai 10 anni, molto meno mediate da quella malizia e quel pelo sullo stomaco che hanno gli adulti nell'interagire tra loro.Sono, se vuoi, una versione semplificata e molto più diretta delle dinamiche che ci sono poi in tutti i team del mondo, perché una squadra di calcio di fatto si comporta in molti casi come un team di sviluppatori.Ci sono molte dinamiche che sono esattamente le stesse e io per 15 anni ho potuto fare l'osservatore privilegiato su questa cosa, perché ero in spogliatoio con loro, e anche ho avuto l'opportunità poi di cercare di guidare queste dinamiche e di vedere che cosa succedeva, che è una cosa che poi quotidianamente faccio con il mio team di lavoro, nel senso che sono parte del team e in questo momento la mia figura di, se vuoi, lead developer, quindi di uno che banalmente per una questione numerica di anni di esperienza ha un po' più di cicatrici, può indirizzare un po' l'andamento del team.e quindi c'è tantissimo di quello che ho visto succedere in spogliatoio che mi porto dietro.Appunto, è un'esperienza che veramente mi ha insegnato un sacco.E tra l'altro la cosa buffa è che quando ho lavorato per un anno a Google, ho vissuto a Londra, e quindi ovviamente ho smesso di allenare, ed è una delle cose che mi mancavano di più mentre ero là.Sono tornato in Italia, e ok, tempo di risistemarmi un attimo, chiamo il direttore sportivo, gli dico "Guarda, io vorrei ricominciare ad allenare, hai una squadra d'armi?" "Sì, sì, tutto pronto." "Allora, giovedì primo allenamento." "Va bene, va bene, bellissimo." "Il giovedì diluvia, allenamento saltato." "Vabbè, ok, non c'è problema, facciamo allenamento sabato così recuperiamo." E tu fremendola."Sì, sì, sì, ero già sulla porta col borsone." "Il venerdì sera a mezzanotte esce il DPCM che blocca le attività sportive." Quindi io ho ancora qui la ripresa dell'attività ad allenatore.e veramente è una cosa che mi ha distrutto.Credo la cosa che più ho patito delle nuove misure.Ti voglio chiedere un'altra cosa, sempre legata alla tua esperienza.Tu sei stato per diverso tempo Developer Advocate per Google.Ma qual è e in cosa consta il ruolo del Developer Advocate? Allora, tieni conto che Google in realtà è un'azienda gigante che ha tantissimi prodotti e quindi in realtà il ruolo del developer advocate dipende un po' dal prodotto su cui lavori.Io nello specifico lavoravo sull'API di Google Ads, che per Google è un asset non banale, nel senso che quando sono venuto via io ci faceva comunque ancora più dell'80% del fatturato.Però è leggermente diverso rispetto al ruolo degli altri developer advocate.Molti dei developer advocate di Google di fatto sono persone famose nella comunità degli sviluppatori.Per esempio io conosco molto bene quelli che lo fanno per Chrome, ma sono proprio persone famose.Non so, mi viene in mente tipo Jay Karchibald, che era seduto due file di scrivania dietro la mia a Londra, o alcuni personaggi così, una Kravets, anche che lavora a Google da poco.e loro fanno quella che Google chiama evangelization dei prodotti.Quindi fondamentalmente vanno in giro per il mondo a dire agli sviluppatori quanto è figo sviluppare on top ad alcuni dei prodotti di Google.Nel mio caso io non dovevo fare evangelization acquisition perché era una cosa che faceva un team di sales.Quindi le persone con cui avevo a che fare io gli eventi, gli sviluppatori che lavoravano con il mio prodotto, erano sviluppatori che già lo usavano.Ma il mio ruolo era aiutarli a farlo meglio.Quindi anche lì torna un po' la tematica dell'insegnamento e della condivisione, delle cose che mi piacciono.Nel senso che io avevo all'epoca una serie di partner assegnati con cui facevo delle call periodiche o a cui davo supporto, che tipicamente o loro venivano da me dicendo "Io ho questo problema super complicatissimo perché ho beccato un edge case super complicato che nessuno ha mai fatto con l'API di Google perché voglio fare delle cose rivoluzionarie nel mondo dell'advertising, aiutami a farlo.Oppure, dall'altra direzione, potevo essere io a dirgli, "guarda, noi abbiamo queste feature nuove nell'API, potrebbe essere interessante per voi, vi aiuto a fare più soldi con il vostro business on top a Google Ads".e quindi poi anche a far fare più soldi a Google.Ed è di fatto, sai, in generale, secondo me, la figura del developer advocate, non solo per come l'ho vista io e per come la fa Google, ma anche in altre aziende, è un po' un personaggio che si occupa di quel concetto che ho sentito nominare spesso, o in questo contesto, che si chiama ADX, developer experience.Che è di fatto la stessa cosa della user experience, solo che anziché pensare a dove posizionare i pulsanti o come progettare un flusso su un'interfaccia grafica, lo fai con un API, lo fai con un SDK, lo fai con un utente che anziché essere l'utente finale che clicca dei pulsanti è uno sviluppatore che sviluppa cose con un API.Voglio un po' andare contro tendenza Ha un trend che sto vedendo sempre più più forte nei colleghi cioè l'ambizione di entrare dentro delle multinazionali e lavorare su hyperscaler o aziende dell'ordine di Amazon e di eBay di Google e chi meglio di te può aiutarmi a centrare questo focus.Tu oggi lavori in un gruppo super interessante che è Brandon Group dove fate un sacco di cose fighe.Quindi la mia domanda è ricordarci cosa di cosa si occupa Brandon Group e poi ti voglio chiedere quali sono i vantaggi a livello proprio anche di esperienza lavorativa che hai trovato nel passare da una società multinazionale come gigante, dove sei un numero piccolissimo come questi grandi, a un'azienda un pochino più piccola? Quindi se ci sono dei vantaggi, cosa ti è cambiato nell'esperienza di lavoro e su cosa ci hai guadagnato fondamentalmente? Allora, tieni conto che...Allora, iniziamo dalla prima delle tue domande, quindi che che cosa fa Branding Group? Di fatto siamo degli enabler per fornitori di qualunque tipo di merce e gli permettiamo di venderla online, detta in maniera molto, molto, molto vaga e high level.Quello che facciamo è mettere insieme i cataloghi dei fornitori, che possono essere negozi di articoli sportivi come produttori di merce che vogliono venderla online.Facciamo il matching del loro catalogo e del loro stock con gli ordini che arrivano dai marketplace.Quindi in questo momento principalmente Amazon, ma non solo.Quello che succede è che quando tu compri qualcosa su Amazon, Amazon manda a noi un ordine di acquisto e noi mandiamo un ordine di acquisto al fornitore.Questo ci permette di aggregare entrambe le direzioni, quindi di metterci in mezzo un po' di scienza e di fare quindi un po' di algoritmi di pricing e repricing per decidere qual è il prezzo che massimizza le vendite e il nostro margine e anche di gestione dello stock da parte dei fornitori, quindi quando loro hanno la disponibilità o no di alcuni articoli, se devono riordinarli oppure no.Facciamo anche integrazione con la logistica, quindi gestiamo le spedizioni.Insomma, è molto interessante perché dal mio punto di vista di sviluppatore è una cosa che stava molto in mezzo tra la system integration, quindi avere a che fare con sorgenti di dati diverse e metterle insieme, e anche con un po' di scienza, di matematica.Uno dei membri del nostro team è un fisico che ha un background matematico molto forte e che è quello che ha disegnato tutta la logica algoritmica che c'è alla base della scienza che abbiamo.Ed è appunto molto interessante anche in quel senso lì.C'è anche, ed è una cosa che un po' mi manca, nel senso che è una di quelle cose che, sì, vogliamo farlo, dobbiamo farlo e lo faremo, ma non ancora perché siamo ancora in fase di crescita e siamo in meno di quelli che dovremmo essere.c'è una parte di data science che si potrebbe fare, che noi abbiamo di fatto una quantità di dati gigante su cui possiamo fare cose che ancora non facciamo.E la differenza grossa che c'è rispetto a lavorare in un contesto di diversi ordini di grandezza più grande, come era Google, è secondo me su due livelli.Intanto, dal punto di vista umano, il CTO nostro è un mio vecchissimo amico.e quindi diciamo che il rapporto umano è molto più profondo di qualunque altro rapporto abbia avuto nel mio periodo lungo.Io e lui ci conosciamo veramente da una vita, abbiamo lavorato insieme in Buongiorno nel 2010 e siamo rimasti amici lungo tutto questo periodo e quando io poi ho deciso di tornare in Italia ci sentivamo già ed era un po' che dicevamo "Ma sarebbe bello lavorare insieme" e infatti poi è successo.Quindi lavorare in un contesto più piccolo e più amichevole fa molta differenza, nel senso che è più facile diciamo buttare fuori quello che hai dal punto di vista emotivo.Se sei, perdonami il francese, se sei scoglianato per qualcosa, è più facile farlo con una persona con cui hai un tipo di confidenza diverso, è più facile dirlo, è più facile...quindi puoi risolvere i problemi alla base, nel senso che hai un rapporto di confidenza diverso.È anche molto più facile vedere l'impatto di quello che fai.Brandon Group negli ultimi anni ha avuto una crescita vertiginosa e su questa crescita è facile che io possa darmi un paio di pacche sulle spalle e sentirla più mia.Quando c'è il Learning School dei quarter di Google e Google ti dice "Noi abbiamo fatto più X di fatturato", dici "Vabbè, ok, siamo in 100.000 e passa, chissà quanto di questo è merito mio".Quando invece Brandon Group dice che per il terzo anno di fila ha fatto più di 100% di fatturato, io gli ho una pacca sulla spalla, me la do, anche se negli anni precedenti non era merito mio ma l'ultimo sì.Se assolutamente sì hai una percezione del risultato decisamente più forte.Invece, ricollegandoci al ruolo del team lead che rivesti oggi, quali sono le responsabilità, un po' l'hai accennato prima, però quali sono le responsabilità del team leader in ambito dev? Allora, guarda, anche questa è una piccola domanda su cui potremmo parlare settimane.Però per come la vedo io, almeno per come interpreto io questo ruolo, il mio ruolo di lead developer è un ruolo di developer.Io scrivo codice, non sono un engineering manager, non sono...cerco di essere un facilitatore del resto del mio team, ma non è quello il mio ruolo principale.Anche perché in questo ho la fortuna che il nostro Stio è una cintura nera, è super bravo.Io sono un developer, sono se vuoi una sorta di Primus Interpares, nel senso che sono uno sviluppatore e faccio a tutti gli effetti parte del team che scrive codice, ma sono probabilmente quello con più cicatrici.Quindi per dirti sono quello che, questo tra l'altro è un bel gancio rispetto a quello di cui vogliamo parlare, sono quello che ha introdotto il processo di cold review all'interno del team.E allora ti sei tirato dietro proprio la domanda che volevo farti.Adesso uso il tuo punto di vista perché poi molti condiscono la definizione con le proprie esperienze personali, ma dal tuo punto di vista che cos'è la Code Review e qual è lo scopo di fare Code Review? Allora, guarda, che cos'è? È molto semplice.L'idea è che il codice che viene rilasciato in produzione venga visto da più di un paio d'occhi prima di essere rilasciato.Quindi non è che tu lo scrivi, lo merge, lo rilasci, ma prima ci metti davanti almeno un altro paio d'occhi.Questa cosa ha, secondo me e secondo la mia esperienza, una serie di vantaggi immediati e non.Nel senso che, ok, c'è quella cosa che si chiama "legge di Linus, dove Linus è il signor Torvalds che tutti ammiriamo e apprezziamo.Spesso per le sue capacità dialettiche ed in building.Certo! Però lui ha formulato, nell'ambito probabilmente di qualche flame nel mio sgrup di Linus, ha formulato questa legge, che si chiama legge di Linus, che dice che se tu ci metti davanti un numero sufficiente di occhi, tutti i bug avvengono a galla.Quindi fare code review, quindi mettere degli occhi in più a leggere il codice prima che venga mergeato, è uno strumento di debugging, diciamo, a basso costo.Nel senso che scovare un bug ed eventualmente risolverlo prima che venga rilasciato in produzione, costa sicuramente meno.C'è un grafico che ho visto diverse volte che mette proprio in relazione il tempo che è trascorso come è stato scritto il codice e lo stato in cui è il codice nel processo di rilascio e il costo di fissare un bug.Ovviamente se tu trovi un bug mentre stai scrivendo il codice, tu costa niente risolverlo, perché ce l'hai già sotto mano ed sei già lì.Se devi risolvere un bug dopo che è stato rilasciato in produzione, il costo è massimo.Ovviamente farlo in fase di coder via, quindi prima che venga rilasciato, ti consente di ridurre quel costo.e quindi un processo di code review ti consente di trovare più bug e di ridurre il costo di risolverli.Ci sono però poi anche, secondo me, una serie di effetti positivi di un processo di questo tipo che non sono immediati.Per esempio, una cosa che ho visto succedere è che leggere codice è uno strumento formidabile per imparare cose.È uno strumento per imparare intanto delle tecniche che magari non conosci.Io, per dirti, sono in Brandon Group da un anno e poco più e il grosso della nostra applicazione è scritto in Kotlin.Io non avevo mai scritto una riga di Kotlin prima di entrare.Ok, conosco Java e l'ecosistema della JVM da un po', per cui Kotlin si impara in fretta ed è stupendo, tra l'altro.Però leggere codici di persone che scrivono Kotlin da qui in tempo di me e mi ha insegnato moltissimo sul modo idiomatico di fare le cose.Oltre a questo, mi ha insegnato anche tantissimo sui nostri processi di business, per esempio.Molto più che leggere documenti dei requisiti o quant'altro.Ovviamente, leggere il codice mentre viene scritto, di fatto.Perché quando fai il review di una cosa che sta per essere rilasciata, è diciamo il living standard dello stato dell'arte delle applicazioni, è uno strumento importantissimo per imparare.Quindi per me, nella mia esperienza in branding group, è stato uno strumento di ramp up gigante.Mi ha aiutato a diventare produttivo nel nostro ecosistema di applicazioni, a conoscere meglio i nostri processi di business.Ma è anche uno strumento ovviamente per tutt'ora che i processi di business li conosco bene.È uno strumento, tra l'altro, che poi come effetto a lungo termine ha anche come effetto che sei costretto a metterti nei panni di qualcun altro.E questa cosa più la fai più è devastante come impatto, nel senso che Quando scrivi il codice che sai che sarà visto da qualcun altro, hai un po' di pressione a scriverlo meglio, hai un po' di pressione a comunicare meglio che cosa fa, perché devi spiegare a quello che lo leggerà che cosa fa il tuo codice.E quando guardi il codice scritto da qualcun altro, ti devi mettere nei suoi panni e capire un po' il suo ragionamento.Quindi, in ultima analisi, quello che succede dopo tanto tempo che fai questa cosa che è un grandissimo acceleratore di empatia, che è proprio l'abilità di mettersi nei panni di qualcun altro.Secondo me è una skill fondamentale.Sì, è una di quelle soft skills trainanti.Tra l'altro a me piace ritornare sempre sul concetto come codice uguale tra le varie cose mezzo di comunicazione, perché fondamentalmente il codice è scritto per gli uomini non per le macchine.Poi le macchine lo devono interpretare per fare delle azioni ma è uno strumento di comunicazione per cui volevo giusto aggiungere un elemento ma perché l'ho vissuto come esperienza personale fare code review in una fase super early di sviluppo ti dà anche quegli elementi che sono dei feedback di design che non potresti valutare a posteriori cioè dare un colpetto per raddrizzare la macchina in una certa traiettoria lo sviluppo in una certa traiettoria più facile mentre lo si sta sviluppando piuttosto che arrivare nell'ultimo momento e quel feedback secondo me ha un grande valore così come dicevi tu il valore della condivisione della conoscenza che non è solo come si fa un either o come si evita un if o come adesso sto banalizzando però anche riguardante i processi aziendali e qua perdonami se ci batto, ma sono quegli elementi che secondo me dovrebbero spingere all'utilizzo del processo di code review anche quando potrebbe sembrare overkill.Assolutamente sì, ed è questa cosa che dici proprio secondo un cancello aperto ed è una cosa su cui io stesso litigo con me, spesso e volentieri, perché ci sono molti momenti in cui sembra overkill.C'è una roba in cui dici "vabbè, ho aggiunto un if ed è super facile, è mezza riga di codice che risolve un corner case remotissimo, non sto a fare la pull request, lo merge su master dritto e chi si è visto si è visto".E in realtà no, perché in quel momento facendo così ti perdi la condivisione di quella conoscenza, di visione del motivo per cui hai fatto quella scelta e diventi un silo, diventi l'unico depositario del motivo per cui c'è quel if e se per caso un giorno tu hai mal di pancia e non sei disponibile, nessuno sa perché di… È il famoso single bus factor, no? Esatto.Cioè tutto dipende da te e peccato che non sei immortale.Io ricordo tantissimi anni fa, bellissimo, c'era un...quando ancora usavamo le macchine virtuali, io ricordo di aver acquistato, ancora Amazon non aveva preso il suo posto, Google Cloud non aveva preso il suo posto, e avevo utilizzato un sistema di macchine virtuali, adesso non ricordo il nome, un po' scrauso, quelli che c'era all'epoca.Ricordo che di punto in bianco l'accesso al pannello di controllo venne bloccato.Perché? Perché lo sviluppatore si era tolto la vita, era l'unico sviluppatore di quella codebase, utilizzata anche in ambiente enterprise.Nessuno era a conoscenza di quel codice, quindi da lì a riprendere in mano il progetto e diventare operativo anche il senior più senior Sicuramente mezz'ora non bastava.Quindi cosa era successo era successo che c'era stato un problema un bug che aveva mandato offline un pacco di roba il tizio si era impiccato e nessuno poteva intervenire.Fantastico.Quindi se è un caso da manuale il busfactor.Sì sì sì ma io ricordo di aver passato i due giorni più brutti della mia vita.Perché noi usavamo quel sistema.un panico, però questo dimostra il fatto che in un contesto dove più persone lavorano e condividono la conoscenza abbiamo un contesto sano o almeno presunto tale, poi i problemi potrebbero essere degli altri.Poi sai, allora, è vero anche, cioè allora quello che hai fatto tu è assolutamente un caso limite di Bus Factor ed è vero che il caso limite dall'altra parte, quello della collettivo ownership totale è probabilmente altrettanto raro, nel senso che in qualunque team ci saranno persone che sono più ferrate su una parte dei processi di business che su altre e ci saranno persone che sono la go-to person su alcune parti dell'ecosistema di applicazioni.È inevitabile, è fisiologico che non tutti possano sapere tutto allo stesso modo di come funzionano le applicazioni di un'azienda.Però c'è un ampio spettro in mezzo.Esatto, che è misurabile da quanto tempo ci metti a trasformare un engine normale nella go-to person.Sì, sì, sì.Tra l'altro è una cosa che ho sentito qui da te, in qualche puntata fa, dal mio amico Alessio.Lui dice che è appunto un buon indicatore di quanto sei stato bravo su un progetto è quanto ci mette una persona nuova a diventare produttiva quando entra o quanto ti detestano le persone a cui fai end off.In effetti ha molto senso, come molte delle cose che dice Alessio.Le bestemmie fag.Alessio che tra l'altro è stato complice nel portarti qua da noi quindi lo salutiamo caramente.E adesso andiamo a qualcosa di un pelino più pratico e quindi ti voglio chiedere come si struttura un processo di code review? Beh allora anzitutto alla base c'è c'è uno strumento che ti permetta di farlo.Noi usiamo Bitbucket, che ha i repositori privati free, quindi non c'è veramente nessun motivo per cui un'azienda non dovrebbe usarlo.Non è sempre stabilissimo, ha degli incidenti un po' troppo frequenti per i miei gusti, però tutto sommato il suo lo fa.In passato in eBay usavamo GitHub, Google ha ovviamente la sua infrastruttura proprietaria per fare questa roba, perché Google si è rifatta tutto in casa.Ne abbiamo parlato nell'episodio dei tre porcellini sui monolipo.Sì, esatto, Google ha il monolipo per quasi tutto.Però, appunto, alla base c'è uno strumento che ti permetta di fare review di una...di quella che Google chiama "change list", quindi di una lista di modifiche, un codice che di fatto è un IDIF, di un set di modifiche che vuoi emergiare sul branch principale della tua applicazione.Quindi ci sono poi diversi modi di strutturarlo, il processo.Uno dei fattori chiave, per esempio, è quante persone devono vedere il tuo codice prima che sia emergiabile.Ed è una domanda chiave, nel senso che ognuno ha poi la sua interpretazione.Tipo il team in cui lavoro adesso è un team molto piccolo, siamo in cinque.e spesso e volentieri non c'è motivo che più di una persona veda il codice che hai scritto, anche perché di fatto se lo vedono due persone vuol dire che lo sta vedendo il 50% del resto del team ed è in effetti un po' overkill.Anche perché una cosa fondamentale è sapere che fare review di codice è una cosa che richiede tempo, non la devi fare di corsa e quindi chiedere del tempo al 50% del resto del team è un po' troppo.Quindi per noi basta una persona.Google ha una cosa leggermente diversa, nel senso che c'è tipicamente un owner del progetto, o più owner, quindi la review di una changelist la deve fare uno degli owner, che quindi conosce bene quello di cui stai parlando, fondamentalmente, ma in una buona parte dei casi anche qualcuno che ha, quella che Google chiama readability nel tuo linguaggio, quindi conosce le forme idiomatiche, conosce lo stile che ci si aspetta che abbia quel linguaggio, ma non necessariamente conosce il contesto applicativo.Quindi ha, diciamo, uno sguardo più fresco.Sì, neoletico.Perché di fatto ti sa dire "ok, capisco che cosa fa questo codice" ed è scritto bene, stilisticamente, anche senza conoscere il contesto applicativo.Quindi ti sei spiegato bene, in sostanza.Ci sono però diversissimi modi, tantissimo di diversi, di fare questa roba.GitLab, per esempio, ha questa roba per cui la fa a catena.Tu metti un reviewer alla tua pull request e questa persona può scegliere se dire "ok, questo codice è immergiabile" o dire "no, voglio un'altra review" e la review va avanti a catena finché qualcuno dice "no, è immergiabile".Secondo me questa cosa è una cosa che va decisa all'interno del team, va condivisa con tutto il team ed è il team che la decide.È veramente una cosa super soggettiva e super dipendente da come è fatto il team, da come è composto anche il team.Puoi decidere, per esempio, che tu hai un team di X persone in cui il 90% è una semplificazione, ma diciamo è junior, lavora da poco e ci sono poche persone, di nuovo, una semplificazione senior, che conoscono bene le cose, potresti decidere che sono queste persone che fanno il review.Oppure no, potresti decidere che fare il review è uno strumento di formazione e sono solo le persone junior che fanno il review.Potresti decidere un po' e un po'.È una cosa su cui secondo me il team deve raggiungere un accordo prima e però è importante che una volta che il team ha raggiunto un accordo lo mantenga.Guarda, voglio farti una domanda su questo.Secondo te, dalla tua esperienza, ha senso implementare metodologie differenti per parti diverse del software? Ti faccio un esempio.Io ho seguito, sono andato a guardarmi un po' dei tuoi talk, dei contenuti che hai creato sulla Code Review e hai parlato di Tactical Code Review, quindi un approccio un pochino più tattico alla revisione del nostro codice.Ecco, in funzione proprio di quest'ottica, ha senso un approccio selettivo per parti diversi che adesso la parte core del nostro software utilizza una metodologia che possiamo chiamare Google Way dove c'è quello che ha una visione di insieme e che dice ok quello che è scritto non funzionerà mai nel contesto dove lo stiamo calando e quello che ti dice no il punto e virgola non va messo così quindi quel tipo di approccio o piuttosto un approccio un po più lasco come dici tu un unico reviewer che guarda prende push e emerge prende emerge direttamente la review? Mi rendo conto che sto per dire una cosa paracula ma non posso che dirti dipende.Però no, l'argomento mio dipende.Diciamo che secondo me quello su cui è utile raggiungere un accordo con tutto il team è una sorta di minimo comunque denominatore che tutte le review devono avere.Quindi dire sì, ok, un pezzo di codice non può essere emergiato se non l'ha visto una persona senior e una persona junior, tipo.O non l'ha visto una persona owner e una persona non owner, che è quello che fa Google.O se proprio detesti una persona, un pezzo di codice non può essere emergiato se non l'ha visto Mattia.e Mattia in quel momento, dopo due mesi dà le dimissioni.[risate] Quindi di fatto puoi decidere il minimo comune denominatore.Da lì in poi ci puoi costruire sopra delle review aggiuntive di caso in caso.Magari è successo, succede spesso anche nel mio team.Ho scritto delle cose che toccano più parti del nostro ecosistema.voglio un parere da più persone.Ho scritto delle cose che appunto fanno parte del core delle nostre applicazioni e quindi rischiano di impattare molte cose, magari in quel caso, siccome si tratta di modifiche potenzialmente critiche, chiedo un paio d'occhi in più.Una cosa che però secondo me è molto rischiosa da fare è aprire una pull request e mettere tutto il team.Quella cosa lì è tipicamente negativa perché quello che succede è che a tutti arriva la mail che devono fare la pull request.Esatto, tutti aprono, vedono che ci sono dieci reviewer e dicono "va be', la farà qualcun altro" e chiudono.E chi s'è visto, s'è visto.E una settimana dopo ti trovi a dover andare a mettere il dito tra le costole qualcosa di "oh io ho scritto 'starà buona' settimana fa, me la fai rilasciare, per favore".Cosa abbastanza comune questa.Assolutamente sì.Poi andiamo a giocare un po', vogliamo un attimino sugli anti-pattern tipici delle code review, ma non spoileriamo quello che andremo a vedere dopo.Ti voglio fare una domanda che non ha senso questa domanda, me rendo conto, però mi diverte farla.Cercherò di fare una risposta sensata.Sì, è un po' non sense.La mia domanda è, ma leggere il codice di altri è davvero così difficile? Il senso della domanda è, quali sono gli elementi di difficoltà nel leggere il codice di altri dalla tua esperienza? Beh, allora ti rispondo un po' ad amarzullo dicendoti che sono più o meno gli stessi elementi che ci sono nello scriverlo.Tu hai detto prima in maniera molto giusta che quando tu scrivi del codice non lo stai scrivendo per la macchina che lo esegue, ma per delle altre persone.Tra l'altro in una maggior parte dei casi l'altra persona per cui lo scrivi è il te stesso di tra sei mesi.che lo leggerai e dirai "ma chi è la bestia che ha scritto questa roba?" e poi ne eri tu.E quindi leggere il codice è difficile, o meglio, non dovrebbe essere difficile se è stato difficile scriverlo.Se tu sei stato bravo a scrivere il codice, il codice è facile da leggere.Però c'è un rapporto molto molto profondo tra quanto è stato difficile scrivere il codice, quindi quanto è stato complesso, articolato il processo mentale che ti ha portato ad arrivare a quell'artefatto lì, alla fine, e quindi il carico cognitivo che tu metti addosso a chi poi lo legge.Se tu hai scritto nel codice ipercomplicato, iperconvoluto, perché è frutto appunto di un processo molto articolato, ma questo processo non è evidente nel codice che hai scritto, sarà difficile anche leggerlo.Quindi, leggere codice scritto da altri è difficile? Sì, soprattutto se chi lo ha scritto non ha articolato bene come c'è arrivato.Questa cosa, tra l'altro, mi dà da pensare a una cosa che leggo spesso rispetto ai commenti del codice.Spesso ho letto che i commenti del codice dovrebbero commentare il "why" del codice, non il "what".perché servono a spiegarti perché sei arrivato a scrivere il codice che hai scritto.Se tu commenti dicendo "questo codice fa questo", ok, grazie, lo leggo, lo vedo.Idealmente i commenti nel codice dovrebbero aiutarti a spiegare come ci sei arrivato.Ho quello, ho anche la descrizione di una pull request, che è un elemento spesso sottovalutato, secondo me, ma è fondamentale.Perché ti ho fatto questa domanda che può sembrare banale e stupida? Perché volevo portarti come un po' come Caronte a ragionare per un attimo sul contesto di codice buono è avere un'opinione sul codice che stai leggendo cioè come facciamo a scindere l'unità minima che rende la barriera che rende il codice accettabile dal che ne so gli elementi stilistici vabbè marginalmente perché poi abbiamo degli inter degli strumenti che un standardizzano ma da quegli elementi che rendono più personale il codice visto che il codice è la rappresentazione dei nostri pensieri in merito a un certo ambiente e un certo contesto.Quindi come fai tu a distinguere se stai ragionando in termini di linee di accettabilità o sei entrato nel il contesto del nitpicking, quindi sei super tignoso e ti attacchi sulle cagate che poi non portano il codice in produzione.Dove sta questa barriera? È una linea difficile, è una linea difficile nel senso che anche lì c'è di mezzo anche ed è un tema che immagino toccheremo poi e su cui si potrà parlare per ore e ore e settimane, del fatto che dall'altra parte della tua codreview c'è una persona.E quindi la linea tra "non capisco cosa fa questa cosa, puoi scriverla meglio, perché poi dovrò mantenerla io e per favore scriverla meglio" e il nitpicking è molto sottile.Quindi sì, dipende ed è difficile trovare la quadra su questa linea anche perché è una comunicazione tipicamente scritta e asincrona, quindi con delle barriere diverse.Se io e te siamo seduti uno di fianco all'altro e io ti faccio un hitpeaking su come hai scritto un if, per se usi due spazi anziché quattro, queste cose veramente minori, tu magari dalla mia faccia o dal mio tono di voce capisci che ti sto rompendo le palle su cose minori, piuttosto che dalla mia espressione capisci che invece no io non sto capendo niente del codice che hai scritto e questa cosa va rifatta.In fase di code review questa cosa è un po' più difficile da trasmettere.Io me la cavo spesso, ne esco da questa cosa usando gli strumenti che ho imparato a usare in anni di forum, di social network e di comunicazione sull'internet.Quindi l'Accademia della Crusca forse disprezzerà, ma faccio largo uso degli emoji e delle gif animate nelle mie code review.Uso spesso anche, per dirti, quando faccio code review, quando so che sto facendo nitpicking metto il mio commento tra due tag "boring", perché faccio capire alla persona che mi sto facendo review che lo so che sono un rompiballe, sto rompendo le palle su cose sottili, però per favore abbi pazienza con me.Però sì, è una linea sottile ed è difficile spesso capire...anche lì, è difficile mettersi nei panni dell'altra persona, perché devi magari dire all'altra persona "guarda, il tuo ragionamento non lo capisco" oppure "lo capisco e non lo condivido".Guarda sfondi una porta aperta sul fatto di mettersi nei panni dell'altra persona, l'ho ripetuto diverse volte quindi capisco proprio l'importanza di questo passaggio e la condivido.La cosa che secondo me è più formativa in quest'ambiente è di provare a fare una code review tua.Uff devastante.Questo perché? è un'esperienza che ho fatto personalmente perché in realtà nel team per me era un attimo cadere nel tignoso lo zelante sai quello che spacca le balle e mi sono reso conto di una cosa che intanto quando noi scriviamo il codice guardiamo il nostro codice il codice c'è chiaro perché lo spazio del problema è ben chiaro nella nostra testa quindi siamo più tignosi nel codice di altri rispetto ai nostri anche sulle fesserie cioè quando mai hai guardato una spaziatura nel tuo codice però capita che nel codice di altri proprio perché non sei così dentro quel elemento emerga faccia bubble up un altro elemento importante proprio per identificare il nitpicking è quello di non trattarlo come questa è la mia esperienza magari potrei dire delle fesserie però di non trattarlo come un elemento negativo a prescindere ma provare a capirlo.Nella mia piccola esperienza ho notato che quando si entra nel meccanismo del nitpicking vuol dire che c'è qualcosa di più grave che non sta funzionando.Il 90% dell'essere così tignosi dipende dal fatto che in realtà lo spazio del problema e la tua codebase non è eloquente.Quindi l'esigenza di chi legge il tuo codice è quello di partire da una situazione di ordine perché mentalmente diciamo se partiamo dall'ordine forse ci viene più semplice capire di cosa si sta parlando.Quindi trattare questa cosa che è negativa, un antipattern ormai noto, ma come indicatore, quindi come elemento positivo.Sì, è una riflessione bellissima questa che hai infatti.La condivido al 110%.Tra l'altro, in effetti, quello che hai detto rispetto all'idea di farsi coderview da soli, che è una cosa che veramente la trovo potentissima, in realtà un pochino ti arriva gratis quando mandi una pull request, nel senso che almeno io ho questa abitudine, perché me l'hanno insegnato quando facevo il tema alle superiori, di consegnarlo lo rileggi.Prima di schiacciare send di una pull request io la rileggo e se dovessi quantificarti la quantità di bug e di commenti che ho prevenuto in quel momento lì, tonnellate.Assolutamente.Io suggerisco sempre di fare, adesso non ricordo, quando si fa la add per la comedia, fare sempre il menù P e riguardare un pochino ciò che stai facendo che è importantissimo perché noi abbiamo il commit compulsivo alle volte quando scriviamo scriviamo il nostro codice quindi è una cosa che secondo me è importante per me io mi sforzo per per farlo anche quando sono un solo developer o developer del mio side project, cioè mi faccio dei pull request da solo.Però qual è l'altra informazione in realtà che è importante e che formalizzi anche il processo evolutivo della tua applicazione in quel modo, quindi stai mettendo dei paletti.E tra l'altro, scusami se ti interrompo, una cosa che fai anche in quel momento lì, è che oltre a formalizzarlo, lo verbalizzi anche.E facendo questa cosa, quindi scrivendo che cosa fa per esempio una pull request, spessissimo ti capita, perché lo hai verbalizzato e non ce l'hai più solo in testa, ma lo butti fuori, che capisci di più del problema che stavi risolvendo e ti vengono in mente magari delle cose che immediatamente non ti venivano in mente.Quando parlo di questo argomento in pubblico, è una cosa che mi piace chiamare automatic rubber ducking, fondamentalmente.C'è questa tecnica di debugging in cui tu racconti il tuo problema a una papera di gomma, no? E per il fatto che lo stai verbalizzando, lo capisci da un altro punto di vista e spessissimo, mentre lo verbalizzi, ti viene in mente la scrivere la descrizione del pull request, questa cosa te la fa fare gratis ed è anche lì uno strumento cognitivo potentissimo.Sì, spesso però nelle nostre pull request ci hanno come testo, o le pull request che vedo spesso, è "update" o "fix", esatto.Allora, secondo te, dalla tua esperienza, come si scrive il testo di una pull request se andiamo pur request perché stiamo parlando di code review ma potrebbe anche essere calata nel testo di una commit in modo un pochino più conciso quindi quali sono secondo te le buone pratiche le regolette da rispettare il più possibile compatibilmente.Siamo tutti abbastanza elastici in questo però la cosa a cui tendere nel momento in cui io scrivo una pure request.commento anche questo.Beh, secondo me il fattore discriminante lì è quanto contesto serve e quanto contesto devi dare appunto a chi la legge.Partiamo dal presupposto che ovunque tu metta l'asticella, FIX è troppo poco.Su questo non mi sento di dire di...Però è vero anche che...Però, sai, ci sono...Ovviamente c'è pull request e pull request, c'è commit e commit.Se tu hai aggiunto un if per un corner case, è diverso da aggiungere una feature da una settimana di lavoro.Fermo restando che una pull request da una settimana di lavoro e cento file modificati è un po' una smell.Ed è forse un segno che detesti la persona a cui hai fatto fare Code Review.E che idealmente dovrebbero essere un po' più piccole.Dovrebbero essere unità di lavoro piccole per centomila motivi.Però, secondo me, appunto, la...la sticella sta nella quantità di contesto che devi dare a chi legge.Quindi una pull request, una descrizione di una pull request o un comment di un commit fatto bene è una cosa che tu la leggi tra sei mesi e capisci che cosa fa.Perché...senza avere contesto, perché tra sei mesi il contesto non ce l'hai più, ovviamente.e quindi dici "ok, si è rotta questa cosa, quando ho fatto questo commit voglio fare il revert", per dirti.Anche quello è un caso che esiste.E tu questa cosa la leggi dal testo del commit.Questo commit fa questa cosa, e quindi ecco dov'è che ho introdotto quel bug, e se faccio il revert il bug torna a posto.Oppure ecco dov'è che ho introdotto quel bug, lo sistemo in questo modo.se il posto dove ha introdotto quel bug ti dice "fix" cosa vuoi capire? Giustissimo, naturalmente poi noi pure questa la mettiamo, aspettiamo che il nostro codice subisca la revisione e ci arriva la risposta della revisione.E quello è un momento bellissimo.Esatto, infatti voglio arrivare proprio a quel momento dove, giusto per collegarmi al panel che avete fatto ieri super interessante.Abbiamo il link, c'hai condiviso il link nel gruppo Telegram quindi grazie.Però in realtà la mia domanda è come, specie se siamo dei junior o comunque abbastanza giovani nel mondo, come dobbiamo gestire emotivamente la code review? Lì è veramente...quello è veramente il momento difficile, nel senso che puoi essere la persona più senior del mondo, secondo me, puoi essere, che ne so, Brian Kernighan, puoi essere Stallman, puoi essere chi vuoi, ma nel momento in cui tu hai scritto del codice, pensi che quel codice lì sia giusto, e quando ti arrivano dei commenti a una pull request, ti stanno dicendo che quel codice lì così giusto non era, comunque ha del margine di miglioramento.Siamo persone, tutti quanti, lì è dove esce la sindrome dell'impostore, lì è dove esce l'emozione che ti dice "se rischi di entrare in quel tunnel in cui ti dice 'sono scarso, non so scrivere il codice, sono una capra' e quella è una reazione positiva.Positiva? No, è assolutamente una reazione negativa.La seconda reazione negativa possibile è "questa persona mi detesta, ce l'ha con me, l'odio, la prossima volta che mi manda una pull request gliela faccio vedere io".Gli "picking"? Gli correggo pure i punti e virgola.Nessuna di queste cose è particolarmente costruttiva.Ora, anche lì, di fatto, c'è di nuovo il tema della barriera, nel senso che è una comunicazione asincrona, è una comunicazione scritta, magari da persone che non hanno la tua stessa lingua madre, perché a me è capitato, io non sono lingua madre inglese, non lo mastico, ma non è la mia lingua madre.Ho fatto e ricevuto review da persone che erano di un'altra lingua madre ancora, quindi di fatto ci sono due barriere linguistiche in mezzo e in quel momento far capire il tono di voce è estremamente complicato.Quindi...- Guarda, posso confermare.- Quindi lì passare da uno che ti sta facendo un gentile suggerimento per migliorarti a uno stronzo è un attimo.Però, appunto, una volta che hai tenuto in mente tutte queste cose, perché sia che la pull request arrivi da una persona più autorevole di te, io ho ricevuto review in Google da persone infinitamente più brave di me e ho fatto review a persone infinitamente più brave di me o meno esperte di me.Questa cosa di fatto non fa differenza.Secondo me il mindset che ti aiuta moltissimo in questo è assumere, partire dall'assunto che la persona che ti ha fatto review aveva le migliori intenzioni possibili.Non ce l'ha con te, non pensa che tu sia una capra, perché probabilmente non lo sei, non pensa che il tuo codice faccia schifo, ma semplicemente cerca di aiutarti a trovare dove ci sono degli spazi per migliorarlo, perché probabilmente poi dovrà metterci mano anche questa persona stessa.E quindi vuole fare in modo che sia più comodo possibile metterci mano in seguito per se stessa o per te.Quindi è quello che mi ha veramente fatto cambiare atteggiamento.Dopo le prime volte che ho ricevuto review, ho detto "Voglio solo chiudermi nell'armadio e piangere fino a domani perché non sono più capace, vado a fare il pastore, non sono capace a scrivere il codice.Una volta che capisci, fai questa cosa che si dice "assume good intent", assumi che chi ti fa review abbia le migliori intenzioni possibili, lì capisci che di fatto le persone che ti fanno commenti a un alcune di queste, che ti chiedono di migliorare cose, in fin dei conti ti stanno facendo un favore.Non è piacevole, non piace a nessuno, perché tutti quando facciamo git push pensiamo che il nostro codice sia giusto, altrimenti non l'avremmo scritto così.Quindi non è piacevole sentirsi dire che non era così giusto.Però è sicuramente più piacevole che doverlo sistemare tra se stessi.Dopo, esatto, trovarti con uno spaghetti code da gestire.Io voglio aggiungere una piccola cosa che è una riflessione risentendo un vecchio episodio di Francesco Sciuti che saluto con San Filippo Salvatore San Filippo che tutti conoscono come Antirez questa figura quasi mitologica del panorama Nome tutelare del dopensorsi italiano Esatto, del panorama italiano però in un'intervista lui ha detto una cosa molto interessante che io sposto, in realtà non l'ha detta, però l'ha fatta trasparire.Quello che ne ho distillato io come ragionamento è che fondamentalmente il codice non è la diretta manifestazione di ciò che siamo.Noi siamo delle persone, il codice è un artefatto.Se facciamo una torta o un piatto di pasta che esce cattiva, noi non siamo cattivi come il piatto di pasta che abbiamo cucinato potremmo essere anche il miglior chef se noi partiamo da questo assunto è un po' come faceva salvatore sanfilippo quando diceva redis non sono io redis è un'altra cosa ed è uno dei motivi per cui lui un po' si è allontanato da redis no? quindi sono due cose diverse è vero che io ho contribuito quindi la mia persona ha contribuito, ha generato quel codice ma non mi rappresenta.Se noi riusciamo a fare questa distinzione e a trattare il codice per quello che è, cioè un artefatto, qualcosa che noi stiamo creando ma che non siamo noi, a quel punto saremo anche in grado di accettare meglio le critiche verso quel codice.Poi hai detto anche un'altra cosa molto importante che io sposo a pieno, voi anche per il contesto familiare dove ci troviamo a parlare due lingue diverse con una lingua in comune che è l'inglese che non è nostra prima lingua né mia né di mia moglie quindi puoi immaginare quando bisticciamo che cosa succeda.Però la mia domanda è in un contesto di lavoro come si gestisce il tono nel momento in cui si argomenta sia una pull request che una code review perché spesso le code review dovrebbero essere argomentate, no? - Guarda, il tema del tono di voce in una lingua che non è la tua è difficilissimo.Appunto io ti ho detto "io adesso", perché è un contesto molto amichevole, molto easy, me la cavo bene con le ghiffe animate.Google che è un contesto, se vuoi, non è un contesto formale in nessun modo, perché non lo è, ma è un contesto comunque un po' più strutturato e un pochino più serioso, non tanto, ma un pochino.Visti i cappellini che mettono nei riventi sembra...Ce l'ho! No, fighissimo! Però in quel contesto lì, diciamo che ho imparato e ho visto succedere una cosa che fa una differenza gigante, che è il mio vicino di scrivania all'epoca, che è inglese, quindi lui è madrelingua, mi ha lasciato su una request nemmeno grossa, piccolina, una buona dozzina di commenti e quello che ha fatto è stato banalmente mandarmi un messaggio in chat e dirmi "guarda sono stato un po' picchi sulla tua pull request, scusami, sorry", banalmente.E fa tutta la differenza del mondo, nel senso che ok, in quel momento lì lui ha fatto proprio il passaggio da stronzo, non c'è un modo meno francese di dirlo, da uno che appunto mi manda una review per cui voglio chiudermi nell'armadio a piangere a uno che invece ha a cuore il mio codice.Sorry è una parola semplice, non è così difficile e al di là di ogni barriera linguistica, credo, però fa una differenza gigante.Assolutamente sì.Intanto il tempo passa noi ci stiamo prendendo un pacco di tempo io non so se hai degli impegni.Ti voglio portare un attimo su un ambito un pochino insomma camminiamo per un attimo sulle pietre e ragioniamo in termini di anti pattern.Una che capita spesso è quella di avere delle code review che sono di tipo gate quindi momento per il cui il codice viene bloccato e se supera quel cancello quel limite poi va in produzione o potrebbe andare in produzione e ci sono dei momenti in cui questa fase in questa fase si inizia a discutere di design.Può capitare.Ecco, intanto quello che voglio chiederti è hai mai avuto esperienza di qualcosa del genere? È indicatore che qualcosa è andato male? Proviamo a immaginare questa situazione dal tuo punto di vista.Ma allora, sicuramente, secondo me, il momento in cui...cioè, il momento in cui, in fase di code review, si finisce a discutere di design, o comunque di argomenti, diciamo, di un po' più alto livello, è un antipattern, infatti, è finito.Nel senso che, se ci sono delle decisioni di alto livello che sono state prese a monte, quelle decisioni o andavano condivise in precedenza, tramite, che non so, un documento di design, banalmente, un momento di agreement prima di iniziare a scrivere il codice, se effettivamente questo codice è frutto di decisioni articolate e complicate a livello di design, oppure a quel punto, se arrivi a una pull request, non è più il momento per discutere il design.Cioè, o lo discutevi prima, o non lo discuti in fase di code review.Diciamo che proprio per quello che hai detto tu prima, che il codice è un artefatto, è un prodotto finito, o meglio, è un prodotto vivente, ma è comunque il frutto di un ragionamento e una serie di ragionamenti, è il frutto di una serie di passi che, come ci dicevamo prima, ricorrerà all'indietro più ne ripercorri più costa.Per cui, se ci sono molti passi, probabilmente avrebbe senso cercare di fare un po' una specie di freeze delle decisioni.Ovviamente nulla è mai scolpito nella pietra, però un po' di accordo condiviso su alcune decisioni, prima lo raggiungi meglio stai.Assolutamente, anche perché la formalizzazione obbliga tutti gli stakeholder, quindi le persone impegnate nell'argomento, a dedicare neuroni per ragionare sulla cosa, piuttosto che dire "ah ok, va bene", perché fondamentalmente di questo si tratta."Ah, ok, va bene", anche quello è l'antipattern per definizione in fase di Code Review, nel senso che mi è capitato in passato e di recente di fare e di ricevere Code Review di fretta, di dire "Ah, ok, va bene, sì".Perché, boh, magari, non lo so, mi arriva una pull request non gigantesca scritta da uno che so che è super competente su quella parte del progetto."Ah, ok, va bene".Sei mesi dopo, quella roba lì ha un bug in produzione.Chi è la bestia che ha provato questo codice? Sì, capita a tutti, perché siamo umani.E oltretutto, sai, sì, ok, va bene senza leggere il codice, è una roba tremenda, perché di fatto contraddice tutti i buoni motivi per cui è utile fare coddore vico, ci siamo detti prima.Non è solo una questione di bug che non emergono nel momento in cui costa meno, ma è anche...ti perdi un momento di formazione, ti perdi un momento di condivisione della conoscenza, crei un silo, perché...tra l'altro è peggio, perché crei un silo nascosto, nel senso che il team pensa che quella conoscenza sia condivisa, ma non lo è.E' proprio...quella cosa lì è il peggio che può capitare a un processo di codrivia.(sfondo) (voce in sottofondo) È arrivato la rosina! (sfondo) ci sono poi tutti una serie di altri anti pattern uno di questi è l'anti pattern del ghost reviewer cioè quello capita spessissimo specie in momenti di particolare pressione che gli mandi la pur request aspetti che lui la revisione intanto il tempo passa e lui fa altro impegnato Quindi intanto, pensi che questo comportamento e questo atteggiamento sia indicatore di qualcos'altro che non funziona all'interno del meccanismo del team? E dal tuo punto di vista come si evita questo tipo di situazione? Ma allora, come si evita? Io sono molto della scuola "patti chiari, amicizia lunga", nel senso che questa cosa si evita mettendo in chiaro come è fatto il processo.Per dirti, io in questo momento della mia vita mi trovo molto bene a fare code review la sera dopo che mio figlio si addormenta.Vuoi per una questione di momento storico? In questo momento storico di come è fatto il mondo, il mondo lavorativo, a me viene molto comodo ultimamente staccare da lavoro un po' prima delle sei, faccio nove-diciotto, stacco un po' prima, gioco un po' con mio figlio perché lui a quell'ora è ancora vivo, ancora visco, ma ha letto presto.In effetti quando è stanco è proprio oltre il collasso ed è anche intrattabile, quindi è difficile gestirlo.Però mi viene comodo appunto prendermi il tempo per fare Code Review, che è una che comunque richiede del tempo, la sera dopo che dorme.È un momento in cui io sono relativamente scarico mentalmente, ma non ho, perché è sera e sono stanco, non ho le risorse mentali per mettermi a scrivere del codice.Le risorse mentali che ti richiede leggere il codice e quelle che ti richiede scriverlo sono estremamente diverse.Ah sì, lo fai sull'iPad nel divano.Io ho notato, per esperienza, che la sera dopo che lui dorme sono nel mood spesso e volentieri giusto per fare code review.Questo significa che io faccio code review a un orario in cui il resto del mio team spesso e volentieri non lavora.Quindi spesso e volentieri capita che loro mi mandano un request e l'approvazione e gli arrivano, i commenti, di fatto la mattina dopo.Questa cosa è un agreement che ho con il resto del mio team e che è ok nel momento in cui non c'è niente di urgente.Se ci sono delle pubblicoas urgenti è anche lì agreed tra me e il resto del mio team che me le mandano direttamente su Slack, mi dicono "questa roba è urgente, me la guardi per favore" e ok, in quel momento, se è una cosa urgente, mi interrompo e la faccio anche di giorno, diciamo, anche con il sole in cielo.Però, ti ripeto, è una questione di agreement.Assolutamente sì.Io per un secondo voglio aggiungere la mia considerazione per il valore che può avere.Secondo me ha senso anche guardarsi un attimo e provare a vedere quello che stiamo facendo noi che richiediamo la pull request, la code review, perché il tempo che il nostro reviewer deve mettere per leggere il nostro codice è direttamente proporzionale, forse anche più che proporzionale con la dimensione della nostra pull request.E tu prima hai detto una cosa super intelligente, super interessante, che è quella del cercare di rendere le pull request più piccole e possibilmente quasi atomiche.Quindi un unico elemento e questo secondo me è l'altro lato di quello che hai appena detto.Tu hai parlato dalla parte del reviewer per me c'è anche un impegno che chi scrive il codice e fa la pull request deve un agreement che appunto questa persona deve sottoscrivere.Esiste anche un altro anti pattern che è quello dei feedback inconsistenti, cioè il fatto che che ne so quello che ti torna indietro in realtà è diverso da quello che lo stesso reviewer ti ha detto nella review precedente.Quindi secondo te come si può gestire questa questione dei feedback inconsistenti.Io credo che, sai, l'idea di fondo è che l'obiettivo di tutti deve essere sempre mergiare il miglior codice possibile.Quindi il feedback che dai, nel momento in cui lo dai, devi assicurarti che sia...mi rendo conto che uso un sacco di inglesismi, ma non so come si dice in italiano "actionable".Cioè, deve essere una cosa su cui si può agire.Tu hai parlato del caso in cui ci sono dei feedback contradditori, ma anche il caso in cui un commento, una request dice "questa cosa non mi piace".Ok, quindi come ne usciamo? Dare feedback è una cosa che richiede attenzione ed è anche lì una skill che si impara, tanto quanto riceverlo, abbiamo detto prima perché ricevere feedback non è sempre facile e ci sono modi per migliorare a riceverlo.Anche dare feedback non è semplice e richiede attenzione.Sì, abbiamo parlato di reviewer, no? E quindi abbiamo parlato male finora, abbiamo parlato dei ghost reviewer, di persone che dà i feedback inconsistenti.Però adesso la domanda è, posto che ci troviamo in un contesto dove è possibile scegliere la persona che farà la revisione del codice perché sappiamo che in altri contesti per esempio giocando con il ragionamento dell'ownership probabilmente non puoi scegliere qual è secondo te, dalla tua esperienza, anche un po' diversa immagino nelle varie corporation dove hai lavorato Il modo migliore, la metodologia migliore per la selezione del reviewer per il tuo codice? Ma allora...Qualora sia possibile, naturalmente.Certo, certo.Direi che potendo scegliere, vabbè, senza dubbio preferisco di solito scegliere chi conosce meglio la parte su cui sono intervenuto.E fin qui credo di essere ancora nel territorio delle banalità.Però un'altra cosa che secondo me fa una grossa differenza, almeno quando mi capita e mi è capitato di scegliere, io tendenzialmente scelgo chi fa la review più velocemente.Perché, per via di quello che ci siamo detti prima, perché quando tu schiacci Sand inizi a friggere e dire "oh dai, voglio rilasciare".Cacciati la mosca.Sì, perché il tuo pensi di averlo fatto.Esatto.è vero però certe volte io trovo importante trovare dei momenti per fare il pay reviewing quindi adesso qualcuno di noi probabilmente non conoscerà io lo so è un'esperienza che ho fatto non tanto tempo fa quella del pay reviewing è un'esperienza che ho scoperto da relativamente poco.Quindi, Mattia, riesci a darci un'idea di quello che è il peer reviewing? E secondo te quando ha senso utilizzare questa tecnica? Guarda, io ho fatto una sessione di questo tipo la settimana scorsa, quindi sono fresco.Se dovessi dirti che ne sono anche un fan, no.Però è una cosa che, se usata con grano sali e con attenzione, è uno strumento potentissimo.Fondamentalmente quello che è successo nel mio team è successo che uno di noi aveva scritto del codice particolarmente complicato e particolarmente urgente, perché risultava un bug grosso che ci sta facendo perdere dei soldi.Quindi critico anche una roba su cui non è che ci fosse troppo margine d'errore.E anziché fare una pull request, un processo di review asincrono, in cui ti mando la pull request, lo vedi, bla bla bla, che è quello di cui abbiamo descritto il flusso finora, quello che abbiamo fatto è che è stato che l'abbiamo fatto sincrono, su Meet, lui ci ha condiviso lo schermo con il codice, ci ha raccontato cosa fa, perché lo fa e bla bla, e in tre abbiamo guardato tutti assieme che questa cosa funzionasse, che facesse quello che doveva fare, che insomma, che fosse tutto ok, e che fossimo tutti poi sulla stessa pagina, che le decisioni avessero senso, che non solo che il codice compilasse, che facesse quello che doveva fare, che effettivamente stesse risolvendo il problema che avevamo.Di nuovo, è stato un momento in cui, noi siamo, ti dicevo, in 5, più del 50% del team è stato fermo a non fare altro.Quindi non è una cosa economicamente a basso impatto.È una cosa che ha un suo costo, però è uno strumento molto potente.Sì, specie in ambiti critici come hai detto prima, o in caso di onboarding.In quel caso per esempio è molto molto interessante il fatto che un mentore, magari in contesti un po' più grandi, però un mentore ti dia una mano proprio mettendoci anche il fattore umano.che in una prima fase aiuta anche a comprendere quelle che sono le dinamiche emotive.Ce li rimetto in mezzo perché sai mi immagino il ragazzo appena uscito all'università che deve sull'aprima code review, forse è il caso di fargliela di persona così almeno gli dai una pacca sulla spalla dopo che gliel'hai dette.Sì, assolutamente sì.C'è da dire anche che però è una cosa che è molto soggettiva, nel senso che si lega molto anche al tema di attraverso quale canale una persona impara meglio o comunica meglio.Io sono, per esempio, una persona molto visiva e comunico molto bene e leggo molto bene, imparo molto bene con la parola scritta.Questo significa che in video, in collo, con una persona di fianco, la sfoglia dell'attenzione è estremamente bassa.È un mio limite, ho imparato a conoscerlo e a, diciamo, a rivoltarlo per il meglio, però questo fa sì, per esempio, che riesco a fare review per una mezz'ora.Mi è capitato una volta di fare una giornata intera di hyperprogramming con una persona che era di fatto un integralista di extreme programming, del timeboxing, del hyperprogramming, sono arrivato a fine giornata che mi scoppiava la testa.Perché? Perché appunto è una cosa soggettiva, perché ognuno riesce a direzionare l'attenzione e la concentrazione in un modo diverso e matchare la direzione l'attenzione e la concentrazione di due persone o più è molto difficile.Ovviamente, anche lì, l'ennesimo dipende che ti sto dicendo oggi, ma se tu riesci a far combaciare queste cose, crei una sinergia in cui due o più membri di un team lavorano meglio.Quando c'è un mismatch tra queste due cose l'unica cosa che tieni è lo scoglionamento.Sì, tiro dentro per i capelli una passione che condividiamo che è la musica, no? Quando il DJ deve mettere due dischi, deve necessariamente mettere a tempo per cercare di tirar fuori un prodotto che sia un richiame.E non si discosta proprio come c'è la tua moda.È molto simile.Da questo ragionamento.Io ti ho fatto un pacco di domande ti ho tenuto un'oregna ma ti voglio fare l'ultima domanda perché in realtà è una delle cose che mi torna sempre in mente un dubbio al quale non riesco a dare risposta abbiamo detto che le purre quest devono essere più atomiche possibile o quantomeno avere cercare di fargli avere una singola responsabilità tra virgolette andando a prendere a scomodare l'uncle Bob della situazione.Però come si spiega o come si riesce a far convivere questo approccio che è una buona pratica a prescindere con un'altra buona pratica che è la Boy Scout Rule quindi lascia il mondo un pochino più pulito di come l'hai trovato che sono due buonissime pratica ma sembrano confliggenti in questo contesto, no? Sì, capisco perfettamente cosa intendi, nel senso che è vero che le pull request dovrebbero essere atomiche e autocontenute, però se trovi una roba in cui puoi fare un piccolo refactoring e dire "ok, questa roba la lascio un po' meglio di com'era", cosa fai? Non la butti dentro? L'istinto è quello ed è fortissimo e io sono il primo colpevole di questa cosa.La teoria ti dice che dovresti fare due pull request diverse.Di nuovo, se tu riesci a monetizzare le volte in cui io ti dico "dipende", sei un cazzino di arbario.Però dipende, nel senso che, ok, è una pull request da due righe, ci aggiungi due righe di refactoring, non muore nessuno.È una pull request con una feature nuova complicata e ci aggiungi anche il refactoring di cinque classi, meglio di no, quelle le puoi dividere.Però non c'è un numero che ti dica, sai, sia Bitbucket che GitHub ti fanno vedere il numerino di righe verdi che hai aggiunto, di righe rosse che hai tolto.Non c'è una soglia fissa su quei numeri lì.Se sono più 25.000, probabilmente c'è un problema.Nemmeno, nel senso che a me è successo di avere più 25.000 a meno 25.000 perché avevo acceso l'intero.Ok, se mai nel caso non automatico.E l'intero è proprio il caso in cui mandi la pull request e subito scrivi ad Reviewer "oh non ti preoccupare di venire a picchiarmi".Lo spostamento di file, cose di questo tipo, o vai a correggere l'ultima riga dei file, sì sì sì, una cosa comune.Io mi sono dato questa regoletta abbastanza stupida, almeno fammi delle commit divise in modo che possano essere quindi quella è almeno un minimo di condizione sine qua non.Anche quello è debatable, io sono di quella scuola di pensiero lì, ci sono quelli che ti dicono no assolutamente devi fare lo squash, devi commit, devi mandare la pull request con un commit solo.Decidiamolo insieme e poi rimaniamo così, però è una di quelle cose quattro spazi o due, con miti squasciati o con miti divisi, graffa sulla stessa riga o graffa a capo.Beh in fondo ci sono diverse religioni quindi.Esatto.Perché poi si entra nel contesto quasi quasi esoterico quando si affrontano questo tipo di argomenti.Mattia, io che ti posso dire, mi sono divertito un sacco a fare questa chiacchierata con te, stato iper super piacevole e per questo ti ringrazio a nome mio e a nome della della community di Gitbar e di tutti gli ascoltatori.No, sono io che ringrazio te perché è stato super divertente e super piacevole anche per me.Grazie da parte mia e da tutti.Ti chiedo solo l'ultima cosina prima di lasciarti a immaginare tuo figlio visto che ti ha rubato tanto tempo.Ricordaci un attimo i tuoi contatti, quindi dove ti possiamo trovare? Allora diciamo che in giro per l'internet mi si trova come RaiBuzz dappertutto, quindi Facebook, Twitter, LinkedIn, Mixcloud.Sì, diciamo che quello è un po' lo username che uso dappertutto.Sì e poi se si vuole legge gli articoli di Mattia c'è Soundwall.Ho anche Raybaz.it che è dove scrivo le cose un po' più intimiste e meno serie da giornalista musicale.Dimenticavo, questa settimana me ne stavo dimenticando, noi prima di lasciarti l'ultima cosa, promesso.No, no, no, al Paese dei Balocchi ci trovi.Ecco qua, infatti andiamo il Paese dei Balocchi? - Li conduco nel Paese dei Balocchi! - Ah, il Paese dei Balocchi! - Dunque, io...è un consiglio molto variegato, nel senso che...c'è questa casa editrice colana di libri che, secondo me, è la maggior parte degli ascoltori di YouTube, o della gente che scrive codice in generale, conosce che è Pragmatic Programmers.Loro hanno iniziato con il primo libro che si chiama Pragmatic Programmer, che è un classicone.L'ho riletto da un po' di tempo fa e è un filo datato, nel senso che tanti degli esempi che fa li fa con CORBA e RMI, che sono delle cose che erano vecchie quando ho iniziato a programmare io.Però l'idea di fondo è molto, molto timeless.E loro hanno una serie di libri, alcuni più concreti, tipo cioè Pragmatic, nome dello strumento per una quantità di strumenti incredibili, cioè Pragmatic Git, Pragmatic SAS, Pragmatic la qualunque.- Se non sbaglio c'è anche Pragmatic Vim, giusto per far parte del Flame.- Sì, sì, sì, ma non c'è Pragmatic Emacs, va via, start the Flame.Però il mio preferito di tutti si chiama Pragmatic Thinking and Learning, ed è un libro che spiega, parla tantissimo del funzionamento del cervello e della mente e di come fare a ottimizzare i processi di apprendimento e di concentrazione.È un tema che a me piace tantissimo e su cui ho letto e approfondito diverse cose perché in fondo sono un nerd e mi piace imparare le cose e se metti assieme le due cose mi piace ottimizzare come imparo le cose.Studiare i sistemi, no? Esatto, e non c'è sistema più complicato della mente umana, quindi cercare di ottimizzare quel sistema lì è proprio "the ultimate nerd".Questo libro parla esattamente di questo, quindi parla per esempio della differenza tra il sfero destro e sinistro del cervello, di quali sono i processi cognitivi di cui si occupa ognuno dei due e di come attivarne più di uno dei due più dell'altro a seconda di quello che stai facendo che vuoi fare, cose del genere ed è.Tra l'altro è molto bello perché il sottotitolo è "Refactor your wetware", dove "wetware" è appunto il tuo cervello che è bagnato, e ti dice ok, come fare a rifattorizzarlo in modo che funzioni in maniera più elegante.Che figo.Come parlavi, mi è venuta però, tu lo sai, io sono guliardico, mi è venuta un'idiozia ho provato a immaginarmi Darwin che faceva le pure quest l'immagine è stata fantastica.No interessantissimo come suggerimento anche perché è uno di quegli studi diciamo così che in qualche modo si avvicinano molto al nostro mondo guardandolo da un'altra prospettiva cioè completano un po' il nostro punto di vista che spesso ha il paraochi ed è molto molto limitato su quello che facciamo quindi grazie grazie di cuore per questo tuo regalo.Anch'io la seconda puntata che anche io voglio portare un piccolo contributo e c'è un bellissimo libro su l'InnPub scritto da Trisha Ghi spero si chiami così che è un ingegnere a JetBrains e ha scritto un libro, un ebook molto interessante che è "What to look for in a code review" ed è molto molto carino quindi questo è il mio balocco di oggi.Detto questo ti ringrazio infinitamente, davvero grazie di cuore per essere venuto da noi.Grazie davvero a te.e ci tengo a ricordarti che Gitbar che nasce come bar degli sviluppatori dove insieme possiamo farci una birretta e chiacchierare delle cose che più ci piacciono del nostro lavoro che poi è anche una passione anzi prima una passione poi un lavoro quindi Gitbar è anche un po' casa tua è un po' anche tu hai preso la tessera del circolo Arci quindi quando vuoi quando è qualcosa di interessante da raccontarci mi raccomando contateci perché ci fa infinitamente piacere di averti qua.Bello grazie mille, è bello sentirsi a casa.Se non lo fai tu sappi che ti rilompero le scatole io.Quando vuoi.Grazie Mattia, grazie di cuore.Grazie mille a te amore.Gitbar, il circolo dei full stack developer.Una volta a settimana ci troviamo davanti a due birre e con Brain Repo parliamo di linguaggi e tecniche di sviluppo web, di metodologie e di strumenti immancabili nella cassetta degli attrezzi dei Full Stack Dev.[Musica] [Musica] [Musica]
