Fragmental

Um e-mail recorrente na lista java-br ganhou uma respsota mais longa e decidi postar aqui…

Quando uma equipe vai iniciar um novo projeto, sendo um projeto pequeno,
quais tópicos devem ser analisados?

Arquitetura
IDE ou ferramenta geradora de módulo

O que vocês sugerem?

Obrigada,

Oi,

Esta é uma dúvida muito comum e, como quase tudo, não possui uma
resposta única ou uma ‘certa’. Algumas dicas…

Se sua equipe é nova na tecnologia a ser utilizada, se preocupe em
fazê-los absorvê-la. Um treinamento de meses geralmente é inviável e
infrutífero, o melhor é dar o suficiente para que o sistema comece e
daí investir em treinamento incremental constante, com sessões de
aulas expositivas, reuniões para discutir design, ciranda de livros
(patrocinada pela empresa preferencialmente), reuniões para discussão
de papers, fórum de discussão e wiki internos, etc.

Partindo do ponto que já se possui um mínimo para começar a aplicação,
vamos criar valor ao cliente. É necessário escolher uma forma de
trabalho, seja qual for especifique um worflow mínimo. Não use
waterfall.

Dependendo da metodologia você vai descobrir o que seu sistema fará de
um jeito ou de outro, então vamos nos ater ao que geralmente não muda.

Arquitetura. Para isso você precisa de alguém experiente porque
arquitetura é algo conceitual, não apenas escolher frameworks e
bibliotecas corretas.

Se não tem um a disposição, identifique todas as possíveis soluções
dentro dos critérios:
- Simplicidade
- Qualidade final do produto
- Facilidade de aprendizado

Basicamente hoje isso quer dizer em utilizar POJOs e quando necessário
os serviços de um container como o Spring (fuja de EJB 2.1 o máximo
possível) e Hibernate se você for ter muitos objetos persistentes
(rule of thumb: muitos é mais que cinco classes) ou tem que fazer
buscas complexas com muitos objetos em memória.

Escolha de ferramentas. Se seus desenvolvedores foram treinados
juntos, provavelmente eles usam a mesma ferramenta, se não e se você
está escolhendo entre ferramentas livres (ou tem liberdade para tal),
deixe que cada um trabalhe com o que achar mais adequado. As IDEs
modernas são razoavelmente não intrusivas e não devem influenciar em
como seu projeto é estruturado. Use um controle de versão. Eu
recomendo o Subversion mas o CVS é bastante usado também. Todos
possuem plugins para as IDEs.

Para codificar, utilize ferramentas como PMD e FindBugs. Estas
ferramentas atuam como um desenvolvedor sênior e pentelho avaliando
seu código o tempo todo. Com o tempo você acaba aprendendo o que não
deve fazer de jeito nenhum e o que é simplesmente feio.

Preferencialmente use tes driven development. Se não conseguir, pelo
menos use Unit Tests, aprender a utilizar o JUnit não é difícil.

Se puder, utilize um build contínuo. Aprenda a usar o DamageControl ou
o CruiseControl. Utilize Maven ou Ant para criar seu build, não crie
JAR/WAR/EAR/RAR/qualquer outra coisa na mão.

Muita coisa, né? Se for um projeto pequeno, um projeto acadêmico ou
sei lá não vai precisar da maioria destas coisas, por isso não dá pra
falar algo com certeza. Um projeto que quer atingir qualidade
profissional é bom ter cuidado com isso.

De qualquer forma a melhor dica na minha opinião é uma só: contrate um
consultor. Existem bons profissionais especializados em pegar um time
‘cru’ e ajudar com mentoria, coaching, treinamento e consultoria. É
profissionalismo saber que alguém experiente é necessário. Pode
parecer caro mas é só colcoar na ponta do lápis o trabalho todo que dá
não ter um guia, quantas horas seus desenvolvedores vão ficar parados
sem saber o que fazer ou vão gastar várias horaspara resolver um
pequeno problema que tomaria minutos se eles forem assistidos por
algum mentor.

[]s

–
Phillip Calçado

This entry was posted on Tuesday, January 31st, 2006 at 10:33 pm and is filed under engenharia, gerencia, java, metodologias. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.