Dores Constantes

Nestes últimos anos visitei muitos fabricantes de software tentando ajudá-los com revisões informais da arquitetura. Tenho agora uma lista de erros mais comuns que encontrei e que atrapalham o desempenho na produção:

• Excesso de comunicação entre camadas;
• Excesso de dados passando entre camadas (ex.: ViewState);
• Excesso de dados em variáveis de sessão (onde o mais comum é trazer para a memória todo o resultado de uma query, mesmo que de milhões de linhas, para então fazer a paginação a fim de apresentar em um grid);
• Locks, muitos locks no banco de dados. Os principais motivos costumam ser:
  • Erros em queries;
  • Falta de uso de hints, quando adequados, como o de ReadOnly;
  • Iniciar e prender cedo demais os recursos, ou liberá-los tarde demais;
• Excesso de loops com queries, ao invés de fazer uma única query mais complexa (sei que é um tipo de excesso de comunicação entre camadas, mas vale a pena sublinhar);
• Excesso de passagem de parâmetros por valor. Exemplo: passar por valor um string xml para métodos que extraem certos valores de tags, como conta corrente ou outro;
• Falta de análise do custo dos algoritmos utilizados;
• Design ruim do modelo do Banco de Dados (falta de índices, e erros graves no modelo de entidades e relacionamentos);

Para estas dores, sempre recomendo a leitura do livro do Patterns&Practices: Improving .NET Application Performance and Scalability. Mesmo antigo, ainda funciona.

Por outro lado, do lado da governança, eu tenho encontrado muita preocupação com processos de controle e pouco com o de melhoria da produção. É espantoso ver empresas com CMMI alto que não têm como costume hábitos simples e baratos como revisão de código e design, fazer um capacity planning, build e teste diário, teste de stress e análise de risco. Pior: muitas não investem na automação da burocracia destes processos, tornando-os muito caros. Parecem preferir o gasto maior ao longo do tempo do que um investimento inicial alto mais de retorno certo.

Deixei a universidade em 92 e neste tempo pouco se falava sobre estes temas. Minha impressão é que a dor continua.

PS.: Para quem quiser saber mais o como comparar o Retorno de Investimento de um CMMI contra um mero processo de revisão, recomendo o site do David Rico.

Comments

• Anonymous
  June 23, 2008
  Grande Otávio, Parabéns pelo post que traduz uma completa realidade nos projetos de software.

• Excesso de camadas (Por que complicar tanto).
• Falta de padrões de nomes (Cada um faz do seu jeito).
• Métodos muito grandes (Quase um sistema).
• Criação de outras soluções mesmo já tendo a funcionalidade. (Por que refazer o que já está pronto). Quanto ao exemplo que você citou sobre session. Eu já tive uma oportunidade 100% fiel ao comentado durante uma avaliação de um projeto onde o cliente carregava uma base super pesada com “todas as colunas” e colocava tudo na sessão (web) para “ver” 10 registros no grid com ” 5 colunas”. Quando medimos o trafego desnecessário e o consumo de memória * a quantidade de usuários da aplicação.  O cliente se assustou :)

• Anonymous
  June 29, 2008
  The comment has been removed