Programmare - Rant

Nella mia vita professionale, ho lavorato in molti progetti, ciascuno con la sua impostazione caratteristica. Alcuni progetti da solo, altri progetti in collaborazione con colleghi/soci e in altri ancora con persone sconosciute (nel senso che mettevo le zampe nel codice scritto da altri).

Quando iniziai con gli IDE c'era VS6, usavo Windows, programmazione in C/C++ (entrambi i linguaggi).
Non conoscevo ancora programmazione al di fuori di MS-DOS (Basic e Pascal, principalmente) e Windows (Basic, C e C++).

Mi ricordo che quando passai dal Borland Turbo Pascal 7, che usavo a scuola, a VS6 rimasi molto sorpreso dalle potenzialità e da ciò che era possibile fare.
Però

Già in quel periodo sentivo che c'era una nota stonata, infatti per molti lavori mi trovavo a scrivere direttamente nei file DSP e DSW per fare tutto ciò che l'IDE non riusciva a fare. La nota stonata non era tanto il fatto che accedessi a questi file quando in teoria avrebbero dovuto rimanere opachi, quanto i motivi che mi spingevano a codeste operazioni. Motivi neppure tanto esotici quali la clonazione di un progetto per avere più eseguibili con le stesse impostazioni di base.

In quel periodo la mia esperienza era ancora limitata, quindi avevo bollato la cosa come semplice sensazione.

Più avanti ho iniziato ad ampliare la mia base di esperienza lavorando sempre più con altri linguaggi (e altri sistemi al di fuori di Windows) e approfondendo metodi di sviluppo quali l'uso dei makefile che avevo visto solo marginalmente poiché Visual Studio già faceva tutto quello che serviva. O almeno così pensavo.

Se sei abituato a camminare usare la bicicletta è un salto notevole, ma se sali in sella ad una moto e impari a guidarla, ritornare alla bicicletta risulta estremamente traumatico.

La nota stonata che sentivo ha iniziato a diventare un rumore assordante di decine di strumenti che vengono suonati a caso da altrettanti musicisti che non si ascoltano tra loro.

Per questioni di lavoro sto lavorando su dei progetti sotto Windows con Visual Studio (2010 e 2008). La versione poco importa perché quello che in questo momento funge da palla al piede è il concetto alla base degli IDE, ossia che chi li ha sviluppati ha pensato ad un tipo di utilizzo e se tu hai bisogno di un metodo differente devi imprecare non poco e scontrarti con una serie di malfunzionamenti in alcuni casi oltre il livello del ridicolo.

Ad esempio la condivisione dei file sorgente tra i progetti di uno stesso lavoro, l'organizzazione in directory dei file sorgente (necessaria quando lavori con 50+ file), l'impossibilità (ancora) di poter fare un confronto delle impostazioni dei progetti se non guardando i file XML o cliccare come un ossesso tra varie finestre (almeno rispetto a prima non sei obbligato a chiudere e riaprire le finestre), l'impossibilità di lavorare con codice generato perché non sono state previste regole di dipendenza personalizzate aggiuntive, il fatto che l'IDE ha delle discrepanze logiche per cui cerca file collaterali (come i resx) nella directory dove si trova il sorgente principale, ma se lo vuole scrivere lo mette nella directory base del progetto per poi impazzire e non riuscire né a trovarlo (non è dove si aspetta) o crearlo (si trova già dove lo vuole creare, che è diverso da dove lo andrà a cercare).

Cancelli un file usando l'IDE stesso, non puoi ricrearlo perché lo vede come se ci fosse ancora.

Insomma, su un'ora di lavoro con Visual Studio più di mezz'ora se ne va per fermare, modificare a mano file, riavviare l'ambiente, click a profusione per includere un file come link a 5 progetti (saranno di più e rabbrividisco). Con tutto quello che impatta sul discorso concentrazione.

Il tutto senza considerare le cache che l'IDE si tiene in pancia.
Infatti modificando un file comune (che tutti linkano) il progetto principale vede le modifiche nell'Intellisense, gli altri no e generano una serie di falsi errori fintanto che non si procede con una compilazione completa (che non è a tempo zero).

Però il cliente richiede Visual Studio e non posso lavorare in altro modo.
Per fortuna, in tutto questo mi viene in aiuto git e una marea di backup che faccio prima di particolari operazioni (per alcune delle quali mi scrivo programmi ad-hoc usa e getta, impiegando un ottavo del tempo che impiegherei per fare la stessa operazione attraverso l'IDE).

Firmato:
Campagna per l'abolizione degli IDE

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 :-)