Maurício Medina

Vivemos hoje uma situação que até acho engraçado quando chamam de engenharia de software: Não se testa do jeito que deveria ser. É impossível pensar em comprar uma casa ou um carro sem que seus componentes tenham sido testados, mas quando o assunto é software, isto normalmente não existe.

Pulando as reclamações, e eu também não vou resolver isto sozinho, vamos ao que interessa: normalmente os projetos têm muito pouco teste, quando têm. Logo, a abordagem precisa ser focada no momento onde o problema pode aparecer ou quando ele já apareceu...

Quando ainda dá tempo para tentar descobrir os problemas antes de colocar em produção:

Um dos problemas complicados, que só surgem no final dos projetos onde não há um processo de qualidade, é o fato de que somente quando os componentes são integrados aparecem os problemas relativos à aderência a funcionalidades e performance. Isto é derivado do fato de que como não houve testes funcionais para os componentes unitariamente, eles somente vão apresentar problemas quando são postos para funcionar com outros e ai é muito mais difícil para identifica onde está, ou estão, os problemas...

Como, para variar, a documentação também não acompanhou o projeto, você vai ter que de fato fazer o negócio funcionar para poder identificar onde está o problema. Mas isto é mais fácil de falar do que fazer... Na realidade é necessário que se rastreie a transação, vendo a cada momento quem chama quem, quanto tempo cada componente custa, quanto tempo leva e outras métricas para poder-se dizer quais são os suspeitos de serem os gargalos.

Mais uma vez, como provavelmente não se têm um plano de testes, ou até uma descrição funcional da transação, isto vai tomar muito tempo e recursos. Ou seja, seria mais barato se houvesse de fato uma preocupação em se descobrir como as transações da aplicação se comportarão. Mas como isto é o que chamamos de "desejo de consumo", vamos aos fatos: Vai ter que identificar no "braço" os componentes problemáticos se não houver algum tipo de automação.

Depois de se obter os suspeitos, é necessário que se analise cada um para que as suspeitas sejam comprovadas e tratadas, ou que o suspeito seja abandonado. E quando o suspeito é submetido à uma análise realmente eficiente, muita coisa aparece: desde código mal escrito até péssima arquitetura (que assunto para outra oportunidade). E ai, quando de fato conseguimos tratar os suspeitos, é o caso de resolvermos o que vamos fazer com eles e com a aplicação. Consome muito de recursos e grana.

Quando os problemas aparecem na produção:

Neste caso, o pior de todos, temos a aplicação gerando riscos para a organização e para o negócio. Temos ai uma ação emergencial, onde devemos fazer tudo para baixar os níveis de risco.

A abordagem inicial é tentar identificar as transações mais comprometidas e que são mais críticas para a aplicação. Uma vez identificadas, priorizá-las é o segundo passo para que possamos encontrar os potenciais problemas. E tentar entender como a infra-estrutura está apoiando a aplicação para que possamos começar a entender os aspectos limitantes da infra, quando existem.

Quando conseguimos identificar as transações de forma consistente, podemos seguir os passos dados no caso anteriormente descrito para isolarmos os suspeitos e tratá-los.

Parece simples mas não é: fazer isto com a aplicação em produção, impactando os resultados de negócios, sentindo a pressão dos usuários e outros problemas mais, não são coisa para iniciantes. E ter o sangue frio, sem preconceitos, para tratar as várias camadas da aplicação é um desafio. E quando falo de preconceitos, falo das análises tendenciosas que muitas vezes empurram as avaliações e diagnósticos para problemas que nem sempre são os culpados de fato, mas que na visão do analista sempre são culpados até prova em contrário.

Bom, o objetivo é dar um caminho para resolver problemas que deveriam ter sido resolvidos antes, mas que as praticas atuais nem sempre se preocupam em resolver. Como dizem alguns: choque de realidade. Que pode ajudar no futuro ou simplesmente perpetuar práticas que são extremamente ruins, mas que o mercado ainda acha que atendem aos "cronogramas e objetivos". Vale uma pensada e uma revisão dos seus processos?

Abraços

Maurício Medina é diretor executivo da Consequor Tecnologia, empresa focada em qualidade e performance, além de ter sido o diretor de serviços da Compuware e o fundador da Rational Software no Brasil. Tem 23 anos de experiência na área de TI e esteve presente nas ondas de tecnologia que chegaram ao país através das empresas que as estavam implementando, como Amplus (início das redes), Relacional (distribuição de Oracle), Gupta (ferramentas de desenvolvimento). Foi escolhido como Most Valuable Professional (MVP) pela Microsoft e é colunista da coluna Arquitetura de Software no site www.msdn.com.br e da coluna Opinião no site www.aliceramos.com