Entropia ed altre tristi storie di codice scritto a fine progetto.

Entropia

Entropia è un termine utilizzato in fisica ed indica il livello di disordine presente in un determinato sistema. Un sistema si può definire tanto più disordinato maggiore è il numero di informazioni che servono a descriverlo. Esiste inoltre una legge della termodinamica che enuncia come il livello di entropia, nel tempo, sia destinato ad aumentare.

Come sviluppatori, conoscere ed aver interiorizzato il concetto di entropia in un progetto può aiutarci a scrivere codice migliore. Quindi vi prego sedetevi comodi, allacciate le vostre cinture e prepararvi ad un, breve ma intenso, viaggio nella mente umana.

Come nasce il disordine

Da sviluppatore, ammetto di appartenere ad una razza davvero strana, ogni inizio progetto segue lo stesso copione: ci ripromettiamo che questa sarà la volta giusta, che riusciremo a tenere tutto in ordine, a prova di bug e che il prodotto finale sarà manutenibile nel tempo.

Poi passa qualche settimana e senza accorgercene e ci ritroviamo con un progetto che è diventato un disastro: c’è qualche bug ma non sappiamo da dove provenga; c’è del codice duplicato sparso nell'applicativo; e quel metodo sappiamo che non è scritto secondo le guidelines… ma funziona così bene che sarebbe un peccato rimpiazzarlo!

Insomma il livello di disordine nel progetto è diventato tale che servirebbe proprio un bel refactoring. Purtroppo però siamo indietro con le scadenze ed il cliente ha anche chiesto delle modifiche urgenti.

Quindi anche questa volta, forse, il progetto giusto sarà il prossimo…

Ma come nasce il disordine?
La risposta è tutt'altro che semplice, ma forse, la teoria delle finestre rotte può venirci in aiuto.

L’entropia può nascere per una finestra rotta, occhio!

La teoria delle finestre rotte

Nel 1969 il professor Philip Zimbardo condusse un esperimento di psicologia sociale. Egli lasciò due automobili identiche, stessa marca, modello e colore abbandonate in strada, una nel Bronx, zona povera e conflittuale di New York, l’altra a Palo Alto, città ricca e tranquilla della California.
Lo scenario era quindi quello di due identiche auto abbandonate in due quartieri con tipologie molto diverse di abitanti, con una squadra di specialisti in psicologia sociale a studiare il comportamento delle persone in ciascun sito.

Ciò che accadde fu che l’automobile abbandonata nel Bronx cominciò ad essere smantellata in poche ore, perdendo le ruote, il motore, gli specchi, la radio, e così via; tutti i materiali che potevano essere utilizzati vennero rubati e quelli non utilizzabili vennero distrutti.
Al contrario, l’automobile abbandonata a Palo Alto rimase intatta. In tali casi è comune attribuire le cause del crimine alla povertà. Tuttavia, l’esperimento in questione fu proseguito. Dopo una settimana, durante la quale la vettura abbandonata nel Bronx era stata completamente demolita mentre quella a Palo Alto era rimasta intatta, i ricercatori decisero di rompere un vetro della vettura a Palo Alto; in breve tempo i ricercatori assistettero alla stessa dinamica di vandalismo che avevano registrato nel Bronx: furto, violenza e vandalismo ridussero il veicolo lasciato a Palo Alto nello stesso stato di quello abbandonato nel distretto malfamato di New York. (fonte: Wikipedia)

Zimbardo osservò che la maggior parte dei saccheggiatori non avevano affatto l’aspetto di criminali o persone disagiate, sembravano invece persone comuni che mai avremmo classificato come vandali prima di vederle all’opera. Secondo Zimbardo, il finestrino rotto dell’automobile costituisce un indizio di abbandono dell’area, il quale a sua volta è in grado di svegliare in noi peggiori istinti, forti del fatto che difficilmente verremmo giudicati o puniti per le nostre azioni.

Le finestre rotte nel codice

Ora proviamo a portare quest’esperienza nella vita reale. Proviamo a pensare a quando lavoriamo in un progetto di cui abbiamo anche la sola impressione che sia un lavoro sprecato o di bassa qualità. La teoria delle finestre rotte ci spiega come inconsciamente siamo portati a risparmiare le nostre energie e continuare su una strada tracciata male o peggio ancora a tracciarne noi una di pessima fattura.

È infatti una cosa nota che non solo l’entropia di un sistema aumenterà con il tempo, ma che l’energia per ordinare un sistema sia di gran lunga maggiore di quanta ne serva per disordinare o lasciarsi trascinare dalla corrente.

Un programmatore deve essere come una carpa koi

In questi casi dobbiamo ricordarci dell’antica leggenda cinese che racconta di una carpa perseverante che riuscì a risalire una ripida cascata, superando ostacoli e spiriti malvagi per poi essere premiata dagli dei, impressionati da tanto coraggio, che la trasformarono in un grande drago. Allo stesso modo ogni giovane programmatore, nell'intento di migliorare sé stesso, dovrebbe provare a migliorare ogni progetto che tocca cercando di remare contro la corrente che porta alla deriva dell’entropia.

Ovviamente capiterà anche i team migliori di dover mettere una toppa per una presentazione del prodotto o per qualche richiesta urgente del cliente, qui però vi esorto a non lasciare mai finestre rotte nel codice.

Conclusioni

La qualità del codice che scriviamo è dettata, molto più di quanto immaginiamo, da bias cognitivi che possono scaturire da diverse fonti. Tra queste troviamo spicca l’idea che abbiamo del progetto ed il suo prestigio. Saremo portati a fare un buon lavoro per un progetto che sarà largamente usato, mentre al contrario, tenderemo a non spenderci troppo per progetti che reputiamo secondari.

Anche lo stato di un progetto al nostro ingresso, il suo scaffolding, la presenza o meno di una documentazione e di commenti di qualità condiziona il lavoro nostro e degli altri programmatori. E noi, dopo quanto detto in precedenza, vogliamo far trovare agli altri una macchina in perfette condizioni o con qualche finestrino rotto?

L’entropia è destinata ad aumentare ma sta a noi cercare di limitarla. È cosa nota che nelle ultime battute di un progetto gli sviluppatori tendono a “rilassarsi” scrivendo codice con meno qualità rispetto che all'inizio. Qui si annidano i maggiori rischi, perché un programma non termina quasi mai il suo ciclo di vita con la prima release: aggiornamenti, bug fixing e nuove richieste da parte del cliente sono sempre dietro l’angolo. Abbassando la guardia ci troveremo a dover costruire in futuro su una struttura instabile. Sarebbe come fare una maratona e smettere di correre a pochi passi dal traguardo.

Come si può migliorare

• Se possibile prendetevi il tempo necessario per valutare più soluzioni, schematizzarle, e solo dopo scegliere quella che offre il miglior rapporto qualità/tempo di sviluppo.
• Investi del tempo, prima di scrivere il codice, per scrivere una buona documentazione per ogni parte del tuo programma.
  Si dice che il miglior modo per scrivere codice di qualità sia quello di limitarne la scrittura al numero minimo di righe che lo rendano conforme ai requisiti o alla documentazione.
• Nel caso di soluzioni poco eleganti ricordatevi di darne evidenza al responsabile del progetto, o se siete voi stessi al cliente, in modo da poter valutare insieme un successivo intervento di refactoring.
• Lasciate un commento al codice in cui spiegate come si potrebbe risolvere diversamente il problema e chiarite la motivazione delle vostre scelte. Dover scrivere una possibile soluzione mette in moto la vostra capacità di problem solving e una nuova strada potrebbe magicamente apparire!
• Se ti dovessi imbattere in un progetto che ricorda una macchina abbandonata nel Bronx, non prendere anche tu la mazza da baseball per sfasciare tutto, ma armati di buona volontà e, anche se non sarà sempre possibile, dai il massimo per ridurre al minimo l’entropia!

Oggi abbiamo capito come l’entropia sia una componente importante da considerare nei progetti a cui lavoriamo giornalmente, abbiamo anche visto qualche modo per poterla arginare, ma ricordiamoci sempre che il modo migliore per avere progetti stabili nel tempo è sempre quello di lavorare con metodo ed ordine.

Non mi resta che augurarvi un buon coding e buon ordine.