RIP

Quando si dice che la fortuna è cieca, ma la sfortuna ci vede benissimo.

Stasera uno dei miei dischi esterni mi ha detto addio rilasciando un effluvio di circuito integrato cremato.
Posso tentare una resurrezione in estremis se riesco a trovare un altro disco della stessa marca (seagate) per fare un trapianto di logica (la scheda elettronica) e recuperare quindi i dati in esso custoditi (500GB).

E pensare che proprio stasera, prima di rientrare a casa, ho paventato la possibilità di acquistare un altro disco esterno (non Seagate) da usare come base per dei backup.
Alla domanda che mi hanno fatto «Ma ti serve?» avevo risposto ingenuamente «dipende».

Mapporc.

Le 5 fasi del porting e del merge

Sono un programmatore.
E come tale, non posso esimermi dall'essere fuori di testa.

Del mio lavoro non è facile parlarne. Come le prostitute.
Spesso si lavora in locali angusti, fino a ore improponibili. Come le prostitute.
Quando si va dal cliente, è il cliente a pagare. Come le prostitute.
Riceviamo spesso le richieste più assurde con la pretesa di soddisfarle. Come le prostitute.

Ma noi paghiamo le tasse.

Comunque, come ogni altro pazz... ehm programmatore sa, abbracciamo diverse tipologie di lavoro. Una di queste viene chiamata porting, in pratica si tratta di prendere un pezzo di codice scritto da una persona a volte sconosciuta (se va bene) oppure conosciuta ed adattarla ad un sistema già esistente per il quale quella funzione non è stata pensata.
Altre volte capita di fare il merge, ossia unire due pezzi di codice che spesso hanno poco a che fare l'uno con l'altro per ottenere un terzo codice che nelle aspettative dovrebbe riuscire a sostituire in tutto e per tutto i due pezzi originali.

Disquisendo (parole grosse :-) ) con il mio amico e collega Birdack, abbiamo analizzato questi due processi identificando le 5 fasi attraverso cui passa ogni programmatore che si trova davanti ad un'epica impresa simile:

Prima fase, detta della negazione oppure del rifiuto.
In questa fase il programmatore ripete un mantra cercando di convincersi: «No, non si può fare. Non ci sono vantaggi a farlo. Non può funzionare»

Seconda fase, detta della rabbia.
Durante questa fase è meglio stare lontano dal programmatore, in quanto inizia a imprecare e insultare chiunque gli capiti a tiro.

Terza fase, detta del patteggiamento.
In questa fase il programmatore dà il meglio di sé cercando (spesso inutilmente) di trovare strade alternative al lavoro propostogli. In certi casi si possono sentire proposte di costruzione di sottomarini per andare sulla luna.

Quarta fase, detta della depressione.
Fase fondamentale del processo. Il programmatore inizia a tirare le somme e si rende conto che né il rifiuto, né la rabbia e tantomento il patteggiamento hanno portato a risultati. Il lavoro è da fare. E ci si rende conto anche della mastodonticità e la delicatezza del lavoro prima e dei test da fare dopo.

Quinta e ultima fase, detta della rassegnazione o accettazione.
Per i più esperti, la depressione dura poco. Potenza dell'allenamento.
Qui si notano diversi tipi di programmatori, dagli stoici che si caricano le spalle della responsabilità e si mettono al lavoro, fino agli entusiasti (spesso sono quelli che non hanno ancora fatto esperienza) che provano a convincersi che il lavoro è da fare, salvo ritornare alla fase uno e ripetere tutti i passaggi da capo.

Risulta comunque interessante osservare il comportamento della faun... ehm, volevo dire dei programmatori di fronte all'onore (e onere) di codeste operazioni, ma questo sarà oggetto di un'altra analisi.

L'unico grosso vantaggio che abbiamo noi programmatori è che se sbagliamo possiamo sempre ritornare ad un backup precedente (se esiste) e rifare il lavoro da capo.

Pensateci bene la prossima volta che salite in macchina e premete un pulsante per accendere il motore, e rabbrividite :-)