Bene e buone feste a tutti, anzi non a tutti ma a te, esatto a te, a te che ci ascolti, a te che sei appena entrato in questa splendida community, a te che sei in questa community dai primi giorni della sua nascita, a te che oltre a seguire github settimanalmente hai anche donato qualche birra per supportarci.A te che sei indietro di 30 episodi e non riesci a stare al passo per mancanza di tempo libero.A te che stai sul pezzo e il giovedì mattina ti viene l'orticaria se non esce un nuovo episodio.A te che sei stato ospite in un episodio e da allora hai iniziato a seguirci con passione.A te che sei host o o cost e metti tantissimo impegno in questo splendido podcast.A te che ti viene un infarto ogni volta che apri Telegram e vedi 375 messaggi da leggere nel gruppo.A te che ti leggi tutti i messaggi sul gruppo quotidianamente senza mai scrivere.A te che clicchi sulla freccia in giù per saltare tutti i messaggi non letti per poi e leggere solo gli ultimi tre messaggi.A te che scrivi in continuazione sul gruppo e sei stato anche bannato dal bot per troppa interazione.A te che se non parli di RAL almeno una volta al giorno non riesci a dormire.A te che ci ascolti ma non sei mai entrato nel gruppo telegram.A te che hai consigliato gitbar ad altre persone, ci ha fatto crescere fino a rompere il muro dei mille membri.A te che hai contribuito anche alla realizzazione del nuovo sito web.A te che mentre ascolti un episodio pensi "Ah bello, sta cosa la sapevo pure io".A te che mentre ascolti un episodio pensi "Ah wow, sta cosa non la sapevo, figata".A te che vorresti condividere un qualcosa ma non hai mai avuto il coraggio di farti avanti.A te che sei venuto a condividere un qualcosa anche più di una volta.A te che non rientri in nulla di tutto questo in precedenza.Ecco, è a tutti questi te che io voglio fare i miei migliori auguri di buon Natale e di felice anno nuovo.Andrea e Cheiei CelliBelliDev Super episodio perché questo episodio esce a sorpresa proprio a Natale.In realtà è uscito un episodio qualche giorno fa ma volevamo in qualche modo farvi gli auguri di natale un po' come ogni anno in un modo un po' speciale.Per farlo vogliamo fare una puntata un po' diversa dal dal solito.Beh bando alle ciance allora che resta da fare? Resta semplicemente di iniziare il nostro episodio.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.[Musica] L'episodio di oggi è un episodio molto personale, infatti voglio raccontarvi di una parte della mia storia, una parte della mia esperienza e voglio farlo appunto condividendo con voi alcuni passaggi fondamentali che sono quelli che alla fine mi hanno reso un professionista migliore e voglio iniziare a farlo partendo da questo piccolo oggetto, questo è un D20 di Dungeons & Dragons perché voglio partire da questo D20? Beh, tanti anni fa, forse 20, una roba del genere, andai a un Java User Group, un evento organizzato dal JOOG e incontrai uno che all'epoca mi sembrava uno sviluppatore anziano, in realtà all'epoca era giovanissimo ma parlando di vent'anni fa forse adesso ecco è un po' più adulto e io ero curioso volevo capire come si esplora, come si cresce, come si costruisce una carriera in quella direzione quindi nello sviluppo software.Allora sai mezzo ingenuo mi avvicinai dal tizio e gli chiesi "ma cosa devo fare per costruire una carriera sullo sviluppo software? Cosa devo fare per poi diventare come te?" e sto tizio mise la mano sulla tasca e tirò fuori un diventi, un dado a venti facce.Io lì per lì non avevo capito il senso di questo dado, in fondo avrebbe potuto voler dire milioni di cose ma avrebbe per esempio potuto voler dire a culo dipende dal tiro che fai e lo diventi o meno.Capii il senso di questo dato poi dopo tanti anni però siccome questa storia è molto personale io voglio raccontarvela usando in qualche modo un mio alter ego si chiama Javass Turing ed è il mio personaggio di D&D Dungeons & Dragons ed è un ranger umano caotico buono e andremo a vedere appunto il percorso che Javass fa per diventare un senior engineer e durante questo percorso andremo a vedere alcune caratteristiche che si sviluppano per esempio la la forza, l'intelligenza, la destrezza, la saggezza, la costituzione, il carisma che sono le classiche caratteristiche dei personaggi di D&D.Ma allora bando alle ciance e iniziamo a entrare dentro.Javass è dentro la sua esperienza.[Musica] Javas ha appena lasciato il consiglio dei vecchi, pensava di aver raggiunto il suo traguardo, quello per cui aveva lottato sin da quando era un piccolo cucciolo di uomo ormai è un ranger, il consiglio lo ha decretato tutte le prove alla quale gli anziani lo hanno sottoposto sono stati superate ma adesso davanti alla foresta di Lyria tutto è diverso quella selva fitta lo spaventa a morte è solo e la notte è profonda qua Javas si trova su una foresta che non conosce e affronta la prima sfida che da sviluppatore da engineer abbiamo davanti a noi che è l'ignotto la paura dell'ignotto quel terrore che ci viene quando ci troviamo davanti a una codebase che non conosciamo quando ho iniziato a sviluppare mi sono capitate le cose più impensabili ma negli ultimi anni pur avendo tanti anni di carriera, questa paura è rimasta presente.E mi è capitato davanti a una codebase quella sensazione di sudore sulle mani, blocchetto sulla testa, nodo allo stomaco, come per dire "ma io questo task non lo finirò mai, non riuscirò a chiuderlo, io do le dimissioni".credetemi questa cosa capita spessissimo e sono sicuro che in un qualche momento della nostra vita della vostra vita è capitata anche a voi beh perlomeno a me è capitato più volte e allora in quest'ultimo anno io ho provato a fare un'analisi più o meno scientifica di quello che succede ho provato a vedere l'approccio alla crescita della carriera da un punto di vista psicologico.Mi ha preso un annetto questo studio e voglio raccontarvi un po' di cose che ho imparato.Dicevamo, Javas è nella foresta, questa sensazione, questa paura dell'ignoto.Bene, la paura dell'ignoto è una roba che ho scoperto in psicologia affrontata in modo intenso, nel senso che è pieno di pubblicazioni io ne ho letto diverse e in realtà la paura dell'ignoto ritorna spesso ma per provare ad affrontare la paura dell'ignoto bisogna fare un passo indietro e provare a capire che cos'è l'ignoto.L'ignoto o questa paura dell'ignoto la paura dell'ignoto è un fenomeno conseguente a due elementi due mancanze che abbiamo la prima è la mancanza di predicibilità cioè il fatto che noi non possiamo prevedere quello che accadrà dopo non possiamo prevedere cosa farà quella riga di codice.Il secondo è la mancanza di controllo che è immediatamente conseguente alla mancanza di predecibilità no? Se io non posso prevedere qualcosa come posso averne il controllo? Ecco questi due perni sono i trigger che attivano questa sensazione che ci blocca ci rende improduttivi ed è anche pericolosa se portata a lungo crea ansia ansia cronica e quindi crea delle vere e proprie patologie specie in un contesto in una industria dove noi siamo sottoposti siamo siamo sempre bombardati da stimoli ignoti, da situazioni da gestire dove l'ignoto domina.E allora come facciamo ad affrontare l'ignoto in modo da riappropriarci della predicibilità e del controllo di quello che stiamo facendo? Beh, la letteratura scientifica dice chiaramente che quello che noi dobbiamo fare è provare a mapparlo questo ignoto, provare a in qualche modo identificare cos'è in modo che insomma se noi riusciamo a identificarlo è un po' meno ignoto no? e quindi ci spaventa meno.Ma andando a fondo negli studi ho scoperto che in realtà gli ignoto non è uno solo ma sono diversi io ne ho identificato quattro e si distinguono appunto per particolari caratteristiche il primo che io ho chiamato cose che noi conosciamo ma da verificare quindi nouns to be verified sono tutte le cose che davanti a una codebase ignota che non conosciamo riconosciamo come simili come qualcosa di familiare queste queste intuizioni sono guidate dal concetto di consistenza quindi vuol dire che quel pattern, quell'elemento, occhio che poi la parola pattern ritornerà tra un po', quell'elemento riusciamo a riconoscerlo come consistente con qualcos'altro qualcosa che noi abbiamo visto su altre codebase, metti che io sto sviluppando su fastify il pattern dei plugin o dei decorator posso averlo visto in qualche altro framework o in un altro progetto che utilizza fastify quindi un elemento che un po mira sicura questa consistenza può essere interna o esterna a seconda del fatto che noi stiamo lavorando, noi riconosciamo questo pattern come elemento già presente all'interno della codebase o elemento presente in altre codebase.E allora quello che noi dobbiamo fare quando abbiamo dei "nones to be verified" quindi delle cose che noi conosciamo ma che dobbiamo necessariamente verificare e imparare a chiedere.Perché? Perché dietro quell'elemento, quel pattern che noi riconosciamo come consistente con qualcos'altro, noi stiamo intuendo un significato, ma spesse volte quella consistenza non esiste per cui in realtà potrebbe voler dire altro.Immaginiamo una parola di dominio.Questa cosa capita a me, è capitata spessissimo.Un altro tipo di unknowns, io ripeterò costantemente unknowns anche se il mio professore d'inglese mi piglia schiaffi per questa cosa, abbiate pazienza ormai sono anni che mi conoscete quindi ahimè mi scuserete, però abbiamo i nones e non unknowns.Cosa sono? Sono le cose che noi sappiamo di non sapere.Esplorando una codebase noi vediamo un pezzo di codice che non capiamo che cipa faccia, che cosa ci faccia là, qual è il suo compito e quello è qualcosa di sconosciuto però noi sappiamo che quell'elemento è sconosciuto quindi abbiamo tutti gli strumenti per andare a scavare a fondo e trovare il significato.Attenzione è che anche qua però il rischio qual è? Il rischio è quello di cadere nei famosi rabbit hole, quindi andare in fondo, scavare, scavare, scavare, scavare, alla ricerca di questo significato e poi perdersi in questa ricerca così profonda.e soprattutto se noi scaviamo e perdiamo poi il nostro filo abbiamo un carico di informazioni enorme da gestire subito dopo quindi questo crea un carico cognitivo enorme che poi dovremmo andare a gestire per cui sì dobbiamo approfondire ma dobbiamo anche capire il momento in cui questo scavare a fondo non è più produttivo per l'obiettivo che ci siamo posti perché il pragmatismo deve guidare il nostro percorso.Poi abbiamo gli unknowns, nones, che è tutto ciò che noi sappiamo del progetto ma che non sappiamo di sapere, sembra una uno scioglilingua, cioè tutte quelle situazioni tale per cui noi stiamo esplorando un pezzo di un progetto non capiamo quel pezzo, chiediamo a un collega o leggiamo nella documentazione e poi diciamo "cazzo ma è solo questo? ma allora lo sconoscevo" ecco questo è un po più stronzo si manifesta poi sotto forma di epifania alla James Joyce no? però è qualcosa che dici "ah" e rimani stupito ma in fondo tu non sai di sapere quindi sono elementi che già in il tuo bagaglio e tra un po andremo a vedere come far triggerare l'apertura di questi elementi nascosti.Per finire poi con gli unknowns più difficili, quelli più complicati da aprire, da scoprire che sono gli unknown, ciò che non sappiamo di non sapere.Ciò che non sappiamo di non sapere a meno che abbiamo qualcuno che ci metta quella pulce sull'orecchio che ci dia quello stimolo è veramente difficile gestire e solitamente vengono da il concetto di obscurity.Che cos'è l'obscurity? L'obscurity è quella condizione che si ha quando informazioni importanti non sono ovvie.questo concetto è spiegato molto bene in un libro che se mi ricordo bene era "A philosophy of software design" di John Osterhout sicuramente non si pronuncia così ma l'abbiamo ci abbiamo citato più volte all'interno del nostro podcast, quindi buttateci un occhio e soprattutto avete ancora qualche giorno di vacanza, prendeteli in mano perché è uno di quei libri che cambia la vita.Io l'ho sentito in un episodio del podcast di Francesco Sciuti mentre parlava con Salvatore Sanfilippo ed è uno di quei libri che veramente mi ha cambiato il punto di vista del lavoro che faccio.Vi dicevo quindi gli unknown unknown sono quelle informazioni che non sappiamo di non sapere che vengono dal concetto di oscurità, obscurity, quindi informazioni ovvie che in realtà non sono poi così ovvie nel codice, ma abbiamo degli indizi Per identificare queste parti abbiamo una serie di red flag, una di queste, forse quella più importante, è la documentazione.Cioè, se un progetto ha una copertura di documentazione molto intensiva in alcune parti, un progetto, ha tanta documentazione su uno dei moduli per esempio, noi abbiamo un enorme red flag che ci dice "Ehi, guarda che in questa parte di codice potrebbero esserci informazioni importanti non ovvie e nascoste".Naturalmente talvolta è sufficiente leggere gli EDR, le PR, le ISSU anche per capire un po' che tipo di informazioni e dove sono.Una volta che abbiamo però identificato i tipi di ignoto, dobbiamo in qualche modo trasformare il nostro ruolo da un ruolo esplorativo a un ruolo proattivo, cioè dobbiamo mettere in piedi la strategia di esplorazione della Codebase e per farlo attingo ad alcuni concetti che ormai sono diventati parte di me che porto nel podcast in modo implicito, nascosto, ma che dalla mia attività di giornalista mi porto appresso proprio perché sono la base di quell'attività.Datemi un secondo un sorso di caffè.E la strategia di cui voglio parlare è la strategia delle 5W1H che sono le classiche domandine che noi ci poniamo da quando facciamo la terza elementare quando facciamo i temini no? chi, come, cosa, quando, perché? ce l'chiediamo sempre ecco se noi facessimo utilizzassimo la stessa strategia di maestra Pina nell'esplorazione del nostro codice beh riusciremmo davvero a esplorare il nostro codice riducendo tantissimo la paura dell'ignoto.La prima domanda che dobbiamo porci è cosa e quando? What and where? Da dove partire? Cosa prendere in mano? Questa domanda dobbiamo rispondere appena noi vediamo una codebase.Ho chiesto a tanti sviluppatori anche molto skillati molto più bravi di me, Temper Programmer, rockstar developer, super senior ninja e alla fine però tutti mi dicono "Boo" in realtà qualcuno mi ha dato delle risposte interessanti alcuni dicono "parti dal main" io con gli anni ho imparato a partire dal package.json nel caso in cui sto sviluppando in javascript o in typescript o dal file delle delle dipendenze del linguaggio che utilizzate.Perché io ho iniziato a partire da là? Perché in realtà è vero che la porta d'ingresso della nostra applicazione è il main però è anche vero che se noi partiamo dal file del package manager noi abbiamo la possibilità in realtà di riconoscere degli elementi che possono essere per esempio delle librerie che noi abbiamo utilizzato prima e che sono utilizzate anche in questo progetto, dei framework che ritornano che abbiamo già visto.Quindi sono elementi che noi riconosciamo come familiari e riconoscendoli come familiari ci spaventano di meno.dobbiamo tenere presente che la paura dell'ignoto è una condizione, la ripulsione verso l'ignoto è una condizione che ci viene dalla note dei tempi e che in qualche modo ci serve per difenderci appunto in una situazione di sopravvivenza e che spesso insomma degenera in antisemitismo e razzismo è è la stessa matrice, per cui riconoscere degli elementi simili ci porta a muoverci con un pochino più di tranquillità all'interno della codebase.Però in realtà quello di partire dal file di package manager può essere una ricetta ma può anche non essere adatta in tutte le situazioni.Perché? Perché fondamentalmente il nostro codice non è un elemento lineare, non è un saggio che tu leggi dall'inizio alla fine o un qualunque testo che tu prendi e vai al capitolo e leggi, ma è una rete intricata di relazioni, dipendenze, per cui non possiamo esplorare il codice in modo lineare.Abbiamo bisogno di una strategia che ci permetta di muoverci in questo intricato ammasso di fili e anche se il codice è fatto bene un po spaghetti lo possiamo visualizzare nella nostra mente.E allora un modo interessante in realtà per esplorare il codice viene da uno stimolo che mi ha dato Leo Rossi, è uno stimolo molto interessante e parte dal concetto che in realtà il nostro codice è una città.Anche la città è un'intricata via, un'intricata ammasso di vie, viuzze, sentieri, veicoli, piazze.E come esploriamo una città nel momento in cui noi arriviamo.Beh, l'esplorazione della città avviene partendo da un punto a caso, il punto dove ci troviamo e in modo, insomma, arraggera, noi andiamo a esplorare prima ciò che abbiamo vicino, ci creiamo dei punti di riferimento, poi ci allontaniamo un pochino di più e costruiamo la nostra fitta rete di punti di riferimento finché dopo x tempo non abbiamo mappato nella nostra mente tutta la città e se facessimo proprio questo quando esploriamo il codice e se proprio ci ponessimo come ci poniamo quando esploriamo la città ebbè probabilmente anche l'attitudine che abbiamo nell'esplorare la codebase è completamente diversa.Un altro elemento sempre del what e where che ci permette di avere quella tranquillità nell'affrontare l'ignoto quindi a battere la paura dell'ignoto è quello di conoscere bene gli strumenti che si usano.Mio padre ha per tanti anni fatto il meccanico e mi diceva sempre "sai Mauro io riesco a riconoscere un meccanico da come impugna la chiave inglese io ti so dire se uno scarpone o se è un bravo meccanico.Noi per tanti anni ci siamo detti o perlomeno io mi sono ripetuto "va non importa l'editor che usi, l'importante il codice che scrivi, forse non è così importante abbiamo insomma ho provato a convincermi ed era abbastanza convincente del fatto che alla fine l'editor era un elemento forse quello meno importante no era per esempio molto più importante il framework ma cosa succede se attorno a te è tutto sconosciuto e hai bisogno di qualcosa di familiare una presenza che tu conosci che sai gestire ecco l'editor è la tua lancia, la tua arma per muoverti nell'ignoto e per farlo la devi conoscere bene.Questa cosa l'ho capita dopo tanti anni di prese per il culo da Kiusa Wim.Kiusa Wim ha riconosciuto che l'editore è la propria lancia e in realtà conoscere gli strumenti ci permette appunto di muoverci con quella tranquillità o almeno riducendo il carico cognitivo perché conosciamo una serie di trucchetti, tricchini nell'usare l'editor che ci permettono di muoverci agevolmente anche su ciò che non conosciamo.Gli strumenti solitamente sono due io adesso vi ho introdotto l'editor ma git è un altro strumento fondamentale quindi dobbiamo fermarci un attimo a conoscere i nostri editor.Io da un po' sto usando Vim ma il mio toolset, il mio kit per Vim non è all'altezza della mia conoscenza di Visual Studio Code quindi vi racconterò due cosine rapide di Visual Studio Code ma sappiate che queste funzionalità di cui vi parlo ci sono in praticamente tutti gli editor, tutti gli IDE, l'importante è sapere che ci sono e come arrivarci.La funzionalità principe nel momento in cui si esplora una codebase è senza dubbio la ricerca.Abbiamo detto che le codebase non sono un elemento lineare, per cui come ci muoviamo in questo grafo di relazioni intricate? Beh lo strumento di ricerca è uno, per farlo dobbiamo conoscerlo molto bene e ci sono alcuni elementi importanti che possiamo utilizzare che ci permettono di saltare da un punto all'altro del nostro codice senza doverci muovere manualmente e quindi limitando l'impatto di quella mole di informazioni che verrebbe nel transito del passaggio da un punto all'altro.La cosa importante quando si esplora una codebase è mettere a mente, tenere a mente, sono solo le informazioni che contano.Quindi ridurre tutto il rumore.Se noi siamo in grado di ottimizzare la serie di informazioni che noi, alla quale noi siamo sottoposti.Nello spostarci dal punto A al punto B vuol dire che noi stiamo ci stiamo muovendo all'interno del codice in modo più fluido più scorrevole ok più liscio per farlo per esempio la ricerca partendo da una selezione di testo quello che noi facciamo comunemente con un command shift F su Visual Studio Code ci permette di saltare da un punto all'altro della nostra code base senza perdereci appunto in caterve di informazioni.Un altro tool che ho trovato utilissimo partendo da una ricerca fatta è quello del elemento precedente e successivo sembra una banalità no saltare all'elemento precedente dei risultati o all'elemento successivo modo da vederne i dettagli ma calcando f4 su video studio code rapidamente io mi muovo tra un risultato e l'altro cercando appunto di ridurre il tempo e la mole di informazioni in pochissimi mille secondi quindi in realtà alla fine arrivo all'informazione che mi serve senza perdermi Un'altra funzione che non conoscevo, fighissima, e cercatela se usate Visual Studio Code cercatela sono sicuro che altri tool, per esempio so che Sublime Text ha qualcosa del genere, ce l'hanno, è praticamente se noi andiamo nei risultati di ricerca di Visual Studio Code e clicchiamo apri nell'editor nella lista dei risultati ricerca avremo una pagina di editor così come quelle dove scriviamo il codice con i vari blocchetti dei risultati di ricerca dei vari file ma la cosa veramente figa è che possiamo aumentare o ridurre le linee di contesto quindi quante linee prima del immaginiamo che di aver cercato un particolare nome di variabile la variabile pippo ok e avrò tre file solitamente i risultati ricerca mi mostrano la riga dove c'è del file A, del file B e del file C.Ma che informazioni ho? Io ho bisogno di più contesto, ecco c'è questa funzione nel search editor di Visual Studio Code che ci permette di inserire il numero di righe prima e dopo che vogliamo vedere del nostro risultato quindi di questi tre file non vedrò solo una riga per file ma vedrò che ne so 5-6 righe in modo da mettere in un contesto quella variabile PIPO e capirne di più.Questo è fondamentale quando si esplora la code base così com'è fondamentale sapere che le ricerche sono le nostre pietre miliari cioè sono quegli elementi che ci aiutano a identificare dove siamo è una cosa che possiamo fare con visual studio code è quella di salvare i risultati di ricerca se io faccio mela s comand s mela sa un po' di anni 90, se io salvo i risultati di ricerca a quel punto in qualunque momento della mia esplorazione posso risaltare rapidamente a quei risultati, quindi diventano un punto che ci aiuta a orientarci e ci aiuta anche a scambiarli con altre persone che lavorano con noi se non lavoriamo da soli.A questo punto però la domanda viene spontanea, ma se io lavoro in un contesto aziendale grande dove ci sono 70 repo e una consistenza condivisa tra i repository quindi devo cercare qualcosa in modo orizzontale tra tutti i repository, beh ci sono tool come source graph che ci permettono di fare proprio questo.Nel caso di source graph è un tool a pagamento ma è sufficiente utilizzare la ricerca avanzata di github che pochissimi conoscono per andare a inserire quegli elementi dettagliati di ricerca su più repository buttateci un occhio perché in realtà la ricerca avanzata di github è una una vera figata quindi arrivati a questo appunto abbiamo in qualche modo risposto alla domanda "what and where" forse ho aperto una parentesi enorme e ci siamo persi ma ritorniamo appunto alle nostre 5w1h la domanda alla quale voglio rispondere adesso è "how" come? la cosa che ripeto sempre è per capire il come fai girare il tuo codice as early as possible il prima possibile sempre il prima possibile metti debugger breakpoint del debugger e console.log nei punti dove vuoi vedere il flow in modo che questi console.log e questi breakpoint diventino i punti che ti aiutano a orientarti.Io in realtà nell'ultimo periodo che ho utilizzato Visual Studio Code ho installato un plugin interessante che era un plugin di bookmarking quindi mi permetteva di mettere di segnalibro in alcune parti specifiche del codice con anche una piccola nota e devo dire che l'ho trovato molto molto interessante perché poi avere il segnalibro a destra mi permetteva di saltare rapidamente da una parte all'altra.Comunque appunto per capire appunto come funziona il nostro codice dobbiamo farlo girare il prima possibile.ma se non possiamo farlo girare a tutti è capitato di dover lavorare su una codebase dove al massimo si riusciva a far girare i test no? perché è complicata perché è un'architettura allucinante perché qua e la...non ce lo stiamo a spiegare perché fondamentalmente talvolta l'architettura è fatta di merda che non può essere replicata sulla macchina però per fare questo cosa facciamo? Per fare questo abbiamo un altro strumento molto interessante sempre dell'editor che ci permette di saltare alla definizione della funzione andare all'implementazione andare alle reference ma soprattutto una cosa che mi ha sconvolto l'esistenza è quella di andare alla call hierarchy, alla gerarchia delle chiamate, cioè nel vedere un albero che ti fa vedere chi chiama cosa, per cui partendo dalla funzione pippo tu vedi chi ha chiamato pippo e poi vedi chi ha chiamato chi ha chiamato pippo e così via, in modo da capire bene dove fluisce informazione, per cui se con il console io vedo il dato che passa solitamente io lo uso per vedere il dato che passa quindi il contenuto dei dati le call hierarchy le utilizzo per vedere diciamo la struttura il percorso che questo dato fa pochissimi la usano a me ha cambiato completamente la vita e abbiamo anche risposto a AU per cui ciò ci manca è rispondere alla domanda "who and when" a questa domanda solitamente ci rispondiamo con una sorta di guessing name, l'indovina chi, non so se vi ricordate, tra l'altro ho scoperto durante questo percorso che ho fatto proprio per studiare gli impatti psicologici dell'esplorazione della codebase, ho scoperto che esiste un indovina chi basato sui personaggi di The Office ed è bellissimo cercatelo perché può essere un regalo di post natale bellissimo comunque capire chi è quando ci permette di trovare chi pingare cioè quelle persone a cui andare a rompere le scatole per chiedere maggiori informazioni appena appunto cercare di allontanare il più possibile l'obscurity da noi.Per farlo abbiamo degli strumenti, sono due fondamentalmente, anzi uno, l'altro è una visualizzazione ed è semplicemente Git.Git ci dà tutti gli elementi per poterci muoverci, muovere agilmente.C'è da dire che però se noi se noi avessimo una serie di funzionalità ben integrate nel nostro editor per muoverci rapidamente e non dover spostarci sulla linea di comando ogni volta ci permetterebbe un cambio di contesto, un context switch minore un insieme di context switch minore e quindi riusciremo a ridurre e gestirebbe bene il caricò cognitivo in fase di esplorazione Per farlo su Visual Studio Code, ma ripeto, ci sono strumenti diversi anche per gli altri editor che coprono questo tipo di esigenze, c'è GitLens.Cosa ci permette di fare? Passando su una riga di codi ci permette di vedere chi e quando ha scritto questa riga, il classico GitBlame, no? Ma ci permette anche di vedere cosa è cambiato nella riga, cosa ha cambiato.Ed è La stessa cosa, ripeto, possiamo farla direttamente con un comando git blame, passare il numero di riga e il file e a quel punto vediamo chi è il responsabile di quella riga e chi andare a contattare se non capiamo.Tra l'altro blame è, penso, il nome più brutto che si poteva dare per un comando ma sappiamo che c'era linus dorvald ed è la persona meno, sotto io nel team di sviluppo è della persona meno politically correct del mondo quindi ci sta va bene.Un altro strumento interessante è senza dubbio il Gitlog che con gli opportuni parametri ci permette di avere altrettante informazioni.Ehm...Ma...una funzione che ho trovato veramente game changer nell'esplorazione della codebase e andare a vedere l'history dei cambi di un certo file.Questo perché in realtà spesso tutti gli elementi che possiamo identificare come obscurity sono arrivati a uno stato di obscurity, non sono partiti da uno stato di obscurity.Adesso sto generalizzando però solitamente nella mia esperienza è è successo così no? Le cose partono, si evolvono e si incasinano col tempo.Se noi riusciamo a percorrere, a fare lo stesso percorso che il codice ha preso per evolversi e incasinarsi, noi siamo in grado di comprenderne il significato, il senso, l'obiettivo che questo pezzo di codice che poi si è incasinato col tempo voleva raggiungere.Quindi avere la possibilità di leggere la git history direttamente dall'editor magari cliccando su un certo commit e vedendo le diff di quel file in quelle righe e muovendosi rapidamente tra i vari commit, beh veramente credetemi cambia tutto perché si capisce appunto il percorso che la codebase ha fatto nell'evolversi oltre che a identificare appunto la persona eventualmente da contattare e la risposta appunto è il why.Dare un perché alle cose è sempre molto difficile quindi noi vediamo che magari dalla git history le cose sono cambiate però capire il perché sono cambiate perché sono andate in quella direzione diventa veramente complicato ma possiamo farlo possiamo farlo se il progetto è stato pensato utilizzando in modo decente e non criminale il concetto di PR ed issue se noi andiamo infatti a esplorare le PR e le issue Noi vediamo le discussioni che hanno portato a quella modifica e quindi ne capiamo il senso profondo.Ma anche qua però spostarci su github, cercare il file, andare a vedere quel punto preciso nella storia diventa un bordello.Gitlens su Visual Studio Code ci permette con davvero un click, e credetemi un click partendo dal codice, saltare direttamente sulla issue o sulla pull request e vedere le discussioni all'interno ed è veramente game changer e soprattutto all'interno delle discussioni vediamo tutta una serie di persone coinvolte in queste discussioni che sono una serie di persone potenzialmente utili per chiedere aiuto.Ebbene sì, li ho contati, sono praticamente 20 anni che scrivo codice e in questi 20 anni una cosa ho capito chiara, che un senior ingegnere non è ciò che chi sa tanto, perché in realtà tutti i geni, tutti i senior, tutte le persone che ho reputato veramente bravi nella mia vita mi hanno sempre mostrato delle carenze in termini di conoscenza per cui mi son chiesto ma allora chi è il senior engineer? La seniority cosa ti dà in più? La risposta che mi son dato poi con col tempo è che in realtà stiamo parlando sempre di ignoto e la chiave sta là cioè un senior un engineer è chi sa convertire in modo veloce ed efficiente gli non annunce quindi ciò che non sa di non sapere in un annunce in ciò che sa di non sapere convertendo ciò che non sa di non sapere quindi l'obscurity in ciò che sa di non sapere ha la possibilità di decidere in modo senziente dove approfondire quali argomenti prendere e analizzare nel dettaglio.Questa capacità di non farsi prendere dal panico davanti a ciò che non sa di non sapere è la chiave principale di tutte le persone con tanta esperienza.Ma come si fa questa trasformazione tra ciò che non sa di non sapere in ciò che so di non sapere lo si fa semplicemente chiedendo agli altri e mi è capitato tantissime volte di vedere richieste d'aiuto proprio sbagliate no? tipo aiuto la navigazione di next.js non sta funzionando ma cosa vuol dire? La prima cosa che dobbiamo andare a fare è saper chiedere aiuto.Io negli anni ho costruito diciamo il mio piccolo framework personale per chiedere aiuto e che si basa su rispondere a tre domande principali.Cosa voglio sapere? E devo avere chiaro in mente cosa voglio sapere.Con chi sto parlando a chi sto chiedendo e anche qua devo individuare chiara la persona che poi mi risponderà in modo da ridurre il rumore al massimo quando poi sto prendendo la risposta.E dove sono e come ci sono arrivato? Questa domanda in realtà mi permette di dare al mio interlocutore il contesto cioè io so cosa voglio sapere ma come ci sono arrivato dove mi trovo lo devo comunicare con estrema chiarezza in modo da portare il mio interlocutore in quel punto preciso ponendomi queste tre domande in realtà quello che sto facendo è semplicemente rubber ducking quindi sto chiarendo a me stesso i dubbi che ho e spesso mi vorrebbe da citare un film famoso "la risposta sta dentro di noi" spesso non abbiamo neanche bisogno di contattare qualcuno ed ecco perché noi queste domande ce le dobbiamo fare prima di contattare qualcuno, fermarci, chiarirci le idee, trovarci queste tre maledette semplicissime domande.Cosa voglio sapere, con chi sto parlando e come ci sono arrivato e come ci posso portare in mente il locutore.Una volta che io ho chiarito questi tre punti e non sono riuscito a darmi una risposta, beh a quel punto io ho le mie cinque regolette che mi permettono di raggiungere il mio obiettivo.Cosa vuol dire? Quando si chiede qualcosa si interagisce con altri esseri umani e noi diciamo non siamo gli esseri umani più, perlomeno io parlo per me, esseri umano più empatico del mondo per cui ho capito col tempo che esiste un galateo nel chiedere domande galateo non tanto per essere eleganti ma proprio per ottenere delle risposte utili e l'ho capito ahimè a mie spese dopo tante figure di merda e tante energie spese senza poi avere un risultato.La prima cosa che poi è un elemento che vedo ricorrere spesso all'interno del nostro gruppo telegram è il "don't ask to ask" chiedere frasi del tipo "posso chiedervi una cosa e attendere risposta fanno sì che si interrompa il flusso di lavoro del mio interlocutore che deve fermare quello che sta facendo, passare al programma di chat, di comunicazione, email, slack, telegram, quello che volete, leggere quel messaggio che non ha alcun valore e decidere se rispondere e attendere la domanda.Questo crea questo singhiozza, questa rottura di balle che ci fa partire già svantaggiati, cioè il nostro interlocutore ha già perso del tempo ancora prima che noi gli poniamo la domanda.Capite che il costo è alto.Un altro elemento è ricorrente che poi è la mia seconda regola d'oro, è non essere pigro quindi quando si scrive un messaggio io me lo devo rileggere correggere la grammatica correggere lo spelling se il messaggio supporta markdown mettere i back tick in modo che il codice venga formatato e che sia più facile da leggere per mi interlocutore perché se io semplifico la lettura della mia richiesta.Ho la possibilità che il mio interlocutore sia più propenso per darmi una risposta se invece scrivo di merda butto codice "Mean Times New Roman" adesso vabbè sto esagerando però alla fine mio interlocutore dice "chi me lo fa fare a perdere del tempo per rispondere a questa roba qua?" quindi non è essere eleganti ma è cercare l'outcome, cercare la risposta, il risultato Una cosa che è stata poi difficilissima e che è la mia terza regola aurea è non aspettare solo confirmation, solo conferme.Solitamente quando noi chiediamo aiuto una mezza idea o comunque delle potenziali vie da percorrere ce le abbiamo o intuizioni qualcuna talvolta ce le abbiamo.Cosa succede? Che noi a quel punto ci attendiamo una conferma.e se la conferma non ci arriva non siamo soddisfatti oppure se la conferma ci arriva o l'indicazione importante ci arriva la riconosciamo come tale e poi subito dopo chiudiamo le orecchie e tutto quello che il nostro interlocutore ci dirà dopo fluisce via come un torrente verso il mare ma noi abbiamo sempre un problema quello della noun, un known cioè delle cose che non sappiamo di non sapere.Se noi otteniamo le orecchie aperte anche dopo che abbiamo ricevuto la nostra main information abbiamo la possibilità di ottenere una serie di indizi che probabilmente quasi sicuramente non avremmo valutato proprio per colpa del fatto che la codebase a noi c'è sconosciuta e che ci permettono di trasformare quegli annunci in qualcosa che noi sappiamo di non sapere o sappiamo di sapere.Si vede che cambia completamente l'approccio ed è quello che il Signor fa, spesse volte fa.Quindi questa terza regola d'oro nel modo di porsi con gli altri è stata forse una di quelle più difficili da superare però che veramente ha generato un valore allucinante.Altro elemento non porsi in modo passivo aggressivo questa cosa l'ho vista spesso nell'open source atteggiamenti del tipo mi fissate i bug o mi rispondete a questa domanda altrimenti io non uso più questo tool, capita tutti i giorni in realtà non è il modo migliore di porsi se si vuole raggiungere un risultato così come non è il modo migliore di porsi iniziando un messaggio con urgente o aiuto perché la cosa è urgente sì ma è urgente per me non per il mio interlocutore quindi un modo un po' pressante per per farlo.Il galateo vuole anche che insomma quando noi riceviamo delle informazioni le condividiamo nostra volta in modo da creare una rete proficua importante quindi questa è una cosa importante da fare.L'ultimo punto in realtà delle mie cinque regolette su come chiedere agli altri è anche questo, è stato molto doloroso, come dirlo? Noi solitamente chiediamo aiuto talvolta ci poniamo nel chiedere una soluzione.Stiamo chiedendo aiuto, non stiamo chiedendo la soluzione al nostro problema.La soluzione al nostro problema deve venire da noi.L'aiuto sono una serie di informazioni.Tutte le volte che all'interno di una community si individua una richiedente soluzione finita, possibilmente anche iscritta in un contesto che non si è condiviso, quella persona viene marchiata a fuoco dal bollino del rompiballe che non si vuole nella community.Perché? Perché bisogna, il tempo del nostro interlocutore ha un valore e noi dobbiamo almeno mettercene il doppio di tempo.Perché? Perché il problema è il nostro.Per cui dobbiamo sempre ricordarci che noi stiamo chiedendo aiuto, non la soluzione, è stata anche questa molto molto dolorosa da digerire nel tempo.Così come è stato complesso in realtà la fase immediatamente successiva alle risposte, cioè il gestire l'impatto emotivo della risposta.Noi sappiamo, i nostri interlocutori spessissime volte hanno un problema, sono poco empatici e le risposte talvolta sono abbastanza tranchant.Quindi una cosa che ho imparato a mie spese è quella di non interpretare una risposta come un giudizio di tipo personale, ma cercare sempre di tirar fuori dalla risposta il valore anche se in modo apparente il valore non c'è.faccio un esempio quante volte vi è capitato di ricevere come risposta read the fucking manual or search in the fucking web? a me gozziliardi di volte ma allora come posso trasformare questa risposta di merda in qualcosa di produttivo? beh col tempo ho imparato in realtà e l'ho fatto anche con Rust davvero poco tempo fa, di rispondere a questa risposta al posto di andare in un angolo a piangere e incazzarmi con una bestia, di rispondere in questa risposta in modo a questa risposta in modo pragmatico con un'altra domanda domanda del tipo ok tu mi stai dicendo che devo leggere il cazzo di manuale però c'è qualche topic specifico vicino al mio problema, al problema che voglio risolvere, qualche aria, quale parte per esempio del linguaggio devo leggere e soprattutto perché devo approfondire questa parte, qual è il mio luck che hai individuato? Questa cosa fa sì che noi vero esponiamo le nostre vulnerabilità, ma dimostriamo al nostro interlocutore di essere coscienti delle nostre vulnerabilità e di in qualche modo volerci impegnare.Il mostrare che noi ci vogliamo impegnare fa capire al nostro interlocutore che noi non stiamo cercando una soluzione ma stiamo cercando aiuto e che siamo disposti a mettere tutti noi stessi alla ricerca di aiuto.Per cui dice ok questo è veramente sta facendo il culo per risolvere la situazione, ma sì, ma diamogli una mano.E quelle poche informazioni che ti dicono perché devi andare ad approfondire e qual è la causa scattenante, qual è la mancanza che devi colmare, sono importantissime nella costruzione di una carriera.Perché talvolta è più capire dove sono i nostri lack che conoscere le cose che fa la differenza e ritorniamo sempre al discorso no del del senior e degli unknown unknowns, unknowns no, e ritorniamo sempre là alla fine è un circolo che che ripercorre la stessa via a questo punto però dobbiamo capire a chi dobbiamo chiedere e ci sono fondamentalmente 2/3 destinatari della nostra richiesta.Il primo elemento è il one to one, quindi dobbiamo identificare una persona specifica e chiedere a questa persona.Naturalmente questo tipo di richiesta è veramente costoso perché sto allocando tempo mio e tempo di quella persona, solo per me fondamentalmente, ma ha una banda larghissima perché in realtà possiamo attingere a un gozziliardo di informazioni con il limite, l'ulteriore limite che in realtà è super limitato in scala, cioè non scala sta roba.Il mio interlocutore è sempre uno, ci sono 70 mauro che gli chiedono informazioni sta roba si impalla.Essendo così limitata noi abbiamo la responsabilità lo ripeto due volte perché è importantissimo abbiamo la responsabilità di write it down le informazioni che riceviamo, andare scriverle, condividerle perché? Perché appunto fa sì che quest'elemento limitate in scala a scali, quindi fa sì che domani mattina al posto di rompere le balle al mio collega io c'ho qualcuno che gliele ha già rotte prima e l'ha scritto sotto e velocizzo il tempo che mi serve per arrivare all'informazione e creo una sorta di circolo virtuoso per lo scambio di informazioni.Possiamo anche chiedere a più persone, che è il nostro secondo tipo di interlocutore, quindi un tipo di comunicazione one to many.Questo modo di comunicare è molto più veloce, come è ovvio che sia, ed è anche abbastanza facile trovare all'interno appunto di più persone chi detiene le informazioni, chi è gatekeeper di quell'informazione.Immaginiamo un gruppo slack o un gruppo telegram dove c'è qualcun esperto di una funzione x di rast, è facile buttare giù il messaggio ben scritto e trovare qualcuno che quella funzionalità di rast la conosce.Qual è il problema? Che per quanto sia facile raggiungere chi detiene l'informazione è altrettanto facile ricevere indietro una grande quantità di rumore.Essendoci più persone le incomprensioni alla domanda o le tangenti che partono generano un rapporto segnale rumore molto basso e questo fa sì appunto che dobbiamo investire energia nel andare a distillare l'informazione, ma se noi riusciamo appunto a farlo con con abilità ecco è abbastanza funzionale per raggiungimento del nostro scopo.L'ultimo punto che un po' non è un interlocutore ma si presta bene a questo tipo di ragionamento è lo stare nel giro, stay in the loop, quindi se noi stiamo seguendo un progetto, stiamo esplorando una codebase nuova, leggere feature, PR, issue, eventuali gruppi di discord, telegram, slack, le news, il blog della piattaforma della nostra codebase che stiamo esplorando ecco dobbiamo conoscerli a meno di tutto perché sono i punti dove abbiamo un sacco di informazioni e ci permettono di non perdere dei tempi appunto nel chiedere alle persone dove i tempi si dilattano.A questo punto Javass il nostro ranger umano caotico buono ha fatto il suo percorso nell'esplorazione dell'ignoto, ha aumentato la sua forza, la sua saggezza, la sua destrezza e il suo carisma perché? perché ha imparato a cercare dentro le codebase, ha imparato a salvare le ricerche e utilizzarle come punto di riferimento, ha capito come il il codice funziona e perché e soprattutto sa come trovare l'autore di quel pezzo di codice e come chiedere informazioni ma i problemi di javas sono finiti quindi no tante erano le informazioni che coglieva nell'entrecata foresta tante da riempire gli occhi e la testa tenendoli immobili lì fermo al centro della piccola radura.Ogni dettaglio era diventato una voce nella sua testa, voce che sbraitava con le altre creando un assordante frastuono mentre in realtà tutto taceva.Era forse l'inizio della follia? noi pensavamo che diciamo i problemi di javas fossero finiti con l'avere imparato ad affrontare l'ignoto ma così non è i problemi di javas non sono finiti javas in questo momento è prossimo alla follia perché perché ha raccolto tantissime informazioni troppe informazioni molti di più di quante in realtà il suo cervello possa processare.E' qua che in realtà emerge un concetto importante, cioè la differenza tra ciò che sappiamo e ciò che abbiamo compreso.Ciò che sappiamo è ciò che in qualche modo entra in contatto con noi, noi vediamo qualcosa, noi vediamo la programmazione funzionale, ok? e quindi sappiamo, ma capire una cosa vuol dire dividere il concetto, scindere il concetto in parti essenziali e farli diventare parti di te, vuol dire nel caso della programmazione funzionale di essere diventato un tutt'uno coi concetti della teoria degli insiemi per esempio ed esiste una forte differenza ma allora quello che succede nella trasformazione tra ciò che conosciamo in ciò che comprendiamo si identifica attraverso un processo che genera del carico cognitivo.Il carico cognitivo è l'insieme appunto di sforzi che noi facciamo per attivare questa trasformazione e può essere definito in tre tipi fondamentali.In realtà ho letto una marea di paper però diciamo il paper più interessante sul carico cognitivo i paper più interessanti sul carico cognitivo sono quelli di John Sonsweller e di Miller, sono paper che risalgono agli anni 50, quindi neanche troppo recenti, e che in qualche modo provano a dare una forma a questo tipo di effort nella trasformazione di informazioni tra ciò che conosciamo e ciò che comprendiamo.Il carico cognitivo come vi dicevo può essere di tre tipi, c'è il carico cognitivo intrinseco, che è parte della natura dell'argomento che stiamo affrontando, per esempio se parliamo di programmazione funzionale, il carico cognitivo intrinseco è per esempio la complessità del mondo della programmazione funzionale, quindi della teoria degli insiemi e di quant'altro.Complessità che sta nella natura, ok? Così come la programmazione RAST è strettamente legato alla complessità di tutto il sistema di gestione della memoria.Poi abbiamo il carico cognitivo estraneo che è il modo in cui le informazioni sono presentate alle persone, viene e è conseguente dal modo in cui vengono presentate le informazioni ed ecco perché noi dobbiamo scrivere il codice con una certa cura di quello che scriviamo, proprio per ridurre questa parte del carico cognitivo la cura la diciamo l'impegno che noi dobbiamo metterci nel ridurre l'obscurity rendere chiare le dipendenze rendere esplicite le cose non ovvie ecco viene inquadrato nel carico cognitivo estraneo che è quello che poi ci ha creato tutta la fear of the unknown di cui parlavo prima no? Quindi la paura dell'ignoto viene appunto dalla gestione di questo carico cognitivo estraneo ma poi abbiamo un terzo carico cognitivo che è quello più interessante in questa fase della nostra discussione che viene definito carico cognitivo permanente ed è il risultato del processo di elaborazione delle informazioni di trasformazione tra ciò che conosciamo e ciò che comprendiamo.Adesso detto così può voler dire nulla ma prendetevi un attimo se state facendo qualcosa fermatevi un secondo e provate seguirmi.Il processo che abbiamo per apprendere è un processo intricato che brucia energie e si attiva attraverso l'uso di due elementi fondamentali.La memoria di lavoro teorizzata da Miller negli anni 50 è la memoria a lungo termine.Immaginiamo come un registro, la memoria di lavoro è un registro del processore e la memoria a lungo termine immaginiamola come come una una ram ok la memoria di lavoro è super limitata veramente piccola piccola può archiviare 7 più o meno due elementi quindi o 5 elementi o 9 elementi che devono essere però strettamente coerenti tra di loro quindi devono avere uno scope super super limitato e soprattutto dura pochissimo, dura solo 20 secondi.Vi ricordate che a scuola ci facevano ripetere in realtà le poesie un botto di volte? Perché? Proprio perché per rinfresciare questo registro, questa memoria ogni 20 secondi affinché i concetti dalla memoria di lavoro si spostino nella memoria a lungo termine.La memoria a lungo termine non memorizza informazioni ma memorizza pattern, non informazioni esplicite ma lavora attraverso appunto i pattern.Questo prevede, permette di memorizzare tantissimi pattern ed è in continua evoluzione ecco perché vi ho detto che una ram e non ho usato la parola hard disk no? quindi c'è un meccanismo tale per cui queste sette informazioni della memoria di lavoro che durano solo 20 secondi e che se io non rinfresco dimentico queste informazioni devono essere portate alla memoria a lungo termine e quindi devono essere create queste sinapsi per memorizzare sto pattern.Adesso io sto semplificando tantissimo.Quindi quello che noi dobbiamo fare è cercare di attivare questo processo.Tra l'altro c'è un bellissimo studio di Giulio Tononi e Chiara Cirelli fatto nel 2005 che evidenzia che questo processo di trasformazione tra memoria di lavoro e memoria a lungo termine si attiva nel sonno perché è il momento in cui le le le sinapsi sono più plastiche e via discorrendo quindi è super interessante ma come noi possiamo portare la teoria del carico cognitivo di sueller miller nel nostro day to day work? beh la prima cosa che possiamo fare è siccome la nostra memoria di lavoro è super limitata 7 più o meno due elementi e solo 20 secondi dobbiamo fare applicare pareto la regola di pareto in modo più più più più drastico cioè andare a prenderci solo il 20 per cento di quelle informazioni che sono quelle veramente utili lasciando fuori l'ottanta per cento come possiamo fare per identificare all'interno della nostra code base questo 20 per cento di informazioni.Io ho trovato due piccole strategie ed entrambe utilizzano git.La prima è andare a vedere i primi commit.Tolto tutta la parte di scaffolding quindi di inizializzazione del progetto i primi commit contengono spesso il senso dell'applicazione o del tool della libreria che stiamo andando a esplorare.Per cui leggere i primi commit ci dà già un'idea chiara di quello che poi vedremo nel nostro codice e per farlo si può lanciare un comando git log reverse col parametro reverse andare a vedere i primi che ne so 30 commit oppure con git hub è un pochino più incasinato perché non ti permette di vedere i primi commit in modo lineare e quindi io cosa faccio parto da un commit e poi utilizzo la paginazione mettendo a mano il numero di step in cui vuoi verso il quale voglio arrivare che ne so io di solito parto da un commit e poi metto più 200 più 300 per andare indietro di 300 commit e così ci riesco in realtà zio github se ci ascolti ecco implementare una reverse navigation dei commit potrebbe essere una cosa figa e utile.Un altro modo che abbiamo per concentrarci su quel 20 per cento secondo zio pareto che ci dà veramente valore nell'esplorazione è quello di andare a trovare i punti caldi cioè i punti nel nostro codice che cambiano più spesso.Per farlo è molto semplice, lo si può fare direttamente con git log col comando git log, il comandino poi se volete ve lo metto nelle note di episodio o ve lo invio su telegram che vi permette di avere una lista di punti caldi di hotspot nel codice, cosa vuol dire? che sono i punti che cambiano più spesso, quali sono all'interno di una codebase i punti che cambiano più spesso? Quelli che hanno più valore implicito quindi quelli dove spesso e volte risiede il senso dell'applicazione.Poi se noi vogliamo vedere veramente l'evoluzione della nostra applicazione abbiamo tool di codebase visualization come Gours o un altro Gours o Pants c'è un sito bellissimo che è graph my repo che ci permette di avere un grafo di tutte le dipendenze quindi una bearded view nel nostro progetto o se utilizzate fastify piccolo momento marchetta col mio col mio amico Manuel abbiamo realizzato fastify overview in realtà tutta la parte core è merito di Manuel io ho solo fatto mezza UI che ci permette di vedere appunto l'intricata relazione all'interno di un'applicazione fastify se l'applicazione appunto è grossa è super super utile quindi se usate fastify buttateci un occhio ciao Manuel e avere una visione di insieme per esseri umani che siamo comunque visivi come in qualità di esseri umani siamo spesso molto visivi e avere sotto occhio tutto ci aiuta tantissimo beh e comunque tanta tanta roba ma quello che noi dobbiamo capire proprio in termini di approccio per limitare il carico cognitivo è che dobbiamo fare della regola di pareto dell'80-20, il nostro motto, il nostro principio base e sul libro a filosofia o software design, ci ritorno di nuovo mi raccomando se in queste vacanze di natale non l'avete letto prendetevi del tempo e leggetelo, c'è un pezzo interessante che dice che la complessità di un sistema non è legata solo alla complessità ciclomatica del codice ma è uguale alla complessità di una parte di quel codice quindi se io voglio stimare una complessità di un pezzo di un modulo devo stimare la complessità del modulo per il tempo o l'insieme delle volte che da sviluppatori ci spendiamo sopra.Cosa vuol dire che se un pezzo di codice è molto complicato ci aggiungere anche scritto di merda ma funziona ed è incapsulato noi possiamo trattarlo come una black box trattare dei pezzi di codice come black box nel momento in cui stiamo esplorando una code base è l'elemento che ci permette in modo più drastico di limitare il carico cognitivo perché non dobbiamo capire cosa fa quel pezzo di codice vediamo gli ingressi vediamo l'uscita leggiamo il nome del modulo perché è ben incapsulato e sappiamo che questa roba fa la conversione degli ordini da dal nostro sistema SAP al formato XML che vuole SAP perfetto non me ne frega niente di come dentro ci siano interazioni, trasformazioni, mapping non mi interessa tutto quell'insieme di complessità me lo evito cosa che invece mi porterei appreso se non trattassi quel blocco di codice come una black box per cui ecco Saper utilizzare le function signatures come elementi che circoscrivono della complessità e ci permettono di trattarli da black box è un altro elemento importantissimo.Io non riuscivo a capire perché nella mia carriera vedevo questi senior che gli dicevano sì ma cosa fa questa funzione? Oh me la frego cazzo, non mi importa, non è il posto dove voglio focalizzarmi.Sì vabbè ma sei senior dovresti conoscerla.una ceppa, conosceva la tecnica per non scavare là, perché doveva raggiungere un obiettivo e questo è quello che faccio io oggi no? Altra cosa i test.I test ci permettono di analizzare delle parti senza portarci appresso tutta la complessità e il carico cognitivo che ci viene dal contesto.Partiamo dai test unitari, cosa fanno i test unitari? Testano un piccolo componente in modo completamente isolato dal contesto, quindi se io voglio capire bene il comportamento di quel blocco io mi vado a vedere un test unitario, in quel caso io sono libero di tutto quel carico cognitivo che mi verrebbe invece dal contesto quindi vado in qualche modo a capire come funziona quella con la piccola box che potrei trattare come una black box ma siccome è importante per l'obiettivo che voglio raggiungere mi interessa analizzare e poi c'è che ne so gli end to end test che mi permettono invece di avere una visione un po più ampia mi permettono di vedere i flussi mi permettono di avere tutta una serie di altre informazioni che completano l'immagine ma a quel punto io vi ho detto trattiamo dei pezzi di codice come della black box e allora come poi posso gestire i pezzi di codice che non tratto Una cosa che ho imparato è appunto a gestire le information leftovers.Per ridurre il carico cognitivo devo lasciare per forza qualcosa fuori dalla scatola.E lo faccio utilizzando una tecnica che ha un nome complessissimo ma in realtà è di una semplicità assurda.Si chiama procrastinazione attiva con rivalutazione pianificata.Io il nome gliel'ho dato, è una roba che faccio da sempre, il nome gliel'ho dato preparando questo episodio e grazie Emanuele per farmi aver scoperto, per avermi detto, appunto, chiarito che quel modo di fare, di rimandare a domani in modo attivo si chiama procrastinazione e c'è un botto di letteratura mi hai aperto un mondo no? quello che io in realtà cosa faccio? quello che io faccio è c'è un pezzo di codice non voglio analizzarlo adesso perfetto prima vi ho parlato della funzionalità dei bookmark di Visual Studio Code se sto usando Visual Studio Code metto un bookmark metto la data nel bookmark e poi me lo scrivo nella mia to do list Quella data in realtà non è relativa al momento in cui lo prenderò in mano e quindi scaverò a fondo per comprenderne bene il significato profondo di quel blocco di codice ma riguarda il momento in cui io farò una rivalutazione se mi serve o non mi serve.In questo caso io si sto procrastinando ma sto ciclicamente facendo riemergere quello che ho rimandato e facendo una rivalutazione di quello che mi serve di quello che non mi serve.Naturalmente poi tutto questo è scritto, è scritto perché la memoria come abbiamo detto è super limitata quindi io mi faccio le mie mappine sulle moleskin e un'altra cosa che faccio molto figa sempre da questo punto di vista proprio per limitare il carico cognitivo è gestirmi un glossario.Sappiamo che nei nostri progetti l'ubiquitous language è l'elemento guida del progetto e lavorando in tanti progetti dove ci sono gozziliardi di acronimi ci si perde no? E quindi avere sempre un glossario a portata di mano è fondamentale.Io non so quanti di voi leggono romanzi, bene a me capitava e capita sempre quando inizio un romanzo di scrivermi i nomi di personaggi e le caratteristiche della quarta di copertina con una mattita e di ritornarci costantemente quando sto leggendo i primi capitoli finché il personaggio non è entrato dentro di me e la storia non si è sviluppata abbastanza da poter, da aver metabolizzato quel personaggio.Bene, faccio la stessa cosa col codice, col glossario.Questa cosa è veramente game changer.Quindi con tutte queste tecniche per la gestione del carico cognitivo il nostro Java Storing, il ranger umano cautico buono, ha sviluppato nuovi punti forza, destrezza, costituzione, intelligenza, perché? Perché ha imparato a decidere dove mettere le mani, quindi quali parti approfondire, sa creare la sua mappa del codice che sta esplorando quindi in realtà si sa orientare ha imparato a gestire i leftover quindi attraverso la procrastinazione attiva con rivalutazione pianificata ha la possibilità di appunto avere sotto controllo ciò che non sta analizzando e tiene traccia di tutto quindi è questo il momento in cui javas capisce di essere diventato un senior ma allora ho capito che il coraggio non è l'assenza della paura ma il trionfo sulla paura.Un uomo coraggioso non è chi non ha paura ma chi convive e conquista questa paura.Con queste parole di Nelson Mandela io vi do appuntamento all'anno prossimo a questo punto.Ci prendiamo qualche giorno per fare un digital detox.In realtà dopo i pranzi natalizi forse il detox servirebbe anche un po' più fisico oltre che digitale però noi ci sentiamo con la nuovissima stagione di Gitbar dopo le festività natalizie e dopo l'epifania.Un abbraccio a tutti e buon Natale di nuovo.Ciao! Ciao a tutti ascoltatori e ascoltateci di Gitbar.probabilmente avremo un po' di ritardo sugli auguri di natale per le feste spero di avere ancora il tempo di potervi dire qualcosa allora in realtà avevo preparato tutto un bellissimo discorso articolato l'avevo scritto però pian piano lo stavo rileggendo e mi convinceva sempre meno quindi cercherò di andare abbastanza a braccio quello che voglio fare è anzitutto ma diciamo ringraziarvi sia come ascoltatori, sia come ascoltatrici, sia come membri di questa community.E questo perché per me HitBar è stato tanto.È un'esperienza che è partita più di due anni fa ed è partita quasi per gioco, possiamo dire, per fare il favore ad un amico, partiva quasi per gioco per poter continuare quello che lui aveva cominciato e potergli tenere in caldo la sedia, diciamo così.In realtà Gitbar si è trasformato almeno per me in molto molto di più.grazie a Gitbar ho conosciuto amici, ho fatto delle esperienze meravigliose e sono cresciuto tanto sia come persona che come professionista infatti voglio innanzitutto ringraziare gli altri ragazzi di Gitbar, gli ammutinati che in questi anni mi hanno dato tanto, ho trovato degli amici e gli devo tanto e voglio ringraziare anche tutti voi che ascoltate Gitbar e che fate parte della community di Gitbar.Far parte della community di Gitbar credo sia un'esperienza che vada insomma oltre il confrontarsi su un tema tecnico piuttosto che un altro tema.Una battuta che spesso spesso mi piace fare, che siamo diversi dai soliti "asterisco asterisco in Italia" per non offendere nessuno anche in periodo natalizio.Ma su Gitbar ritengo di affrontare discussioni di ampissimo respiro, specialmente nell'ultimo mese, mese e mezzo, sto vedendo veramente che le discussioni stanno prendendo un tono altissimo, veramente sui massimi sistemi delle cose.Ed è una cosa che mi fa assolutamente piacere perché significa che GitBar è un posto sicuro dove poter parlare di tutto e non solo di argomenti tecnici.Certo poi il filo conduttore che ci unisce è la passione per questo lavoro e la passione per la tecnologia, per la formazione, per lo sviluppo software in generale, ma riusciamo a fare argomenti anche molto complessi con una discreta quantità di flame e non è da poco e quindi credo che a me, a tutti, e credo che possa parlare anche a nome degli altri ragazzi di Gitbar, ci ha dato molto Gitbar e ci da tanto ogni giorno e a parere mio personale posso dire che Gitbar mi ha aiutato a superare dei momenti diciamo abbastanza bui e mi ha dato sempre quella voglia anche di migliorarmi dal punto di vista professionale.Infatti, se proprio la vogliamo dire, è tutto il mio ultimo e attuale lavoro e soprattutto aiuto di Gitbar.Quindi non posso che essere estremamente grato a questa community e quindi vi voglio lasciare dicendo che vi aspettiamo, che vi aspettiamo sul nostro gruppo Telegram, che vi aspettiamo su Twitter @brainrepo e aspettiamo le vostre mail su info@gitbar.it.Mi piace per una volta essere io quello che ricorda i vari contatti perché proprio è un invito, a te che ci stai ascoltando e non hai mai interagito, non hai interagito con noi, un po' perché forse c'è un po' di sindrome dell'impostore che abbiamo tutti io in primis, un po' per vergogna, un po' perché magari si pensa sempre di non avere tempo.Entra nel nostro gruppo Telegram, scrivici su Twitter, inviaci una mail perché spesso basta basta veramente poco per far cominciare qualche cosa di grande e dagli aspetti diciamo e dalla futuribilità imprevedibile e questo è stato gitbar per me rispondere ad un messaggio su telegram e ritrovarmi anni dopo a essere parte di qualcosa di veramente grande e lo dico non con poca diciamo...e lo dico senza nessuna vergogna, credo che Geekbar sia veramente qualcosa di diverso ed è grazie a tutti voi.Quindi vi auguro un buon Natale, un buon inizio anno e un grande 2023 e per quanto possa contare ci potete sempre trovare qui.Ciao a tutti! GitBar, il circolo dei fullstack developer.Una volta a settimana ci troviamo davanti a due birre e con BrainRepo parliamo di linguaggi e tecniche di sviluppo web, di metodologie ed strumenti immancabili nella cassetta degli attrezzi dei Full Stack Dead.
