Progetti multipli - piattaforme simili o diverse possibili?

Innanzitutto, i requisiti effettivi dovrebbero guidare la decisione su quale linguaggio, framework e strumenti utilizzare.

Se i requisiti ti consentono di lavorare su linguaggi, framework e strumenti simili, dovresti assolutamente cercare di mantenere le cose il più coerenti possibili.

Vuoi mantenere le cose simili per i seguenti motivi:

• Meno cambi di contesto per uno sviluppatore è buono - C'è molto meno cambio di contesto quando permetti ai tuoi sviluppatori di usare le stesse lingue, strumenti, ecc ... Tutto quello che devono passare è tra "domini" ma non tra le lingue con sintassi diversa e / o principi completamente diversi.
• La complessità dell'ambiente di sviluppo è inferiore - È abbastanza complicato configurare l'ambiente di sviluppo per un singolo tipo di stack di applicazioni, non è necessario il problema di dover impostare più di quello che è necessario. / li>
• La coerenza è buona - Tieni il più possibile coerente tra i due progetti, come standard di codifica, layout di directory, ecc. Immagina un nuovo sviluppatore che entra nel progetto e prova a capire entrambe le app. Richiederebbero il doppio del tempo di accelerazione.

UPDATE: La domanda è cambiata in modo significativo e la mia comprensione è che stai chiedendo quanto segue ...

Ho un progetto su cui sto lavorando in questo momento. Vorrei raccogliere un altro progetto su cui lavorare contemporaneamente con l'altro. È meglio scegliere un progetto simile a quello esistente o completamente diverso.

Dipende interamente da ciò a cui vuoi entrare.

Vuoi imparare una nuova lingua del tutto? Mi concentrerei sulla nuova lingua. Personalmente faccio meglio quando il mio obiettivo non è diviso tra progetti, quindi mi piace lavorare su una singola cosa almeno per un paio di giorni prima di passare a qualcos'altro. Per quanto riguarda il tipo di linguaggio, se impari qualcosa che è vicino a quello originale (Java- > Groovy), probabilmente lo raccoglierai più velocemente, avrai meno frustrazione e meno cambi di contesto. Tuttavia, potresti non avere una grande prospettiva su quanto due lingue possano realmente differire (Java- > Ruby o LISP- e gt; C) nei loro principi.

Supponendo che queste decisioni abbiano superato la fase "usa gli strumenti giusti per il lavoro", sei veramente di fronte a una situazione in cui ci sono progetti ugualmente utili con strumenti ugualmente utili per ciascuno che lo sviluppatore sa, i miei pensieri:

Raramente, se non mai, mi sono trovato a beneficiare di lavorare in due mentalità completamente diverse allo stesso tempo. Alcuni motivi per cui non mi piace:

• Presupposti diversi sull'applicazione finale. È difficile cambiare la tua mentalità tra due impostazioni completamente diverse. Per usare un esempio estremo, trovo irritante programmare per qualcosa che andrà in un cluster un giorno, e quindi qualcosa che deve essere eseguito in un ambiente estremamente povero di risorse.
• familiarità degli strumenti. Anche se sei intimamente familiare con entrambi gli ambienti di programmazione, il passaggio avanti e indietro richiede un po 'di lavoro. Dov'è il pulsante per fare X in questo particolare IDE? Questa lingua inizia a indicizzare a 0 o 1?
• Coerenza tra i progetti. La tua domanda presuppone effettivamente 4 progetti su cui lo sviluppatore potrebbe suddividere il proprio tempo, due serie di due progetti simili. Presumibilmente, quegli altri progetti verranno raccolti da qualcun altro. Probabilmente è meglio che tutti i progetti X seguano lo stile di Programmatore 1 e che i progetti Y seguano lo stile di Programmatore 2 (supponendo che non siano codice spaghetti, ben documentato, ecc.) Di una miscela strana in cui quando devi lavorare con X, devi anche capire se è stato Bob o Amy a codificarlo.
• Diciamo, come suggerisce Joonas, che hai scelto male. Innanzitutto, è altrettanto probabile che non ci siano informazioni che la tua scelta decolla, quindi è discutibile. Ma anche se hai quelli con cui hai deciso di andare con il collasso, è probabilmente meglio migrare dalla nuova alla vecchia piattaforma / sistema / qualsiasi cosa allo stesso tempo - ancora, usando uno stile coerente, piuttosto che farli trasferire da due team diversi .

Fondamentalmente, preferisco di gran lunga concentrarmi su un "tipo" di progetto alla volta. Metti il mio cappello "R" o "SAS" o "Python" fino a che il progetto non è terminato, poi cambia le opzioni, piuttosto che rimbalzare tra loro.

Dovresti sforzarti di utilizzare gli strumenti migliori per il lavoro da svolgere. Tuttavia, se l'utilizzo degli strumenti migliori è completamente sconosciuto agli sviluppatori, questi potrebbero non essere gli strumenti migliori.

Dipende da cosa vuoi.

• Se vuoi ottenere più lavoro possibile, scegli tecnologie simili, per ridurre al minimo il tempo di apprendimento.
• Se vuoi imparare cose nuove, scegli diverse tecnologie, per aumentare l'esposizione a nuove idee e tecnologie.

Quindi dipende dal contesto.

Se fosse un progetto per hobby, probabilmente mi propenderei all'opzione 2, perché mi piace imparare cose nuove.

Se assegnassi sviluppatori a progetti in un'azienda, tenterei di trovare un compromesso, perché per un datore di lavoro entrambi i punti sono importanti: ovviamente vuoi che i tuoi dipendenti lavorino, ma vuoi anche che imparino di nuovo roba, quindi puoi spostarli tra i progetti come richiesto.

Da una parte, certo, per ovvi motivi (meno cambio di contesto, maggiore coerenza, ecc.)

D'altra parte, vuoi mettere tutte le uova nello stesso paniere? Che cosa succede se la struttura / piattaforma / qualsiasi cosa della vostra scelta muore in qualche modo? Cosa succederebbe se il framework / piattaforma / qualunque cosa non scegliessero iniziando a prosperare? È che accade sempre, ad esempio, con piattaforme mobili - attualmente il potente Symbian sta lentamente ma inesorabilmente andando giù, Windows forse sta salendo, ma nessuno sa qual è lo status quo in dopo un paio di anni.

Se si tratta di più progetti nel tuo lavoro o per la tua attività, probabilmente è meglio utilizzare un simile stack di tecnologie per aumentare la possibilità di riutilizzare parti di una nell'altra.

MA, se un progetto è per lavoro, e uno è un progetto personale che stai facendo a casa - cioè due luoghi completamente diversi - quindi utilizza tecnologie separate. Presumibilmente il riutilizzo del codice in quel caso è fuori questione comunque, dal momento che non puoi copiare il codice del tuo datore di lavoro. Usando uno stack diverso avrai meno probabilità di "bruciare" su uno o l'altro perché non lo guarderai per 12 ore al giorno.