Café com Tecnologia

Essa semana participei de uma discussão sobre a construção de códigos otimizados.

Qual a melhor forma de se otimizar um código para ganhar desempenho? Escrever o código durante o projeto tentando escrever um código mais eficiente possível ou simplesmente terminar um projeto e depois realizar testes para diagnosticar e otimizar?

Eu diria que a busca por códigos otimizados deve ser constante. Para fazer isso, a melhor maneira é:

• possuir processos de desenvolvimento de software bem definidos. é importante que todos os membros da equipe estejam alinhados com ela.
• possuir profissionais experientes nos projetos. Se seu projeto tiver pessoas menos experiêntes, faça um mentoring sempre que possível. Evolua a equipe, para evoluir o projeto;
• conhecer (as boas e más), praticar e disseminar as boas práticas no desenvolvimento para a equipe;
• utilizar ferramentas que façam auditoria nos códigos.

Já comece qualquer projeto com todos os recursos disponíveis para você construir códigos otimizados.

Hoje existem várias técnicas e ferramentas que podem auxiliá-lo a respeito.

Utilize ferramentas, como Maven, para centralizar suas rotinas para auditoria de código. Exemplos:

• O plugin Checkstyle pode ser usado para você verificar se os códigos estão sendo desenvolvidos seguindo os padrões da SUN. Pode ser customizado para atender seus requisitos.
• O plugin CPD / PMD te apresenta códigos duplicados.
• O plugin FindBugs te apresenta os possíveis bugs em seus códigos.
• Faça testes unitários. Veja alguns recursos que você pode usar: JUnit, DBUnit, JMock2, TestNG, JsUnit, JsMock, ….

Esses plugins podem estar contidos em sua IDE ou executados externamente. Se estiverem na IDE, em tempo de codificação, você poderá ter impactos na performance (tenha um bom PC, ok?).

Há vários outros itens que podem ser usados.

Porém, esse é o cenário perfeito, mas que nem sempre é uma verdade. Muitos projetos são vendidos e gerenciados sem prever os testes. INFELIZMENTE e sem tempo para refactoring.

Em uma recente experiência NADA AGRADÁVEL, solicitaram para que a configuração de timeout do Portal fosse configurado para 12h. O recomendado (InfoCenter, documento de Tunning, Suporte, etc) pela IBM é um timeout de 30 minutos.

Enfim, mesmo avisando as consequências, a configuração foi realizada após o horário comercial, já que necessitaria de um restart no servidor.

No dia seguinte não deu outra: o Portal ficou absurdamente lento e meu servidor passivo foi ativado.

Conclusão: hoje o cliente tem total ciência do problema encontrado e estamos fazendo reduções até chegar a um ponto que atenda aos usuários (que não gostam de fazer autenticação) e que seja suportado pelo Portal.