Gironi infernali per sviluppatori (risposta a Mich Murabito di DevelopersLife)

Nascondi

Quella che segue è una trascrizione automatica dell'episodio.

Pensieri in codice. Idee dal mondo del software a cura di Valerio Galano. Salve a tutti e ben ritrovati su Pensieri in codice. Oggi vi parlerò della mia personale classifica dei gironi dell’inferno dedicati agli sviluppatori. Vi racconterò quindi quali sono i cinque peggiori comportamenti che un developer può mettere in atto secondo me e quale ritengo che dovrebbe essere la punizione dantesca nell’aldilà. Prima di procedere però ci tengo a dirvi che questo episodio è una risposta al video di Mitch Murabito nel quale lui illustra i suoi gironi dell’inferno per developers. Ho infatti visto il suo video qualche giorno fa e nel finale lui invita i suoi spettatori a condividere la propria lista di gironi e ho pensato che potesse essere carino farlo attraverso un episodio di Pensieri in codice. Se già non conosceste Mitch per una delle innumerevoli conferenze sull’informatica alle quali ha preso parte come speaker, sappiate che si tratta di uno sviluppatore di professione che da qualche mese ha aperto anche un canale youtube chiamato Developers Life. In questo canale si parla di tanti aspetti legati alla vita pratica dello sviluppatore, comportamenti da tenere o da evitare, situazioni che si possono verificare o meno e consigli su come migliorare la propria professionalità. Insomma se siete sviluppatori o aspiranti tali questo è uno di quei canali youtube che assolutamente non potete perdere. Io vi lascio il link in descrizione, voi iscrivetevi e vi assicuro che non ve ne pentirete. Al quinto posto della mia personalissima classifica sui gironi infernali degli sviluppatori c’è il girone di quelli che usano un’infinità di if indentati o a cascata. Ora capiamoci, gli if servono e vanno usati quando necessario. Cioè avete presente quelle catene infinite di if else che potrebbero essere facilmente sostituite con uno switch? O quelle sequenze di if uno dentro l’altro che a guardar bene non sono necessarie ma comunque spingono il codice indentandolo verso destra fino a farlo uscire dal monitor? Sì ok lo so non si tratta di questo comportamento poi così terribile ma io personalmente lo odio. Quindi? Per quel che mi riguarda in questo girone gli sviluppatori dannati saranno costretti continuamente a scrivere algoritmi con migliaia e migliaia di condizioni annidate utilizzando solo un editor senza indentazione automatica senza folding e senza evidenziazione dei costrutti. Così imparano. Al quarto posto poi c’è il girone di quelli che iniziano a scrivere il codice senza avere chiari i requisiti. Secondo loro e secondo anche molti dei loro clienti in questo modo si risparmia tempo ma in informatica non c’è cosa più falsa. Iniziare a sviluppare senza sapere bene cosa equivale ad affidarsi alla fortuna. Il lavoro fatto potrebbe essere completamente inutile e da rifare. In questo girone le anime dannate sviluppano un software di giorno in giorno ma ogni mattina viene lanciato uno speciale cron che rivoluziona completamente tutti i requisiti. Il terzo posto è occupato dal girone di quelli che risolvono tutti i problemi nello stesso modo. Non importa il tempo o le risorse che hanno a disposizione non importa che esistano soluzioni già pronte questi sviluppatori sanno utilizzare una e una sola tecnologia e qualsiasi siano le richieste le soddisfano utilizzando quell’unica freccia al loro arco. In questo girone i dannati passano il loro tempo a programmare software con un pc che ha una tastiera fatta di soli due tasti enormi uno 0 e un 1 così visto che hanno scelto di fare tutto in un unico modo tanto vale che lo facciano in binario. Al secondo posto c’è il girone di quelli che scelgono nomi di variabili e di funzioni che non hanno senso. Scrivere il codice utilizzando nomi come xxx, pluto, pippo, iii o cose del genere innanzitutto denota scarso rispetto per chi sarà costretto a manutenere quel codice che sia il programmatore stesso nel futuro o qualcun altro. Oltre a ciò c’è la concreta possibilità che chi ha scritto quel codice non ne abbia capito bene il senso. In questo girone tutti i dannati saranno costretti a programmare utilizzando un solo carattere per tutti i nomi sia di funzioni che di variabili quindi se hanno scelto il carattere x ad esempio tutto il loro codice sarà composto di variabili e funzioni che si chiamano xxxxxx e così via. Infine in vetta alla classifica al primo posto c’è il girone di quelli che non usano un sistema di versioning. Sì lo so che non ci credete ma esistono e le ho anche incontrati. Mi rifiuto di spiegare perché il sistema di versioning sia indispensabile però vi dico che in questo girone i dannati sono costretti a fare commit di ogni singolo carattere che aggiungono e per di più questi commit sono anche soggetti a validazione di sintassi quindi qualsiasi errore gli causa il riggetto del commit. Bene spero che questa piccola lista scherzosa sia stata di vostro gradimento e come al solito vi invito a condividere anche il vostro pensiero e perché no la vostra lista utilizzando i commenti il gruppo telegram ormai l’ho ripetuto alla nausea sapete che c’è tutto in descrizione. Ora però vorrei condividere con voi anche alcune riflessioni che guardare il video di Mitch e scrivere la scaletta per questo episodio mi hanno suscitato. Innanzitutto non vi faccio spoiler ma vi dico che quando ascolterete quando guarderete anzi il video di Mitch vi renderete conto che le nostre liste sono molto diverse e questo può sembrare strano soprattutto considerando che anche se utilizziamo magari tecnologie differenti sia io che Mitch siamo entrambi sviluppatori. Beh la spiegazione che mi sono dato io per queste differenze sta nel fatto che abbiamo background ed esperienze molto differenti. Mitch infatti lavora in un contesto aziendale dove ci sono determinati problemi ma al tempo stesso altri problemi vengono mitigati ad esempio dalle procedure e dagli accordi interni all’azienda. Io invece ho quasi sempre lavorato come freelance il che comporta cambiare spesso progetto cambiare spesso cliente e persone con cui si collabora da una parte quindi c’è una maggiore flessibilità e un minore impatto di determinati problemi che invece sono più importanti in un contesto aziendale ma al tempo stesso diventa difficile predire la qualità del progetto sul quale ci si troverà a lavorare e molto spesso ci si trova ad unirsi a progetti già in corsa o a dover estendere software già iniziati da altri. Per capire quello che sto cercando di dire consideriamo ad esempio il primo posto della mia classifica. In un contesto aziendale soprattutto se si parla di aziende nel campo dell’IT è veramente raro trovarsi a manipolare un progetto che non sia sotto un qualche sistema di versioning. Per un freelance invece può capitare di trovarsi per le mani il progetto iniziato per quello stesso cliente da un altro consulente che magari non utilizzava versioning o semplicemente non lo vuole fornire. Al di là quindi delle battute di spirito secondo me quando si valuta un software o un codice va sempre tenuto in considerazione il contesto nel quale esso è stato scritto. Voglio dire a tutti noi è capitato di scovare qualche codice dell’orrore in qualche progetto e se ne può anche ridere ma in generale trovo scorretto giudicare colui che ha scritto quel codice senza essere a conoscenza di tutti i dettagli della situazione. Voglio dire magari la persona che ha scritto il codice è veramente uno scarso programmatore oppure è possibile che in quel momento avesse pochissimo tempo per scrivere quell’algoritmo. Magari con più tempo a disposizione avrebbe potuto fare meglio o ancora in quel momento poteva non essere a conoscenza di tutta una serie di dettagli che sono poi venuti fuori col tempo o magari ancora le richieste del cliente sono cambiate o erano confuse. Insomma la lista è molto lunga ma in generale questo è il motivo per cui quando mi trovo a lavorare con un nuovo cliente o quando un vecchio cliente mi chiede un giudizio su di un progetto di qualche altro consulente o di un’azienda difficilmente me la sento di sparare a zero su quelli che possono essere gli errori di stile o altro. Al massimo quello che solitamente faccio è giudicare il codice ma non lo sviluppatore nel senso che posso dopo una certa analisi tirare fuori la lista degli errori dei bug cioè della serie questo calcolo è sbagliato oppure qui può esserci un crash o c’è un errore di logica nel flusso ma in generale cerco sempre di evitare di dare giudizi sullo stile del codice o sulla scelta implementativa del progetto e con questo non vuol dire che non propongo delle migliorie semplicemente evito quei commenti del tipo questa scelta è sbagliata o questo codice fa schifo e il motivo è appunto che ci sono degli aspetti soggettivi in un giudizio del genere e non essendo io stato presente e non conoscendo le condizioni nelle quali è stato svolto il lavoro non trovo corretto essere troppo duro nel giudizio d’altronde potrei io stesso trovarmi nelle stesse condizioni ed essere costretto a fare un lavoro non del tutto perfetto e se dovesse capitare sinceramente preferirei che il primo venuto evitasse di sparare a zero senza conoscere la situazione bene anche oggi siamo giunti al termine di questo episodio spero come al solito che l’argomento vi sia piaciuto e vi ricordo che queste sono le mie opinioni ma che io sono anche interessato a conoscere le vostre quindi dopo esservi iscritti al canale di mich developers life lasciate un commento e magari condividete questo episodio con qualcuno a cui pensate possa interessare per me il podcast è un momento di condivisione ma anche di apprendimento quindi ci tengo a raggiungere il maggior numero di persone possibili anche per avere indietro un feedback questo è l’unico modo in cui io potrò crescere come creatore di contenuti e di conseguenza far crescere questo progetto detto questo direi che per oggi non c’è altro e non mi resta che salutarvi e ricordarvi che un informatico risolve problemi a volte anche usando il computer

Nascondi