Cosa prendere in considerazione quando si sceglie un framework per un team di sviluppo? [chiuso]

Quando scegli qualsiasi framework, considera la sua popolarità , in termini di post del blog, domande StackOverflow, risorse e documentazione. Un framework relativamente nuovo non è garantito per sbocciare e potrebbe renderti esperto in un contesto di nicchia. Idealmente vorrai qualcosa che sia facile per qualsiasi nuovo sviluppatore.

Assicurati che sia adatto per la tua competenza principale. Se sei un negozio Microsoft, non vorrai un PHP in quanto è coinvolta una curva di apprendimento e uno sviluppatore .NET normalmente non sarebbe molto abile in PHP. Allo stesso tempo, ci può essere un'aspettativa ragionevole per uno sviluppatore ASP.NET di raccogliere framework MV * Javascript.

Per quanto riguarda le prestazioni, se non è un requisito reale o NFR avere pagine fulminee, allora non penso che escludere Python / Ruby sia ragionevole. Dovresti essere a posto con quelle lingue se questo è un sistema interno con una quantità moderata di utenti concorrenti. Ci sono molti framework in Python e Ruby che offrono molte funzionalità che potrebbero soddisfare diversi requisiti, e dovrebbero essere esclusi solo se ci sono altri ostacoli allo sviluppo, come test, sviluppo, curva di apprendimento, ecc.

Riguardo all'apprendimento - aiuta molto se c'è un "campione" di una tecnologia. Questo campione può fare un workshop e insegnare agli altri sviluppatori le basi. Avere le nozioni di base è una lunga strada per imparare di più e lasciare che gli sviluppatori passino attraverso più tutorial, video o compiti. Il successo di questo approccio dipenderà dalla cultura del team.

Per quanto riguarda la tua ultima domanda sull'architettura / organizzazione, un'area interessante sarebbe utilizzare un framework MV * Javascript (AngularJS, Knockout) con un'API RESTful come back-end (e questo può ancora essere un normale framework MVC come Django o ASP.NET WebAPI). Ciò ti consente un front end ricco e funzionale e puoi concentrarti sulla logica di business nel back-end senza preoccuparti di generare il markup.

Scegliere la struttura in base a molti fattori:

• Tempo / risorse: se hai tempo, puoi essere più avventuroso per provare nuove tecnologie. Se hai meno tempo, tienilo semplice, se hai una discreta quantità di tempo, fai la ricerca e trova qualcosa che si adatti bene ai tuoi sogni. Sulle risorse: se disponi di risorse scarse (nessun guadagno, tempo libero al giorno) rendi tutto più semplice e semplice.
• Competenza: se il team ha una buona base su una tecnologia che è ok, ma potrebbe non essere la migliore, è ancora una scelta razionale, dal momento che molti di voi non devono imparare le basi, e gli altri possono raggiungere rapidamente, dal momento che hanno molte persone da cui chiedere. Scrivi tutte le competenze che possiedi con una scala da 1 a 5 e pensa attraverso la tua forza (linguaggi di programmazione, API, strumenti, ecc.)
• Dimensioni del progetto: se hai un progetto piccolo, mantieni la scelta il più semplice possibile. Chiedi sempre: abbiamo veramente bisogno di questa / quella caratteristica che fornisce il framework? Il "keep it simple" ripaga il secondo o il terzo progetto quando pensi a cosa fare in modo diverso, e non sarà una lista troppo numerosa.
• Popolarità: non scegliere alcune tecnologie esotiche, controlla quante persone lo stanno utilizzando. Cerca nei forum le domande fatte con quella tecnologia, se è numerosa, allora puoi giudicare quanto bene funzioni, e anche se ottieni casi problematici, ottieni molti successi.

Una volta che abbiamo realizzato un progetto, abbiamo ereditato una cattiva base, ma abbiamo avuto il tempo di terminarlo. Il progetto era piuttosto semplice, quindi abbiamo scelto GWT e abbiamo cercato un'estensione con cui lavorare (abbiamo scelto smartGWT). Abbiamo avuto il tempo di fare esperimenti sulla tecnologia, e ha avuto successo. Se avessimo meno tempo, probabilmente ci siamo attenuti a Vanilla GWT con meno funzioni. Ci è voluto un mese per familiarizzare con smartGWT (scoprire cosa funziona e come, e cosa abbiamo bisogno di aggiungere), se non hai tempo / risorsa, non sprecare quella quantità di tempo a sperimentare.

Credo che la cosa più importante nella scelta di un framework / piattaforma sia la forza tecnologica dei membri / sviluppatori del tuo team.

E sì MVC per il punto di vista della manutenzione / riutilizzabilità.

Ma per uno sviluppo piccolo e rapido, suggerirei che PhP è il migliore! Persino il team non conosce o ha altre conoscenze del framework web, può adottarlo molto rapidamente con una curva di apprendimento molto semplice.

What should be considered when choosing a web framework? For small projects, performance shouldn't be a killer factor, but would it still be reasonable to remove Ruby/Python systems from the competition?

Come menzionato la forza del team e il know-how tecnico disponibile.

Is being able to work on more than one programming language, or more than one framework in a given language something important?

Dipende da ciò che desideri raggiungere, sì, è sempre bene avere un pool di risorse eterogenee. Ma potrebbe essere molto complesso da mantenere, motivare e guidare.

Should the learning of one or more frameworks be done in group, or on each developer's own, and then gather opinions on them?

Qualsiasi apprendimento in gruppo è buono se è orientato al target, misurato e coinvolto. A volte un ragazzo pigro si mantiene abbastanza in gruppo e lo scopo non è servito. Anche i metodi XP come la paia di programmazione possono essere utili.

Finally, is there a more recommended project architecture/organisation method for team projects than MVC for the Web? What are the viable options?

Ancora una volta la struttura / tecnologia dipende dalla forza della squadra. Ma usa un agile aproach per misurare gli obiettivi e governare di conseguenza.

Buona fortuna!