Programmazione del tempo di programmazione per il porting di un programma

Question

Sto lavorando su un programma di grandi dimensioni che ha un'API della GUI astratta. È molto basato sulla GUI, molte finestre di dialogo e alcune brutte funzionalità che si basano molto sul flusso di messaggi della GUI (sequenze corrette di messa a fuoco/mouse/gestione attiva ecc.) - non facile da portare

Ora voglio portarlo dal FOX Toolkit attualmente in uso al Cocoa/MFC nativo.

Mi concedo un periodo di tempo fino alla fine dell'anno, ma il mio lavoro principale sarà quello di continuare il lavoro di sviluppo con il toolkit esistente, ma non è previsto alcun rilascio per i clienti finali prima che entrambe le attività vengano eseguite.

La mia domanda è come devo passare il mio tempo?

1. smettere di lavorare sul programma principale e fare una porta al 90% (circa 3 mesi) del GUI prima
2. Splitting tutto in piccoli sessioni di un mese ciascuno.
3. Assegnazione di lunedì/martedì al progetto GUI e il resto della settimana per l'app .
4. Prima di terminare con l'App, quindi la porta.

Penso che ci siano tre argomenti che ho bisogno di bilanciare.

1. Motivazione, voglio vedere qualcosa da fare su entrambi i progetti
2. Cervello Overflow ingresso, entrambe le attività richiedono un sacco di informazioni di dettaglio nel mio cervello e, a volte è troppo è appena sufficiente.
3. Immagino che il porting sia eseguito in modo tale che il porting richiederebbe anche molte modifiche al codice nel codice esistente e il nuovo codice che sarà nel frattempo.

Answer 1

Se non vi è alcuna versione pianificata per i clienti, si ha il lusso di poter strutturare il lavoro esattamente come si desidera.

La mia prima impressione è che mettere lo sforzo per finire l'app sulla piattaforma corrente, quando si sta per buttare via quel codice, è il tempo almeno parzialmente sprecato (si ottiene un po 'di apprendimento ma il codice finale è inutile).

Personalmente parcheerei la versione esistente e ricomincio con la riscrittura Cocoa.

Per prima cosa lo dividerei in blocchi funzionali e visualizzarli come una versione agile. Questi dovrebbero essere focalizzati sulle attività e sulle funzioni dell'utente finale e includere sia la GUI che il back-end per questi.

(Il motivo per cui non mi piace l'idea di utilizzare la GUI e la logica dell'app separatamente è che non sono separati. Come parte di una riscrittura potrebbero esserci delle opportunità per apportare miglioramenti e questo è più difficile se si ' dobbiamo mantenerli compatibili: una riscrittura è un'opportunità per apportare cambiamenti fondamentali che spesso non arrivano - lo prendo io).

Lavorare attraverso i blocchi funzionali uno a uno, portandolo a uno stato completo e rilasciabile prima di passare a quello successivo. Questo ti darà sia il senso del successo che la capacità di misurare il progresso. Significa anche che se un'implementazione emerge dal nulla, hai dei blocchi utilizzabili completi.

Inoltre, concentrandosi sulle attività end-to-end, si spera che il materiale di overflow mentale sia ridotto al minimo poiché si lavora sempre all'interno di una singola area specifica piuttosto che attraverso l'app.

Answer 2

Vorrei finire prima l'app, quindi portarla. IMO, meno progetti gestisci allo stesso tempo, più sei efficace.

Answer 3

Dipende davvero da cosa ti senti a tuo agio.

Personalmente, vorrei iniziare il porting ora - un sottosistema/pezzo alla volta. Non è necessario che tutto venga portato in un solo colpo. Potresti scoprire che le basi della tua applicazione devono essere riscritte per supportare il porting. Se si attende fino alla fine dell'applicazione per eseguire la porta, è possibile che si risulti comunque la riscrittura di ampie porzioni dell'app. Quindi mi piacerebbe iniziare il porting delle librerie di supporto e delle funzionalità di base, quindi lavorare lentamente ai margini.

Nel frattempo, ogni volta che si introduce una nuova classe sul non-porto, assicurarsi che sia portatile fin dall'inizio.

Answer 4

Ho iniziato con un mese ciascuno per MFC, Cocoa e GTK per fare le cose di base. E dopo questa settimana, cicli tra i sistemi per ottenere il livello di astrazione della GUI. Non ho ancora toccato l'applicazione stessa.

Questo è stato abbastanza efficiente. Anche quando la complessità di MFC, Cocoa e GTK rende il tipico lunedì mattina quando faccio la commutazione anche peggio.

E ora so molto come devo cambiare la mia domanda. Porterò il toolkit GUI prima di continuare ad aggiungere funzionalità perché, come già detto da Jon, avrei dovuto scrivere parti due volte.