Il porting di applicativi si riferisce al trasferimento di un applicativo su una piattaforma diversa da quella per la quale e' stato originariamente concepito e sulla quale funziona.
Il porting quasi sempre implica il possesso del codice sorgente dell'applicativo e la sua ricompilazione.
Se l'applicativo e' di rete, per piattaforma si deve intendere non solo il calcolatore ed il sistema operativo, ma tutta l'infrastruttura aggiuntiva di rete come formalizzata dal modello OSI.
Le probabilita' di successo del porting sono innanzi tutto tanto piu' elevate quanto maggire e' la rassomiglianza della piattaforma target a quella di origine.
Se si tratta di usare modelli di riferimento software diversi, p.es. di passare un applicativo con determinate funzionalita' utente dal modello Internet al modello NetBIOS o viceversa, e' necessario addirittura riprogettare l'applicativo.
Se il modello software e' lo stesso. il porting e' tanto piu' facile quanto piu' le differenze tra origine e target si trovano a strati bassi del modello.
Per esempio il porting di un applicativo funzionante in reti CSMA/CD a rete con accesso ATM richiede solo la generazione di nuovi device driver MAC. Il porting di un applicativo progettato per TCP a protocollo UDP richiede un cambiamento delle funzioni per l'uso dei socket. Il porting da applicativo che usa lo ONC RPC a DCE RPC o viceversa richiede l'uso di nuovi files di definizione protocollo, nuove funzioni all'interno dei programmi server e client e nuove librerie di RPC.
Un caso frequente e' quello di manutenzione dell'intera catasta di protocolli e di diversi sistemi operativi tra l'origine e il target.
Una variazione e' il porting tra origine e target appartenenti a versioni diverse dello stesso sistema operativo.
Il porting e' tanto piu' facile quanto piu':
Un esempio e' il porting tra UNIX e Windows NT. L'interfaccia socket e' (teoricamente) molto simile; il sistema NT (teoricamente) supporta lo standard POSIX. Il porting (teoricamente) non dovrebbe essere molto difficoltoso se il programma sorgente era scritto secondo rigidi canoni POSIX.
E' difficile enfatizzare a sufficienza l'importanza degli standard. Un caso sempre piu' frequente e' lo upgrading, cioe' il porting ad una nuova versione dello stesso sistema operativo o ad una nuova versione dei protocolli di rete.
L'avvento di nuove versioni genera molto interesse mondiale per le attivita' di upgrade e vengono forniti da piu' enti nuove versioni di programmi, utilities, librerie, ecc. Questi oggetti sono tanto piu' utili quanto piu' il nostro codice che deve subire lo upgrading e' vicino agli standard.
Una versione di upgrading e' la manutenzione del codice, anche detta 'debugging preventivo' o 'miglioramento della qualita'', spesso eseguita da personale del tutto diverso da quello di programmazione originale.
Un'osservazione: in generale il Rapid Application Development o il prototiping sono nemici del porting e dello upgrading.
Vi sono soluzioni di porting tappabuchi, a volte dette 'strumenti di porting'. Consistono nel riproporre sul sistema operativo target un ambiente che emula il comportamento del sistema operativo origine ed entro il quale l'applicativo originale gira senza modifiche. L'emulatore solitamente peggiora le prestazioni dell'applicativo, del sistema operativo nuovo, e non e' quasi mai un emulatore fedele al 100%.
Il debugging e' l'attivita' di detezione e riparazione di bugs (bachi) - anomalie di funzionamento del codice.
Le anomalie sono state generate per errore, e l'errore si trova:
Gli ultimi casi sono i piu' facili da risolvere: buttare gli altri applicativi, colpevoli, cambiare il sistema operativo, cambiare il compilatore. Quasi sempre una o piu' di queste strade non sono praticabili, ma in tal caso compiere il debugging e/o la modifica del nostro applicativo puo' non avere senso: siamo in una situazione perdente.
Se l'errore e' negli algoritmi usati, occorre apportare cambiamenti sostanziali al programma, con dispendi notevoli. Esempi sono l'uso di buble-sort o il famigerato baco dell'anno 2000. Se l'errore e' nel modello teorico occorre ripensare l'applicativo.
Con un po' di fortuna gli errori (mai assumere che il colpevole di un qualsiasi malfunzionamento sia un solo errore) sono nel codice sorgente, e sono dovuti a:
L'errore puo' essere bloccante: l'applicativo proprio fallisce a compiere un'operazione essenziale; oppure puo' essere non bloccante. In tal caso alle volte e' possibile aggiungere codice sorgente che modifica il comportamento dell'applicativo senza togliere l'errore originale: questo viene chiamato un workaround o un kludge.
La soluzione definitiva e' di togliere l'errore dal codice. Viene affrontata in piu' fasi:
La difesa dagli errori e' la prevenzione, con programmazione difensiva:
Si stima che del 100% dello sforzo di programmazione di un applicativo, idealmente 30%/30%/30% debbano andare alla progettazione, codifica, testing, e solo il 10% debba servire per il debugging. Al giorno d'oggi piu' verosimilmente il 10% va alla progettazione, il 20% alla codifica, meno del 5% al testing e tutto il rimanente al debugging (piu' del 65%).
Dovrebbero esistere anche standard di produzione.