Avete scritto un programma. Che sia un’applicazione standalone, o un’applicazione web, o un’applicazione mobile, in questo caso non fa differenza. L’avete scritto, e funziona. Poi lo trasportate su una macchina diversa, e non funziona più.
Questo scenario mi è capitato innumerevoli volte durante esami o consulenze con studenti. Persone stupite, che si meravigliano che il loro gioiello non funzioni al primo colpo, e che iniziano una serie di divinazioni cabalistiche incolpando il compilatore, le librerie, il sistema operativo, il browser, la rete, la tastiera, o il vicino di casa. Oppure persone sconvolte dal fatto che, dopo aver copiato un file, occorra mettere mano a innumerevoli impostazioni (path, password, servizi, proxy, firewall, …) affinché tutto funzioni a dovere, il che richiede molto tempo ed una buona dose di competenza sugli ingredienti di cui l’applicazione è composta.
È il porting, bellezza. L’arte di fare funzionare la stessa cosa su una macchina diversa. E richiede di solito due attività a cui molti non sono preparati, specie se alle prime armi:
- pensare in avanti, anticipando i problemi, parametrizzando le applicazioni, e facendo del testing su macchine diverse già in fase di sviluppo
- ricordarsi che anche i migliori registi, attori, scenografi, direttori d’orchestra o musicisti fanno sempre una prova generale, nella quale provano, il giorno prima o la settimana prima, il loro pezzo o la loro performance nel contesto in cui dovrà essere realizzata realmente. Perché chi viene a sostenere un esame non installa il giorno prima il software sulla stessa macchina su cui lo dovrà dimostrare?
Un consiglio per tutti: visto che all’ultimo momento gli imprevisti ci saranno sempre (il mitico “effetto demo”), cerchiamo di premunirci in anticipo, con opportune prove generali, non lasciando il successo della performance alla fortuna del momento.
Nessun commento:
Posta un commento