segunda-feira, 24 de junho de 2013

Caixa de ferramentas do arquiteto Java


Gosto de uma definição antiga que pode ser usada até hoje:

“O arquiteto ideal deve ser uma pessoa erudita, um matemático, familiarizado com estudos históricos, um estudioso aplicado de filosofia, conhecedor de música, que não desconheça medicina, detentor de saber jurídico e familiarizado com astronomia e cálculos astronômicos.“ (Vitruvius, 25 A.C.)

Eu tenho trabalhado como consultor em muitos clientes e tenho que tomar diversas decisões arquiteturais sobre tecnologias e ferramentas e também sobre ALM (Application Lifecycle Management). Estou fazendo este post para falar de algumas ferramentas que temos à nossa disposição e que devemos conhecer.

Vale lembrar que a escolha das tecnologias e ferramentas sempre depende de inúmeras variáveis, é necessário entender a aplicação, requisitos, objetivos e limitações para tomar a melhor decisão.

E ferramentas, na verdade, são úteis apenas com a definição de técnicas e de processos de forma adequada.

Enfim, vamos lá! Separei algumas ferramentas por tópicos:

Análise de requisitos, arquitetura e design

O mais importante na análise de requisitos são as técnicas utilizadas, conseguir obter o máximo de informações e detalhá-las conforme necessidade.

Uma ferramenta bem robusta é o Enterprise Architect (EA), porém, gasta-se muito tempo para trabalhar com esta ferramenta.

Existe a possibilidade de trabalhar com arquivos de texto como o Word, porém, não são documentos vivos, uma ideia interessante é utilizar uma ferramenta de wiki, como o xwiki por exemplo. O Confluence da Atlassian é muito bom também para documentação e compartilhamento de conhecimentos.

É interessante o uso de ferramentas para criação de fluxos e diagramas como o Astah (antigo Jude) e o Bizagi.

Para criação de protótipos eu sempre utilizo o Balsamiq Mockups, ele é fantástico! Existem outras opções como o Axure, que é um mais robusto, mas o Balsamiq é mais simples e atente em quase todas as situações.


Gerenciamento de Projetos

O MS Project é ótimo para gerar e organizar cronogramas.

O Jira (ou RedMine, que é basicamente uma versão free do Jira) é muito bom para gerenciar as atividades de um projeto. Você cadastra um projeto, coloca as atividades e o número de horas, delega para os responsáveis, e tem um visão bem clara de tudo que está acontecendo. Estas ferramentas também servem para registrar bugs, é possível visualizar quantos erros aconteceram, de qual tipo, tem diversos gráficos e formas de visualização. Você também pode criar um workflow com todos os passos e responsáveis para cada atividade. Caso você vá usar RedMine, sugiro a instalação do plugin Monitoramento e Controle para melhor visualização das atividades.

Se você for trabalhar com Agile o GreenHopper é uma ótima opção. O Trello é um software de kanban muito eficiente em que você pode organizar seus projetos, atribuir responsáveis, entre outras funcionalidades.

Se você precisa de um produto que seja integrado com a folha de pagamento, que gera relatórios para enviar aos clientes, você pode procurar sistemas próprios para isso, porém, talvez exista a necessidade de customização.


Criação de código (IDE)

Sou adepto da ideia que cada desenvolvedor deve ser livre para escolher sua IDE.

Eu sempre trabalho com o Eclipse, ou com o JBoss Developer Studio (que é o Eclipse com diversos plugins da JBoss), mas caso o desenvolvedor queira usar NetBeans, ou alguma outra IDE (IntelliJ IDEA por exemplo), ou até mesmo um editor de textos qualquer ele deve poder! Para isso deve ser utilizado o Maven, que, entre outras coisas, organiza o projeto para que ele possa ser utilizado com qualquer IDE, ou sem nenhuma.


Repositório de fontes

Há muito tempo era utilizado o CVS, porém, com o surgimento do SVN ele não é mais recomendado.

O SVN é simples de usar e muito eficiente e eficaz.

Caso você tenha uma equipe entusiasta por tecnologia e que abrace a ideia, é uma excelente ideia utilizar o GIT. Ele é mais complexo e mais difícil de aprender, no entanto, traz inúmeras vantagens.

Outra opção é o TFS para versionamento de fontes, mas acredito que ele é extremamente eficiente para projetos com tecnologias Microsoft, mas não para projetos Java, mesmo as versões mais novas do TFS.

Existe ainda o Mercurial, este eu não conheço muito, não conheço muitas empresas que o utilizam.

Existem diversos padrões, utilizados mundialmente, para versionamentos, criação de tags e branches, é de extrema importância definir este processo.


Build automation e Integração contínua

Recomendo a utilização do Jenkins, nele você pode rodar compilação automática, rodar scripts de testes, de validação de código e atualizar ambientes.

O Jenkins é free e opensource, ele sempre me atendeu 100%. Outra opção é o Bamboo, da Atlassian.


Qualidade

Para garantir a qualidade, além dos testes manuais (abrir a tela e verificar se está funcionando) existem outras formas de manter a qualidade como validação de fontes, testes unitários e testes de interface.

Estes testes e validações podem ser rodados automaticamente na integração contínua através do Maven, dessa forma você pode verificar a cada commit se algum teste parou de funcionar ou se alguma política de validação de fonte foi desreipeitada. Caso isso ocorra é enviado um e-mail para quem fez o commit e para os responsáveis pelo projeto.

Para validação de fontes recomendo a utilização de PMD e Checkstyle. Essas ferramentas verificam vários problemas no código. Existem plugins para o eclipse para utilização destas ferramentas. E elas também são rodadas via Maven (ou seja, independem de IDE). Para uma melhor visualização de tudo isso deve ser utilizado o Sonar, que oferece uma tela web para visualização de todos os problemas de código.

Para testes unitários o Arquillian é excelente! É interessante utilizar uma ferramenta que verifica quantas e quais linhas do seu fonte estão sendo cobertas pelos testes, para isso pode ser utilizado o Sonar ou o EclEmma ou o Atlassian Clover ou ainda alguma outra ferramenta.

Se o sistema for SAAS (ou se tiver uma grande preocupação com performance), é importante também escrever testes de desempenho utilizando ferramentas como JMeter, NewRelic, VisualVM, jConsole, entre outras.

Para testes de interface eu já utilizei o Visual Studio para projetos Java Web, achei muito bom, porém, a licença é cara. Quem conhece Java não terá dificuldade para trabalhar com ele, é utilizado C# para escrever os testes de tela. Uma opção free e bem semelhante às ferramentas de teste da Microsoft é o Selenium.

O ideal é estabelecer um processo de desenvolvimento onde sempre se escrevem testes automatizados e uma política de PMD e Checkstyle. Então para liberar uma versão, todos os testes automatizados devem rodar sem erros e a política estabelecida de PMD e Checkstyle deve ser atendida. Com certeza também é importante sempre fazer testes manuais, os próprios desenvolvedores podem testar o que outros desenvolvedores testaram, ou pode ser criada uma equipe de qualidade ou definir uma pessoa para ser tester.


Criação de Help On-line

Com um código bem documentado, é bacana a geração e publicação do JavaDoc. Através das ferramentas de validação de código é possível verificar se os códigos estão ou não documentados.

Mas é possível criar um help on-line de outras formas também, o xwiki é uma opção bacana!

Para a criação de help por página sistema de forma automática talvez exista alguma ferramenta para isso. É possível criar um mecanismo de links, tive que fazer isso em um produto e criei eu mesmo uma estrutura de documentação seguindo alguns padrões que eu defini.


I18n

Pode-se utilizar arquivos de textos, que é a opção mais simples. Porém, já trabelhei salvando as traduções em um banco de dados, é possível trabalhar com cache para melhorar a performance e fica muito bom também. Existem outras estratégias para corrigir problemas de performance com traduções.

Existe ainda a possibilidade de trabalhar com as traduções na Cloud, com a ferramenta transifex por exemplo.

Existem diversos padrões para serem seguidos com relação a tradução, para evitar problemas de formatos de campos, documentos, entre outras coisas.


Conclusão

Primeiro temos que definir ideias, definir o que queremos e o que é preciso de verdade. Após isso deve-se pensar em ferramentas para atender as necessidades.

Temos à nossa disposição inúmeras ferramentas, mas temos que entender melhor cada situação para utilizarmos as ferramentas adequadas.

Um grande abraço!
Adriano Schmidt

sábado, 22 de junho de 2013

JSF 2.2

E aí pessoal..

Hoje estava em um cliente que tem uma aplicação com JSF 2.1 e EJB 3.1 rodando no JBoss AS 7.

Essa aplicação tem centenas de acessos simultâneos e estávamos com problemas de uso de memória e de performance.

Sei que JSF talvez não seja a tecnologia mais adequada para projetos como esse, mas não poderíamos mudar isso agora.

Nós migramos a aplicação de JSF 2.1 para JSF 2.2 e tivemos muitos ganhos! O consumo de memória diminuiu consideravelmente! O GC conseguiu rodar melhor e limpar o heap bem mais do que fazia no JSF 2.1! Não sei se foi apenas por consequência do melhor uso da memória, mas a performance aumentou muito também!

Tudo isso foi constatado pelos próprios usuários e também por testes com o JMeter e com análises utilizando o VisualVM.

Enfim, fica a dica pessoal, usem o JSF 2.2!

Para implantar ele no JBoss AS 7 foi bem tranquilo! Nós seguimos este tutorial: http://www.marcusschiesser.de/2013/01/how-to-use-jsf-2-2-with-jboss-7-1/

Só um porém.. alguns componentes na aplicação tinham update="@form" ou update="idDeUmForm" e isso parou de funcionar no JSF 2.2 :/

Não sei o motivo.. aqui eram poucos casos e resolvemos alterando o update para atualizar o componente que devia ser atualizado e não todo o form.

Ao invés de update="@form" usamos update="idDoComponenteDentroDoFormQueTinhaQueSerAtualizado" : )

Abraços!!
Adriano Schmidt