*musica* Siamo noi quelli che leggendo il codice cercano lo stronzo che ha scritto quello schifo Ma ahimè, lo stronzo è mai medesimo, ma l'ho scritto giusto ieri *I'm sorry* Siamo quelli che santificano il nuovo framework javascript preferendo segretamente jQuery Gli stessi per il quale il testing è importante, infatti la nostra codebase ha solo due test e flakey pure Siamo noi quelli che il tuo linguaggio fa cagare, ma il mio è peggio.Quelli che la chiarezza nei comment message prima di tutto, e dentro ce l'appella tutti i santi."Se non bestemmi io guarda" Quelli che in call parlano per 5 minuti prima di accorgersi che il mic è muto.Quelli che non si può fare di default, diventa velocemente un tutto è possibile se hai le risorse, tempo e budget ilimitato.Siamo noi quelli che l'AI va regolamentata, ma hai visto questo nuovo modello che disegna gatti di funambuli? Quelli che il dipende e unisci gratis la prigione.E quelli che la RAL...No vabbè, fa già ridere così.Siamo quelli che fanno lo slalom tra le specifiche che cambiano costantemente.Ormai rassegnati che la definition of ready è solo una pia illusione.Quelli che si sentano dire "ho un'idea per un'app" ed è subito l'ennesimo social come Instagram, ma meglio.Siamo noi che nonostante il deploy fallito, l'ACI rossa, il business incazzato, ci troviamo al Gitbar e davanti a una birra tutto ci sembra un po' meno grave.Bene e benvenuti su Gitbar, nuova settimana e nuovo episodio qua nel nostro bar degli sviluppatori.Sabato, mentre facevo il giardinaggio ripensavo a quello che ho fatto questa settimana e allora mi è venuto in mente di fare questo episodio un po' diverso dal solito, un po' fuori dal nostro standard.Di solito infatti li registro là in studio, là su, e invece oggi sono in giardino perché è sabato e bisogna essere un po' più chill, un po' più rilassati.Voglio raccontarvi però di quello che ho fatto quest'ultima settimana.Questa una versione di Git, un po' del tipo "Mauro racconta cose e vi svuota la testa", qualcosa del genere.Quest'ultima settimana sono stato impegnato nel fare un IA, un Impact Assessment, un documento che in qualche modo spiega l'impatto che hanno delle potenziali modifiche su un ampio sistema, un sistema enterprise.Non l'avevo mai fatto prima e in realtà è molto più difficile di come possa sembrare, perché alla base di una stima di impatto bisogna conoscere la codebase.Cosa succede quando non si conosce la codebase? La si deve studiare.Il problema in realtà sta nel fatto che le codebase, spesso quelle sviluppate in ambito enterprise, magari da più team, per quanto possano essere ben documentate hanno tutta una serie di informazioni che non sono esplicite, che sono spesso quelle informazioni che si annestano tra gli intestizi dei vari silo, perché sfido chiunque a dirmi che in una qualunque enterprise non esistono dei silo informativi.Ecco, tra questi due silo che che magari lavorano sulla stessa codebase si nascondono delle informazioni, spesso quelle di integrazione, che non sono esplicite, non sono trasparenti.Allora, mentre facevo questa investigazione, questo studio, questa analisi, mi è venuto in mente il talk che ho fatto qualche anno fa a Code Motion, dove raccontavo cosa bisogna fare quando si approccia al Manovac Codebase, quindi, facile, so già qual è il mio metodo, applico pedesequamente il mio metodo e in un modo o nell'altro riesco a portare a casa il pane.Sì, fino a pagina due e adesso vi spiego perché.La prima cosa che io ho sempre detto è "si parte dalla documentazione".Adesso la documentazione c'è, non c'è, però un problema di fondo che non si muove alla stessa velocità della codebase e questo è un problema fondamentale perché se la documentazione non si muove alla stessa velocità della codebase può essere che la documentazione non sia verità, può essere che la documentazione sia vecchia, che sia parziale e la documentazione di per sé non è un qualcosa che si muove con la codebase, ma è un qualcosa che si muove a fianco con il suo ritmo, per cui non muovendosi con la codebase e avendo appunto questo rischio di non essere allineata, la documentazione diventa concettualmente un discorso di fiducia.È interessante questo concetto perché in realtà non ci avevo mai pensato.Leggere documentazione vuol dire fidarsi di qualcosa che ci sta dicendo qualcuno.Solo il codice è portatore di verità.Qual è il problema? È che il codice non possiamo leggerlo tutto quanto e vi spiego anche perché secondo me non si può fare.Per cui dobbiamo fare in qualche modo affidamento sulla documentazione.Però il codice muta, la documentazione non si muove col codice, per cui si parla di un discorso di fiducia.Adesso, questo non vuol dire che io non mi fidi di chi ha scritto la documentazione, però io in questa fase, nel momento in cui devo fare un impact assessment, ho bisogno di solide fondamenta per analizzare l'impatto e la documentazione di per sé è uno strumento che potrebbe nascondere la verità.E non è solo una questione di "non mi fido di chi l'ha scritta", perché io devo guardare che ore sono, prendo l'orologio e guardo che ore sono, ma questo non vuol dire che non mi fido di chi mi direbbe l'ora se gliela chiedessi, è solo una questione di come ottenere l'informazione.L'azione numero due, quindi se la documentazione mi dà una visione che è sempre utile avere ma che può essere o può nascondere degli errori o delle fallace o potrebbe essere non allineata a questo punto devo leggere il codice.Problema! Il codice è tanto! Una codebase media conta anche 250.000 lighe di codice che sono più o meno 65 volte l'hamletto, con l'unica differenza in realtà che l'hamletto può essere facilmente riassunto, la nostra codebase un po' meno.La codebase inoltre ha un'altra complessità, che la sua navigazione non è unidirezionale, una sola direzione, una sola sequenzialità, ma è un mondo interlinkato che come abbiamo detto evolve e quindi leggere codice è complesso, è una delle attività più complesse degli sviluppatori e tra l'altro, leggevo alcuni studi, è anche una delle attività che prende il 60% del nostro lavoro, cioè noi da sviluppatori spendiamo il 60% del nostro tempo a leggere codice.E allora qua io mi incazzo e mi chiedo, ma se noi spendiamo il 60% del nostro tempo a leggere codice, perché cazzo non ne parliamo mai nelle conferenze, negli articoli? Perché non discutiamo sulle metodologie che applichiamo nel leggere codice? E on top of questo mi verrebbe da chiedermi, visto che in questo periodo stiamo parlando tutti di intelligenza artificiale, large language model, generazione di codice, ci facciamo scrivere il codice da cloud, da chat gpt, ma perché in pochi parliamo di quanto ci sia bisogno di leggere il codice e più facciamo uso di questi strumenti, più facciamo uso di VibeCoding, più in realtà il problema di leggere del codice diventa ancora più profondo e più difficile.E allora a questo punto mi viene in mente come leggiamo il codice.Mi viene da chiedere qual è il metodo che utilizziamo per leggere il codice, ma ancora prima di questa domanda più più pratica è perché leggiamo il codice? Leggiamo il codice perché leggere il codice è esattamente il pilastro del nostro lavoro.Noi non siamo pagati per scrivere codice, siamo pagati per raccogliere informazioni, costruire una tesi, validarla e risolvere un problema.Questo è il motivo per cui tutti i mesi riceviamo il nostro stipendio e questo è il problema per cui leggere il codice diventa pilastro fondamentale, perché abbiamo la necessità di prendere delle decisioni informate.Io sono pronto a scommettere che il 90% di noi quando lavora, lavora su sistemi, su piattaforme, sviluppa sistemi e piattaforme che semplificano questa fruizione, semplificano la lettura dei dati aiutando persone a prendere decisioni.E allora mi chiedò, ma perché cazzo non lo facciamo per noi stessi? Perché leggere il codice è così difficile? Probabilmente il motivo per cui è così difficile è perché utilizziamo lo strumento che usiamo per scrivere codice con lo scopo di leggere il codice, scrivere il codice, leggere il codice, sono due azioni che sono completamente diverse, sono quasi agli antipodi.E allora mi dico, buona parte dei problemi che abbiamo nel leggere il codice sono dati dal fatto che utilizziamo uno strumento che è pensato per risolvere tutti i problemi legati al codice.E allora, se per un attimo pensassimo al codice esattamente come pensiamo ai dati che mostriamo al nostro manager sulle dashboard che scriviamo in D3JS, no? Perché non pensiamo al codice come dati? E perché no a questo punto non facciamo un passo indietro e proviamo a guardare il codice come data scientist? E pensiamo al fatto che probabilmente abbiamo bisogno di visualizzazioni che semplificano la lettura del codice.Ragionando in questa direzione ci viene in mente, ci viene subito a pensare che le codebase sono tutte diverse.L'università di Berna, qualche tempo fa, ha fatto un'analisi e uno studio.ha provato a dare dei requirements e un set di librerie di dipendenze a diversi team e ha detto "ei cari team, sviluppate un software con questo linguaggio, queste dipendenze, che fulfilli questi requirements".Le varie applicazioni che ne sono venute fuori, o almeno le code base che ne sono venute fuori sono state poi analizzate con un force diagramma, adesso non ricordo il nome, ma sono quei diagrammi dove ci sono le palline elincate che mostrano appunto uno spaccato dei metodi, delle classi, delle funzioni, della struttura del codice.E' emerso che ogni team ha creato il suo codice che aveva la sua forma specifica.E allora se noi abbiamo un problema nel leggere il codice perché abbiamo degli strumenti generici, one size fit all, che risolvono i problemi dappertutto, allora mi dico cosa sarebbe se avessimo degli strumenti che in realtà sono specifici, tailored, disegnati apposta per una specifica codebase.Mi immagino delle dashboard in stile, che vi posso dire, in stile Power BI o superset, dove si possono esplorare metodi, dove si può esplorare la codebase, vedere le dipendenze, vedere gli impatti nelle varie aree moduli integrati magari con dei flame graph che mostrano il carico, cioè mi immagino degli strumenti integrati per la lettura e la comprensione dei sistemi magari a livelli.Mi direte "Mauro e chi paga?" Sicuramente non io, nel senso, mi immagino che sviluppare ad hoc una soluzione di questo tipo sia veramente costosa, premesso che più del 60% del costo dello sviluppo software è allocato in lettura di codice, probabilmente potremmo anche dire "sì è costosa, ma se ottimizziamo quest'area dove spendiamo tanto e che è possibile ottimizzare e che nessuno o pochissimi ci stanno pensando, probabilmente troveremo anche il budget per coprire.Ma oggi il nostro modo di pensare è in termini di modularità.Tutti i giorni scriviamo componenti Vue, React, abbiamo chiaro nella nostra testa il concetto di components.E allora, cosa potrebbe succedere se avessimo dei tool per leggere codice nei quali possiamo collegare component diversi per creare la nostra esperienza di sviluppo? Ma non è molto lontano da quello che facciamo con strumenti come Backstage? backstage? E se lo facessimo anche a livello di codebase? Beh, in realtà io non sto inventando nulla.Mi è venuta in mente questa idea parlando con mia moglie di come si potesse sviluppare un software di questo tipo, mi è venuto a cercare su chat gpt e su google e ho scoperto che esiste un mondo, o almeno esiste uno scienziato, credo sia uno studioso, un ricercatore, credo che sia dell'Università di Bernache ha proprio analizzato questo aspetto.Lui è partito da un ragionamento appunto di quanto si spende nel leggere codebase magari scritte in COBOL e quanti soldi si buttano in queste codebase che in realtà sono ancora presenti rego nel mondo probabilmente.Questo studioso, in qualche modo questo ricercatore, ha tirato fuori l'idea di questo concetto del "moldable development", vi lascio un link nelle note dell'episodio, ed è appunto l'idea di costruire uno strumento per l'analisi del codice e non solo, in realtà l'analisi dei sistemi, perché flame graph, debugger, tutto integrato, tutto che si muove insieme e soprattutto la cui composizione sia affattibile.E quindi appunto c'è questo concetto che mi ha interessato tantissimo.Tra l'altro c'è questo tizio che ha sviluppato un prototipo chiamato Glamorous Toolkit, forse, Glamorous framework.Adesso non ricordo, tra l'altro ho sviluppato in faro un dialetto moderno di Smalltalk.Questi universitari tirano fuori sempre delle cose con linguaggi esoterici.A parte questo, l'idea è appunto di comporre questi elementi del software mutuando un po' dalla, come si chiamano, dei workbook dove si mettono snippet di codice documentazione insieme.È una roba da approfondire, probabilmente siamo ancora in una situazione un po' prematura, però secondo me questo è uno degli ambiti di sviluppo, anche perché in realtà per esempio in questa fase dove devo fare un'analisi di impatto su una codebase che non conosco mi sarebbe tornato molto utile uno strumento evoluto per componenti riutilizzabili su un host che mi permette di collegarli.Molti mi possono dire "ma Visual Studio Code già è è plaggabile, supporta i plugin, sì, ma parlo di un livello differente di integrazione, molto più vicino a un tableau, molto più vicino ad altri tipi di strumenti che Visual Studio Code, che in realtà non è pensato per questo.Però avere uno strumento di questo tipo mi sarebbe tornato particolarmente utile.E' per ricollegarci in un contesto dove più del 60% del tempo è speso nello scrivere codice, in un contesto quindi dove il 60% del costo dello sviluppo del codice è in lettura del codice e noi continuiamo a parlare di generazione di codice, o LLM, avere uno strumento che semplifica la lettura, magari supportato da strumenti di intelligenza artificiale che corredano il tutto, potrebbe dare quel vantaggio competitivo che ci manca e soprattutto potrebbe portare quella ventata di freschezza nello sviluppo software che mi auspico da tempo, visto che mi sono anche un po' rotto le balle di sentir parlare di LLM e generatori di codice e vibe coding.Spero che questo episodio vi sia piaciuto, in realtà era un vomitare idee che mi venivano mentre facevo il giardinaggio, un po' diverso dal solito.Io vi do appuntamento alla prossima settimana, ricordandovi che ci trovate nel nostro gruppo Telegram, ricordandovi anche che abbiamo lo store con le magliette del video terminalista metalmeccanico e che potete supportarci nel sito, trovate insomma tutti gli strumenti per farlo.Io, ripeto, vi do appuntamento alla prossima settimana, mi piacerebbe sapere da voi cosa ne pensate di questo concetto e vi do appunto la prossima stimola.Ciao ciao! [BARBARA]
