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ù efficace possibile quei prodotti digitali che quotidianamente utilizziamo.12esima puntata di GITBAR, bene e benvenuti.Io sono BrainRepo e questo è il podcast dei Fullstack, developer italiani.12esima puntata dove affronteremo un argomento molto interessante, tanto semplice quanto importante nella vita dei developer.parleremo infatti di dare i nomi alle cose dove per cose intendiamo variabili, classi, funzioni, costanti e tutti quegli elementi che sono praticamente le nostre lego con le quali andiamo a costruire il nostro castello quotidianamente.Ma prima di entrare nel vivo dell'argomento di oggi mi premeva ricordarvi i nostri contatti.Bene potete entrare in contatto con me scrivendo a info@gitbar.it oppure direttamente attraverso Twitter @brainrepo In informatica due sono le cose più complesse dare il nome alle cose e invalidare la cache Sull'invalidare la cache ci torneremo in una delle prossime puntate ma oggi ci soffermiamo sul passaggio sull'azione che è quella di dare il nome alle cose.Prima di entrare nel vivo proprio tecnico, delle regolette, le buone pratiche per dare il nome alle cose, mi piacerebbe immaginare il programmatore come se fosse uno scrittore e nel mio immaginario vedo un Dante Alighieri che fa il factoring o un Manzoni che si occupa di scrivere le classi e fare TDD (test driven design) insomma, un'immagine abbastanza simpatica.Perché cito questa immagine simpatica? Perché in realtà dovremmo imparare dagli scrittori.Scrittori che per creare un personaggio fanno un'analisi, uno studio quasi maniacale.La stessa cosa noi dovremmo fare per realizzare le nostre classi, i nostri metodi, le nostre funzioni e le nostre variabili.Andando un po' sulla rete, ho beccato delle note molto interessanti.C'è un testo di George Orwell che si intitola "Rules for Naming", ok? E che dà una serie di regole, detta una serie di buone pratiche, agli scrittori su come, appunto, andare a scrivere i romanzi.E il passaggio più importante che George Orwell cita è un passaggio che secondo me è molto significativo.Lui ci batte tantissimo su questo.È il passaggio che dice che bisogna lasciare che il significato scelga le parole e non arrendersi e cedere alla parola stessa.Quando scriviamo il nostro codice, spesso ci viene di getto dare un nome a una variabile e spesso questo nome non è il nome migliore che può essere associato al significato del caso.George Orwell dice appunto di, nel momento in cui si dà un nome a una variabile, fermarsi un attimo, andare a identificare il vero significato e cercare la parola migliore che può descriverlo.Per farlo lui suggerisce tutta una serie poi di piccole regole, quindi non lasciarsi guidare dall'istinto nel buttare giù una parola, ma da quella parola prendere il significato e cercare la parola migliore per poter rappresentare quel significato.La prima regola che lui ci dà è quella di non usare metafore.Le parole sono precise, indicano un elemento piuttosto che un altro e lo fanno in un modo molto puntuale.Per definire la nostra variabile, la nostra classe, la nostra funzione, dobbiamo usare la parola perfetta, la parola che la rappresenta.Lui ci suggerisce anche che se ci troviamo davanti a una parola lunga, a una parola corta, dobbiamo scegliere necessariamente la parola corta.E questo ritorna anche a noi nel nostro codice.Sembra quasi che George Orwell fosse uno sviluppatore.perché questo elemento ci ritorna quotidianamente, perché basta immaginare le variabili lunghissime, le variabili brevi, che però ci danno un significato immediato, quali preferiamo? Preferiamo senza dubbio i nomi di variabili brevi, perché? Perché a colpo d'occhio ne riusciamo a estrappolare il significato.Un'altra cosa, George Orwell dice che se puoi tagliare una parola o eliminare una parola, toglila.Immaginiamo ai nostri nomi di variabili, di funzioni, di metodi, di classi composte.Quante volte utilizziamo più parole per definirli? E quante volte queste più parole sono superflue? Possiamo strizzare, ridurre, eliminare delle parole che non ci aiutano a identificare quel concetto.Bene, questa è una regola letteraria che sta insieme alle regole di George Orwell, ma che quotidianamente possiamo utilizzare nel nostro operato.Lui inoltre ci dice sempre nel testo "Rules for Naming" di preferire sempre la forma attiva, la forma passiva, immaginiamo una variabile "letto" al posto di utilizzare una funzione "leggere", e poi lui ci suggerisce di non usare verbi frasali.naturalmente George Orwell queste regole le ha definite naturalmente per gli scrittori inglesi però immaginiamo di dover scegliere tra due parole "dormirci su" o "rifletterci" qual è più semplice? Quale scegliereste voi? e l'ultima regola appunto delle regole letterarie stabilite da George Orwell Orwell nelle rules for naming è quello di evitare parole scientifiche o comunque fuori contesto.E qua dovendola ricondurre all'ambiente di sviluppo mi viene in mente una cosa interessante.Quante volte cerchiamo, utilizziamo delle parole fuori dalla logica di business, fuori dalla logica di business, che un po' confondono all'interno del nostro codice? Bene, le parole scientifiche citate da George Orwell possono essere identificate in quello, cioè una parola che è completamente fuori contesto, che quindi risulta difficile per chi deve andare a programmare perché non riesce a decifrarla nel momento in cui sta usando quel codice che magari l'ha scritto un'altra persona.Beh, noi programmatori cosa facciamo? Certo, spesso ci dimentichiamo delle regole del buon nominare di George Orwell, tanto che l'altro giorno ho fatto un esperimento.ho provato a cercare sia foo che foo bar all'interno di github per vedere quante istanze quante righe di codice risultavano presenti all'interno di questi appunto famosi tool per l'archiviazione di repository git e alla ricerca di foo sono rimasto di stucco perché ho visto che ci sono 174 milioni di istanze che si chiamano foo dove foo è una variabile segna posto un nome segna posto un nome che non non ha un significato.Quindi nel nostro lavoro dovremo fermarci un pochino di più e ragionare un pochino di più sui nomi delle variabili.Anche perché in realtà se pensiamo al nostro codice dobbiamo prendere in considerazione il fatto che il codice è scritto per gli uomini e non per i compilatori o gli interpreti.quindi il codice di per sé è uno strumento per comunicare.Noi dobbiamo partire da questo presupposto.Possiamo comunicare agli altri che sono i membri del nostro team o le persone che lavorano allo stesso progetto open source oppure il nostro cliente che deve poter leggere il nostro codice ma dobbiamo anche comunicare a noi stessi, a noi stessi, il noi stesso che poi dovrà prendere il codice tra quattro mesi e dovrà capirci.Quindi migliori sono i nomi che utilizziamo nel nostro codice, migliore sarà la qualità del codice anche perché in realtà quando parliamo di codice complicato non stiamo parlando di una complessità altissima.Solitamente quando si parla di codice complicato si parla di codice implicito dove i nomi delle variabili e i concetti non sono identificabili a prima occhiata.Quindi quando mi trovo davanti a un blocco di codice implicito, di primo colpo, a livello empatico, la prima cosa che vedo è che un codice è complicato.Poi magari il codice fa un'operazione banalissima, però ho davanti un codice complicato, solo perché è implicito.In realtà il codice dovrebbe spiegarsi da solo.I nomi delle variabili, delle classi, delle metodi e funzioni, dovrebbero essere talmente eloquenti da non avere necessità di commenti, di nessun commento di sorta.E qua mi viene in mente un capitolo di Clean Code di Bob Martin.Bob Martin ha scritto un bellissimo libro, si chiama Clean Code, e suggerisco a tutti gli sviluppatori, almeno chi non l'avesse fatto perché credo che l'80% e il 90% degli sviluppatori abbiano letto quel libro, di leggerlo e uno dei primi capitoli, anzi direi il primo vero capitolo ciccioso dove c'è della sostanza parla appunto di come dare il nome alle variabili e lui utilizza una serie di esempi per raccontare i casi limite e le best practice da utilizzare.Beh, la prima best practice che Uncle Bob racconta e che suggerisce è quella di evitare la disinformazione Scegliendo appunto un nome giusto, un nome legato al significato nelle nostre variabili, diciamo, riusciamo in qualche modo a dare l'informazione precisa, puntuale, per poter identificare il suo contenuto.Un'altra cosa che racconta Bob Martin nel primo capitolo è che suggerisce quella di utilizzare dei nomi pronunciabili.e lui fa un esempio molto molto interessante racconta di aver lavorato in un blocco di codice dove la data di generazione si chiamava gen ymd hmn e qualcos'altro, no? allora, che cosa dice questo nome? semplicemente da la data in anni, mesi, giorni, ore, minuti, secondi della generazione di un certo dato Beh, il nome potrebbe anche in qualche modo raccontare di cosa si tratta.In realtà c'è un altro problema su questo nome.Però di per sé è un nome impronunciabile.Immaginate di andare all'anagrafe, registrare vostro figlio e chiamarlo a "zcdbdg" o una roba del genere.Sarebbe impossibile poi chiamarlo durante la vita normale.E quindi cosa succederebbe? probabilmente si eviterebbe di chiamarlo o si userebbe un altro nome o comunque ci sarebbe una non comprensione nel processo comunicativo Un altro suggerimento che dà Uncle Bob nel suo libro è quello di suggerire dei nomi ricercabili immaginiamo di dare il nome della nostra variabile "e" nel momento in cui io devo utilizzare le funzioni di ricerca perché voglio vedere le informazioni relative a quella variabile e scrivo "e" nella casellina di ricerca probabilmente mi evidenzia qualunque cosa ci sta su quel file.Bene, se invece do un nome concreto, un nome che ha un significato, un nome ricercabile nel mio codice, beh, diventa più facile anche interagirci.Lui suggerisce inoltre anche di evitare le codifiche.Quante volte utilizziamo delle sigle che comunque vanno decodificate? il processo di decodifica presuppone comunque uno sforzo mentale e se state già facendo un ragionamento nel leggere, provare a capire qual è il processo della vostra applicazione quindi magari avete scritto questa applicazione due mesi fa oppure siete dei new entry nel team state provando a capire il flow dell'applicazione vedete queste sigle dovete interrompere la comprensione del flow per andare a decodificare queste sigle e questo diventa comunque una sorta di interruzione nel processo di ragionamento e comunque un ostacolo che possiamo evitare a priori evitando le sigle sempre parlando di sigle o comunque di nomi che hanno degli elementi che potrebbero essere omessi mi viene in mente anche la notazione ungherese.Cosa prevedeva la notazione ungherese? Che era una notazione utilizzata nei vecchi linguaggi di programmazione a partire dal FORTRAN.Prevedeva il fatto che nel nome della variabile in qualche modo venisse indicato il tipo.Quindi il nome della variabile conteneva da una parte il significato, dall'altra il tipo.ma questa operazione è superflua nei moderni editor.Questo perché i moderni editor, se tu evidenzi il valore o la variabile stessa, sanno loro a dirti di che tipo si tratta.E se dovessi fare un parallelismo mi viene da pensare, immaginate di chiamare vostro figlio Mario Italiano, o Mario Persona, o Mario Uomo.Cioè, non c'è bisogno di andare a indicare il tipo, non serve, è superfluo, basta il nome e poi il resto lo deduci dal contesto.Un'altra cosa molto importante è quella di evitare prefissi o suffissi.Oppure delle variabili monolettera, come vi ho detto prima, no? Quando vi ho parlato delle variabili ricercabili.variabili monolettera A è molto difficile passare un significato con una sola lettera e poi immaginate di chiamare una persona A o E.Inoltre vi devo però anche ammettere che ci sono per tradizione delle situazioni dove le variabili monolettera sono utili.Queste variabili monolettera sono utili per esempio dove vengono utilizzate per convenzione.Mi viene in mente il ciclo for dove abbiamo appunto la variabile "i" come iteratore.Tutti i programmi sanno la variabile "i" che contiene appunto l'iterazione.Tutti sanno che "i" indica quello.Chiunque programmi è cosciente di quella informazione.Quindi la necessità è quella di dare appunto dei nomi parlanti.Queste sono, diciamo, alcune delle regole che Bob Martin ha indicato nel suo libro.In realtà ce ne sarebbero tante altre, però se già partissimo, cercando di rispettare il più possibile queste regolette e cercando di ricordarci quello che ha scritto George Orwell nelle "Rules of Naming", beh, sicuramente faremo un codice decisamente migliore di quello che quotidianamente facciamo.Io sono sicuro che voi siete dei bravissimi programmatori e probabilmente non avete bisogno di queste regolette, però io ogni tanto, anche per me stesso, me le riguardo, perché spesso, preso dal flow di programmazione, beh, qualcosina me la dimentico, oppure mi faccio rapire dalle parole, come dice George Orwell, e tralascio i significati.beh, capita.Non possiamo essere sempre al massimo della concentrazione o comunque focalizzati solo col naming.In quel caso, beh, dovremmo comportarci un po' come i Boy Scout.Nel momento in cui prendiamo in mano il codice dovremmo provare a lasciare quello che prendiamo in mano un pochino più pulito, un pochino più ordinato, un pochino più comprensibile di come l'abbiamo trovato.Anche perché oggi rinominare le variabili diventa sempre più semplice con tool come phpStorm è possibile utilizzando le funzioni di refactoring rinominare grandi lotti di variabili senza rischiare tantissimo.E poi se si è sviluppato usando un approccio test driven design, beh a quel punto basta lanciare la propria suite di test e vedere se fallisce o se va in porto per capire se si è distrutto qualcosa, però prima di lasciarvi mi piacerebbe evidenziarvi anche questo passaggio.Nella scrittura, nella definizione dei nomi delle variabili dobbiamo anche possibilmente evitare di fare simpatici perché Bob Martin dice nel suo libro appunto che gli è capitato di leggere delle funzioni delete chiamate con nomi del tipo super mega bomba distruttiva questo è il nome di una funzione che deve andare a eliminare qualcosa va bene siamo simpaticissimi a chiamare una funzione in questo modo però diciamo che non siamo il massimo della chiarezza detto questo vi dico che appunto utilizzando un minimo di refactoring e le funzioni di rinominazione dei nostri editor? Beh probabilmente ridurremo i WTF per minute quindi aumenteremo l'indice di qualità del nostro codice.E anche per oggi è tutto.Nelle prossime puntate, a partire da questa cercherò di alleggerirmi un po' di più perché mi sono reso conto che le puntate precedenti mezz'ora di Mauro che parla forse erano un pochino pesanti quindi cercheremo di essere un pochino più leggeri ma senza ridurre o sacrificare il significato.Anche per oggi è tutto da UnaLioneBarricata.Vi ricordo che se vi fa piacere e trovate utile questo podcast potete iscrivervi con il vostro client di podcast direttamente appunto cliccando sul pulsantino più in modo da ricevere ogni settimana la nuova puntata e le notifiche push e se vi fa piacere potete contattarmi all'indirizzo email info@gitbar.it oppure via twitter @brenrepo per il resto non so cosa dirvi non ho ancora deciso l'argomento del prossimo episodio ma sarà sicuramente una cosa interessante un salutone da lione e alla prossima settimana ciao GitBar, il circolo dei fullstack 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 fullstack dev.- [Musica]
