Come organizzare un progetto più grande con diversi sottoprogetti e le loro dipendenze?

Question

Come organizzare un progetto più grande con diversi sottoprogetti e le loro dipendenze?

#1 da (6 voti)

5

Fino ad ora, come sviluppatore di software, ho lavorato principalmente su progetti che erano abbastanza "monolitici", con pochissime dipendenze da altri progetti, senza l'automazione degli edifici (no Make, Ant, Maven, ecc.) e mantenuti su un semplice sistema di controllo della versione (principalmente Subversion) con pochi rami di versioni facilmente gestibili.

Ora insieme ad alcuni amici sto pianificando un progetto che è destinato a girare su più piattaforme (principalmente mobili: Android, iOS, Kindle, Windows, ecc.), quindi scritto in diverse lingue e su diverse piattaforme di sviluppo.

Ciò porterà a molte dipendenze: tutti i progetti che condividono le stesse risorse (ad esempio immagini) o progetti dipendenti l'uno dall'altro (ad esempio, un progetto di libreria Java principale utilizzato da Android e altre implementazioni basate su Java).

Quindi quello di cui ho bisogno sono alcune informazioni di base su come rispondere a domande come: Come sarebbe strutturato il VCS? Sarebbe meglio un client-based o un VCS decentralizzato? Come decidere i sistemi di automazione degli edifici da utilizzare?

Dato che questa è una domanda abbastanza aperta, immagino che per ora sarebbe fantastico se tu potessi indicarmi qualsiasi libro o risorsa web che puoi raccomandare per questo argomento.

organization code-organization

posta RoToRa 09.01.2011 - 16:07

fonte

1 risposta

Leggi altre domande sui tag organization code-organization

Sta bloccando le applet java come misura di sicurezza necessaria? Problemi di progettazione del dominio ORM

score 6 · Accepted Answer

Questo non risponde alla tua domanda attuale, ma potrebbe essere di aiuto.

Considerare gli strumenti multipiattaforma

Ci sono livelli come PhoneGap , che ti consentirebbero di sviluppare app su più piattaforme in una lingua.
Inoltre, un linguaggio multipiattaforma, come haXe potrebbe essere di interesse (puoi usare il backend C ++ per le app native e il JS back-end per applicazioni web e mobile (attraverso il già citato PhoneGap)).

Puoi drasticamente ridurre la quantità di codice che devi scrivere, se puoi riutilizzarla su più piattaforme. Avere meno codice in primo luogo, risolve molti problemi prima ancora che si verifichino.

Concentrati su una singola piattaforma per iniziare con

Se provi a scrivere l'app per molte piattaforme diverse contemporaneamente, i risultati potrebbero diventare mediocri. Invece, dovresti provare a scegliere una singola piattaforma, su cui concentrarti. Prova i concetti della tua app su quella piattaforma e poi portalo su altre piattaforme e adattalo di conseguenza.

Ad esempio, potresti rendertene conto che in realtà non volete che le diverse porte condividano la grafica, per adattarsi meglio alle esigenze grafiche. Ad esempio su iPhone 4, hai una risoluzione molto alta, quindi potresti aver bisogno di icone extra per questo. Inoltre, gli utenti potrebbero avere aspettative diverse.

Portare un concetto di lavoro su una nuova piattaforma è relativamente semplice (anche se a volte intenso dal punto di vista del lavoro), in confronto allo sviluppo vero e proprio in primo luogo. Se provi a farlo su più piattaforme allo stesso tempo, potresti sovraccaricarti.

Quindi scegli una piattaforma, che sia sufficientemente diffusa e in cui ti senti a tuo agio, per iniziare subito a lavorare. Una base di utenti è una preziosa fonte di feedback, che difficilmente potrai ottenere da nessun'altra parte.

Non pensare troppo in grande. Inizia in piccolo e cresci.

Questo vale non solo per la scelta iniziale delle piattaforme, ma anche per la configurazione dei tuoi progetti. Adatta la tua catena di strumenti in base alle tue esigenze invece di investire tempo nella creazione di un gigantesco ambiente per tutti gli usi, che in realtà sta sovraccaricando il tuo processo di sviluppo.

Vuoi affrontare un problema non monolitico. Di conseguenza, penso che un flusso di lavoro monolitico e demenziale non sia forse la cosa migliore da fare.