Framework ideal para equipes com alta rotatividade

Estou projetando uma arquitetura para um sistema de informação interno de uma empresa júnior. Controle de membros, projetos, clientes, etc.

O desejo é que este software esteja em desenvolvimento e manutenção contínua. Mas existe dois problemas críticos: alta rotatividade dos desenvolvedores do projeto e membros iniciantes na em J2EE. Suponho que um desenvolvedor passe pela equipe por 4 a 12 meses.

E aí? Qual "Framework MVC Web" usar?
O seria mais interesante, um mais consolidado c/ livros, documentação e grande comunidade (Struts) ou um framework mais simples e produtivo (WebWork, VRaptor)? Alguma sugestão?

Moderador Membro desde: 21/02/2003 16:19:19 Mensagens: 1647 Offline

Eu ficaria com o mais simples e produtivo.

O mal desses frameworks com pouca documentação é o ínicio ... montar o ambiente e estruturar a sua aplicação, mas depois disso ter todas as vantagens que eles te dão é muito melhor do que ficar limitado por algumas características dos documentados (aka: Struts

)

Já que é uma empresa júnior, a idéia é vcs se desenvolverem pacas a aprenderem pacas porque não ficam com o Vraptor? Ele tá começando (na verdade eu não sei em que pé está), é brazuca e vcs podem ir contribuindo conforme forem tendo necessidades que ele não supra.

O Webwork já está mais maduro mas vc tb pode ir por esse caminho (de contribuir, etc. etc.) embora vá ser em menor escala.

[]s

É a falta de documentação pode ser parcialmente suprida pela nossa documentação.
Alterar o framework?! Eu tinha até esquecido dessa vantagem de software livre.

Eu nao me preocuparia com o framework, pra falar a verdade, apesar disso ser uma decisao importante, mas sim com a qualidade do codigo que voces vao produzir. Uma empresa junior tem a tendencia a montar bases de codigo extremamente poluidas em pouquissimo tempo, entao voce precisa pensar em um jeito de tornar o codigo o mais limpo possivel, para facilitar a manutencao. De uma olhada nos principios do XP (aqui tem um resuminho: http://martinfowler.com/bliki/PrinciplesOfXP.html

)

XP, Wiki e Fórum interno também fazem parte dos planos.

Mas valeu pelo toque. E novas sugestões são muito bem vindas!

Talvez até mais que numa empresa sênior, numa empresa júnior a qualidade dos projetos (não apenas do código) está intimamente ligada com a qualidade dos desenvolvedores. Por isso são feitos projetos com tamanha diferença de qualidade. Exite cobrança, porém é mais suave.

E é justamente isso que estamos atacando. Claro que sempre estaremos atrás das sêniors, mas queremos dar uma empuradinha para cima.

Bom, mais uma dica: capriche nos testes e no sistema de builds. Se for usar Ant, certifique-se de que todos os deliverables de todos os projetos podem ser compilados, testados, montados e deployados facilmente com UMA operacao soh (ant doEverything

). Isso aumenta horrores a produtividade.

Mais uma dica eh usar um sistema de test coverage (JCoverage, EMMA, Clover sao alguns exemplos), pra saber o que, exatamente, esta sendo testado pelos testcases. Mao na roda.

cv wrote: (...) todos os projetos podem ser compilados, testados, montados e deployados facilmente com UMA operacao soh (ant doEverything ). Isso aumenta horrores a produtividade. (...)

Teste do Joel na veia! Bem lembrado.

cv wrote: (...) usar um sistema de test coverage (JCoverage, EMMA, Clover)

Isso eu nunca ouvi falar.

Mãos à obra. Ou melhor, mãos ao google.

Valeu.

Notícias, artigos e o maior fórum brasileiro sobre Java