Il porting è un termine molto usato. Generalmente significa adattare un grande blocco di codice a qualcos'altro. L'opposto di "porting" è "riscrittura". Quindi, la parte importante del processo di porting è che si sta cercando di risparmiare un sacco di tempo quando si vuole spostare il codice.
Rileggendo questo è molto non specifico, e questo è il problema con un termine che è usato così ampiamente nella nostra professione. Quindi, cerchiamo di essere specifici:
Diciamo che ho scritto un gioco in C++ destinato ai telefoni Android. Funziona alla grande e diventa popolare e così ricevo richieste per lo stesso gioco sui telefoni Apple. Ora ho un paio di scelte. Potrei riscrivere il gioco da zero usando gli strumenti di sviluppo Apple, o potrei provare a portare il mio codice su Apple. Devo guardare la quantità di lavoro che è coinvolta in ciascuna di queste scelte e prendere una decisione su quale di queste mi costerà meno soldi mentre fornirà un nuovo flusso di reddito sui telefoni Apple. Se decido di supportare i telefoni basati su Windows avrò la stessa scelta.
Il porting può essere un processo molto semplice (per esempio, se sto passando da una tecnologia di chip ad un'altra, ma rimanendo nello stesso sistema operativo potrebbe essere facile come ottenere un cross-compiler e correggere qualsiasi bug possa emergere), o potrebbe essere un processo molto difficile.
Porting tra due ambienti completamente estranei come Windows desktop ad Android Phone ha diversi ostacoli da superare. In primo luogo, le interfacce utente di questi due sono enormemente diverse e molte delle assunzioni che la vostra applicazione fa quando è in esecuzione sul desktop di Windows sono completamente non valide su un telefono (non ho bisogno di entrare nei dettagli qui, giusto? le differenze sono ovvie).
In secondo luogo, gli strumenti sono molto diversi (i compilatori, gli installatori, le catene di distribuzione, ecc) quindi c'è probabilmente una curva di apprendimento per il porting tra qualsiasi due ambienti molto diversi. Si può anche assumere un intero gruppo di sviluppatori che capiscano specificamente il nuovo ambiente per aiutare a capire i problemi (o anche uno specialista di porting).
In terzo luogo, le limitazioni fisiche dell'esecuzione in un telefono (meno memoria, schermo più piccolo, nessun mouse, supporto parziale della tastiera) devono essere gestite.
Molte aziende che hanno fatto questa scelta hanno deciso che riscrivere l'applicazione per il nuovo ambiente è il modo più economico di procedere. Spesso possono prendere un nucleo dell'applicazione e trasformarlo in API remote o in librerie distribuibili (il che significa che hanno estratto un pezzo più piccolo e portato solo quello) e poi riscrivere il resto dell'applicazione (per esempio, un gioco potrebbe estrarre il suo motore fisico in una libreria, ma riscrivere tutto il codice dell'interfaccia utente).
Il porting è un affare così grande che ci sono aziende che si guadagnano da vivere fornendo un ambiente tampone in cui scrivere la propria applicazione. Si sono presi la briga di creare un ambiente che possono garantire (entro certi limiti) permetterà alla vostra applicazione di funzionare essenzialmente invariata su un dato insieme di piattaforme (anche attraverso quelle diverse come quelle che ho proposto sopra). Questi ambienti saranno sempre un compromesso e spesso comporteranno limitazioni molto specifiche per la vostra applicazione (quelle cose che non possono essere implementate o simulate su tutte le piattaforme supportate). Se si può vivere entro questi limiti, questi ambienti possono essere fantastici, ma se si combatte con le limitazioni possono essere un incubo.