[Musica] Bene, benvenuti in questo nuovo episodio di Gitbar.È Natale eppure non indosso un maglione natalizio, ma sono qua in vostra compagnia perché riputo che in questo 2020 un po' balordo l'esperienza di Gitbar mi abbia dato qualcosa di veramente eccezionale.La community che si incontra sul gruppo Telegram è diventata una famiglia e in quest'anno anche professionalmente e umanamente penso di essere cresciuto molto anche grazie al vostro aiuto e alla vostra condivisione.Poi naturalmente qua sui I tavolini di Geetbar si sono avvicendati tantissime grandi persone, ognuna delle quali portava un pezzettino di sé, raccontava una parte della sua esperienza, di visione del mondo.E sono queste, dal mio punto di vista, le cose che fanno crescere.Poi però, come ogni bar, gli ospiti vanno via e ti ritrovi da solo a pulire il bancone con lo straccio.e magari una volta che hai pulito questo bancone virtuale ti sedi un attimo anche tu nel tavolino, provi a rilassarti un attimo e a ragionare lasci la mente libera di vagare dove vuole e magari riprendi un libro che sta là vicino al bancone quel libro è il libro di Italo Calvino "Cità invisibili" che ho preso e ho provato a leggere in questa situazione immaginaria ma leggendolo ho ritrovato tanto della nostra professione, tanto di quello che facciamo tutti i giorni e quindi ho fatto una mia riflessione in stile natalizio che volevo condividere con voi [Musica] Benvenuti su GITBAR, il podcast dedicato al mondo dei fullstack 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.La città di Leonia rifà se stessa tutti i giorni.Ogni mattina la popolazione si sveglia tra l'insuola fresche, si lava con saponette appena sgusciate dall'involucro, indossa vestagli nuove e fiammanti, estrae dal più perfezionato frigorifero barattoli di lata ancora intonsi, ascoltando le ultime filastrocche che dall'ultimo modello di apparecchio escono.La descrizione della città di Leonia racconta un po' il codice che tutti vorremmo avere, quindi mi porta a ragionare in termini di refactoring.Infatti quando noi facciamo il refactoring agiamo un po' come agì il Rudolf Giuliani di vent'anni fa appunto a New York in qualità di sindaco quando decise di riqualificare alcune aree della città a livello estetico con l'obiettivo di ridurre la criminalità e questo tipo d'azione in un certo senso funzionò quindi sembra quasi che la riqualificazione tutto per un tratto fa sparire la malavita questa azione naturalmente non è magica ma presuppone che sotto ci sia una una certa fatica è un po quello che noi facciamo nella nostra code base quando facciamo il refactoring ma che cos'è il refactoring nella sua essenza? il refactoring è quel cambiamento interno che non altera la parte di comportamento esterno e che serve per rendere il nostro codice più resiliente quindi più duraturo nel tempo dandogli quelle caratteristiche tipiche di qualcosa che riesce a resistere alle intemperie che sono la manutenibilità la riduzione della complessità e perché no anche le performance Quando però noi approcciamo a refactoring la prima cosa che ci viene in mente è quel famoso ciclo tipico del TDD, il ciclo del scrivo il test, il test fallisce, scrivo l'implementazione e il test viaggia.Quindi cosa faccio? Scrivo il mio codice nel minor tempo possibile in modo che funzioni e poi rifattorializzando ripulisco un po il cantiere e miglioro le saldature in modo che il mio codice riesca a essere un pochino più mantenibile un pochino meno complesso e perché no anche un pochino più performante.Ma per capire questo ciclo dei test il ciclo red green quindi test rosso e test verde ci viene in aiuto un ragionamento che prova a distinguere due tipi di programmazione la programmazione tattica e la programmazione strategica e Kent Beck ha raccontato questa divisione tra programmazione di tipo tattico e programmazione di tipo strategico usando una metafora che secondo me la descrive in modo veramente preciso che è la metafora dei due capelli infatti il programmatore deve indossare due capelli il primo nel momento in cui scrive il codice quindi chiamiamolo il cappello del muratore e quindi questo cappello deve stimolare il pensiero tatico cioè devo scrivere del codice che funziona nel minor tempo possibile.Il secondo cappello quello un pochino più da ingegnere è invece il cappello che ci accompagna al refactoring e che è un po più legato al pensiero strategico il cui obiettivo è quello di in qualche modo cercare delle modalità per contenere la complessità in un'ottica di medio o lungo periodo naturalmente qua emerge il concetto di refactoring, refactoring che ha senso però se è chiaro l'obiettivo è il goal ecco perché l'ottica deve essere di medio o lungo periodo.Un buon programmatore è colui che ha queste due personalità noi siamo spesso dei mostri dobbiamo essere in in grado di switchare un cappello e l'altro nel modo più veloce possibile.Quindi scrivere blocchi sempre più piccoli di codice che funziona e subito dopo provarlo a ripulire in modo da ottenere un codice che funziona e allo stesso tempo riesca ad avere una complessità limitata e magari una mantenibilità superiore.Però spesso siamo portati a sottovalutare questo processo di pulizia e a questo punto quando sottovalutiamo questo compito importante che ci è dato in qualità di sviluppatori aumentiamo l'accoppiamento e soprattutto aumentiamo la complessità.Lo facciamo spesso mandando a quel paese buttando agli ortiche lo stile e la coerenza nel nostro codice e qua mi viene in mente un pensiero che ho letto diversi anni fa scritto da Sun Tzu nell'arte della guerra e che dice non muoverti se non vedi un vantaggio non usare le truppe a meno che non ci sia qualcosa da guadagnare e infatti è la visione del futuro che deve influenzare le azioni del presente e lo deve fare anche nel nostro codice cioè avere una visione complessiva ci deve aiutare a gestire l'azione nel micro e questo cambiare cappello rapidamente da una parte all'altra deve essere lo strumento che abbiamo per passare da micro a macro velocemente e continuare quindi ad avere una visione del futuro infatti il generale come dice Sun Tzu deve sapere se la battaglia che sta combattendo oggi lo condurrà all'obiettivo finale della vittoria altrimenti tutto il lavoro che sta facendo non essendo finalizzato non avendo quella visione olistica complessiva che si ha quando si mette il cappello dell'ingegnere probabilmente andrà perso sarà inutile.Vero è che però il nostro mercato corre a una velocità spaventosa e spesso quando realizziamo i nostri prodotti non abbiamo una visione chiara di quello che sarà tra un anno due anni cinque anni anche perché diciamo che il nostro mercato ha un movimento quasi schizofrenico e quindi spesso ci troviamo con una situazione che è molto simile a quella che Calvino descrive che adesso vi leggo Sui marciapiedi, avviluppati in terzi sacchi di plastica, i resti di leonia di ieri aspettano il carro dello spazzaturaio.Non solo i tubi di dentifricio schiacciati, lampadine fulminate, contenitori, materiali di imballaggio, ma anche scaldabagni, enciclopedie, pianoforti, servizi di porcellane.Più che dalle cose che ogni giorno vengono fabbricate, vendute e comprate, l'opulenza di Leonia si misura dalle cose che ogni giorno vengono buttate via per far posto alle nuove.a tutto questo caos, a tutta questa mondezza abbiamo la necessità di farci spazio e per farci spazio abbiamo bisogno di una bussola.La bussola quando lavoriamo come sviluppatore, anzi l'unica bussola quando lavoriamo come sviluppatore in questo contesto, non può che essere i valori, i valori che noi sposiamo nella nostra professione e uno di questi dal mio punto di vista uno dei più importanti è il valore della consistenza, quel valore che ci aiuta a farci spazio tra la mondezza e dobbiamo coltivare il valore della consistenza quando ci vengono dati, riceviamo dei segnali.Il primo è quando iniziamo a non capire il nostro codice.Il codice che noi leggiamo ci sembra un alieno, abbiamo difficoltà nel districarci tra tutte quelle linee che parlano una lingua che non riconosciamo e quindi l'inserire delle nuove funzionalità ci prende una quantità di tempo e uno sforzo mentale molto alto.Tutto questo naturalmente ci accompagna a una situazione, una sensazione di frustrazione.naturalmente in mente abbiamo chiaro quello che noi vorremmo.Il nostro mondo ideale è quel mondo dove la qualità della nostra codebase dopo un X di tempo continua a rimanere uguale alla qualità che abbiamo iniziato a immaginare, abbiamo immaginato in fase di progettazione e a quel punto quando noi abbiamo quest'idea lontana quasi utopica e allo stesso tempo ci troviamo in una situazione super messi complicata contorta da gestire ed in questo momento che si affaccia la paura ci siamo davanti al codice abbiamo paura di rompere tutto abbiamo paura che la nostra fix o la nuova piccola funzionalità che stiamo implementando generi un butterfly effect che faccia a crollare tutta la nostra codebase e quindi andiamo a intervenire con delle piccole fix, dei piccoli interventi arraffazzonati.Certo il TDD aiuta, ma aiuta in cosa? Aiuta semplicemente a prevedere le catastrofi, ma comunque siamo tentati e siamo portati a creare queste piccole fix proprio per scongiurare quel butterfly effect che vanno a incrementare accoppiamento, consistenza e quindi una volta che terminiamo quando dovremo andare a creare delle nuove fix andremo a incrementare accoppiamento e a perdere di consistenza andando a generare poi una spirale negativa che Calvino nel suo libro ha raccontato in modo credo eccezionale con questo pezzo Il risultato è questo che più leonia e spelle roba più ne accumula le scuome del suo passato si saldano in una corazza che non si può più togliere rinnovandosi ogni giorno la la città conserva tutta se stessa nella sola forma definitiva quella delle spazzature di ieri che si ammucchiano sulle spazzature dell'altro ieri e di tutti i giorni, anni, lustri ci troviamo in una situazione dove non siamo ad agio col nostro codice e l'unico modo in realtà che ci avrebbe potuto tenere in una comfort zone all'interno della nostra codebase era quella di cercare di preservare le convenzioni.Sono infatti le convenzioni che ci aiutano a orientarci.Immaginiamo per un attimo di...proprio immaginare una città dove ogni quartiere ha dei cartelli stradali conforme e colori diversi appunto dedicati a ogni quartiere.Come possiamo orientarci in questo contesto? Quando noi ci troviamo davanti a questo tipo di codebase difficilmente riusciamo a gestire la nostra paura e andiamo a fare quello che ho detto prima di piccoli interventi volti proprio a non generare il butterfly effect.Questi piccoli interventi spesso nascono perché non avendo consistenza nella nostra codebase essendo difficile orientarsi.Mentalmente siamo portati ad andare a cercare dei pattern per riconoscere delle strutture comuni che possiamo utilizzare come punti di riferimento ma essendo questo processo molto difficile spesso ci troviamo a fare degli assunti sbagliati.Quindi avere una code base con delle convenzioni, avere una code base consistente ci permette di imparare le cose in un posto all'interno della code base e riutilizzabile e riusarle dei processi delle dinamiche delle strutture in un posto e riutilizzarle anche da qualunque altra parte della struttura riconoscendole e sentendoci confidente con questa parte della struttura.Tra l'altro avendo e e riuscendo a dare questa coerenza.
