Cross-Platform: sviluppo in parallelo o in serie?

2

Quando si avvia un nuovo progetto software che verrà utilizzato su più piattaforme, come si determina il modo migliore per avviare lo sviluppo? Ti sviluppi per una piattaforma e poi la porta a quella successiva? Cerchi di sviluppare tutte le piattaforme contemporaneamente?

Ad esempio, inizierò a sviluppare un'applicazione per Windows Phone in C #. Gran parte del mio codice potrebbe teoricamente essere riutilizzato con .NET Framework e Silverlight. Tuttavia, trovo che mentre provo a sviluppare su tutte le piattaforme contemporaneamente, il refactoring e la riprogettazione tendono a essere 3 volte più difficili e lenti.

Potrei provare a scrivere la mia app per Windows Phone e poi portarla su altre piattaforme, ma non ho idea di cosa mi aspettino i hairballs, e sembra che ci sarebbe un sacco di potenziale per le decisioni di design di mordermi nel culo solo dopo aver iniziato il porting.

Quindi quale è meglio: sviluppare il codice per tutte le piattaforme contemporaneamente, oppure refactoring e porting su nuove piattaforme uno alla volta? Quali trappole mi aspettano su entrambe le strade?

    
posta Phil 28.05.2012 - 02:06
fonte

4 risposte

3

Panoramica

La mia esperienza consiste nel lavorare con entrambi gli approcci. Dirò più come "parallelo", "serie" e amp; "Incrementale".

Descrizione

Ad esempio, sto progettando un'applicazione. con 10 moduli, e voglio migrare su 3 piattaforme.

Quindi, iniziamo con una singola piattaforma e 3 moduli, di solito i più importanti, come "core" o "sistema".

Quindi, provo a migrare la stessa app. alla seconda piattaforma. A volte aggiungo alcune cose, il nome dei tipi di refactor e ritorna alla piattaforma originale quei cambiamenti.

Esempio (Usando "C #" & "Plain C" come "piattaforme, senza precedenti, potresti pensare in" Linux "," iOS ", Windows Compact Edition):

Ho un parser XML personalizzato in C # (.NET), per fonti pratiche, "una piattaforma", voglio migrarlo a "Plain C", come un'altra "piattaforma".

Ho questo tipo di enumerazione in C #:

enum XMLNodeType
{
  Undefined,
  Declaration,
  Comment,
  SingleTag
  StartTag,
  FinishTag,
  EntityTag,
}

Ma, in "Plain C", per qualche ragione, ho bisogno di prefisso, l'enumerazione equivalente:

enum XMLNodeType
{
  xmlnodeUndefined,
  xmlnodeDeclaration,
  xmlnodeComment,
  xmlnodeSingleTag
  xmlnodeStartTag,
  xmlnodeFinishTag,
  xmlnodeEntityTag,
};

Quindi, decido, che torno al codice "C #" e lo sostituisco con:

enum XMLNodeType
{
  xmlnodeUndefined,
  xmlnodeDeclaration,
  xmlnodeComment,
  xmlnodeSingleTag
  xmlnodeStartTag,
  xmlnodeFinishTag,
  xmlnodeEntityTag,
}

Quando, ho quei 3 moduli in codice equivalente, in 2 piattaforme, aggiungo la migrazione alla terza piattaforma. Di nuovo, a volte, aggiungo cose o refactoring e applico quelle modifiche alle piattaforme precedenti.

Quando ho 3 piattaforme in funzione, inizio ad aggiungere un modulo aggiuntivo a ciascuna piattaforma.

Ripeti il processo, fino a quando tutti i moduli saranno disponibili nelle 3 piattaforme.

Riepilogo

Non provo a fare né a migrare l'intera app, né "seriale" né "parallela". Solo parti di esso. Aggiungi il concetto "incrementale".

Anche se una sezione di codice funziona in una piattaforma, è possibile che durante la migrazione a un altro cambi i nomi dei tipi e applichi le modifiche alla prima destinazione.

    
risposta data 28.05.2012 - 02:21
fonte
2

A meno che non pianifichi di cambiare drasticamente le lingue, tenterei qui il pattern MVC in modo che la maggior parte del codice risieda nel modello e nel controller, che devono essere sviluppati solo una volta. Successivamente, ogni piattaforma può essere una visualizzazione, riducendo notevolmente il codice su ogni piattaforma e il costo di implementazione di nuove funzionalità e modifica di quelle esistenti.

L'ho fatto con un pacchetto software che ho scritto per essere disponibile tramite un normale sito Web html5, un'app per Android e un'app desktop per .NET. La maggior parte del mio codice risiedeva sul server esposto tramite servizi Web ASP.NET con cui ogni client avrebbe interagito. Ha notevolmente semplificato il lavoro che dovevo fare su ciascun client consistente nel presentare i dati e i comandi disponibili dai servizi web.

Se ti ritrovi a dover cambiare il tuo meccanismo di archiviazione da una piattaforma all'altra, è un buon momento per avere un DAL astratto che potrebbe contenere un numero qualsiasi di motori di archiviazione.

    
risposta data 28.05.2012 - 04:11
fonte
1

Quando scrivevo il codice per Windows 32 (x86), WinCE (arm), Linux (x86) e Linux ARM ho trovato che l'unico modo per farlo era in parallelo. C'erano alcune cose che mi hanno davvero aiutato:

  • un sistema di integrazione continua per tutte le piattaforme
  • le build dello sviluppatore possono essere prese a calci per qualsiasi piattaforma da qualsiasi box sviluppatore (rsincronizza il codice sulla piattaforma appropriata ed esegue la build)
  • isolando il codice specifico della piattaforma e creando un livello di macro e librerie per normalizzare le diverse apis
risposta data 28.05.2012 - 05:43
fonte
0

La mia esperienza con questo è C su Linux su x86 & Solaris su SPARC:

Sviluppo su una piattaforma e collaudo su entrambi mentre lavoro. Questo cattura più bug in modo più rapido. Io uso solo due piattaforme che mi costringono a separare il codice dipendente dalla piattaforma dal codice indipendente dalla piattaforma. Successivamente, una volta terminato il programma, inizierò a portarlo su altre piattaforme.

Non ho mai avuto bisogno di usare più di due piattaforme, quindi non ho esperienza con il passaggio finale. Comunque questo sarebbe il mio piano.

    
risposta data 28.05.2012 - 04:05
fonte

Leggi altre domande sui tag