Reflexão sobre o uso de herança e o impacto nas vendas

O uso de herança na programação é uma das grandes sacadas na POO. A possibilidade de compartilhar comportamentos entre objetos nos dá produtividade, semântica e abstração. Além disso, herança é o que permite o uso de alguns design patterns, como por exemplo composição.
Saindo da teoria e indo para o mundo real, herança pode ser algo nocivo não só para entendimento e manutenção de código, mas principalmente para performance.
Analisando a aplicação de um cliente (ASP.NET MVC 3), observei que o número de contenção de threads (locks) era alto, assim como o número de falhas. Antes de fazer o profile da aplicação resolvi analisar as classes bases mais utilizadas na aplicação e encontrei uma classe chamada SiteControllerBase — extremamente ofensiva — que era utilizada em todas as controllers da aplicação.

Em todas as chamadas para controllers (inclusive ajax), a classe base (SiteControllerBase) era instanciada. O objetivo principal dessa classe base, era inicializar objetos de logs e atualizar os menus do usuário na aplicação.
Do ponto de vista lógico, esse código estava funcionando, porém do ponto de vista de performance e negócio não.

Veja o que acontecia na criação de uma nova instancia:

#1 Lock no objeto privado estático _mylock;

#2 Solicitação de instância da interface IProductDepartmentService para injetor de dependência;

#3 Chamada do método GetAll(), implementado em um repositório com NHibernate sem cache (fazendo hit no banco);

#4 Carregamento encapsulado de uma propriedade estática com as informações de departamento do usuário;

#5 Os passos 2, 3 e 4 eram executados novamente para as interfaces IProductCategoryService e IProductSubcategoryService.

Olhe agora que interessante:

• DBA mostrou que três das top 10 queries eram dos repositórios utilizados na classe base.
• Analista de negócio informou que as informações do menu não eram por usuários e sim por grupo e que a informação era atualizada esporadicamente.

Com essas informações em mão, refatorei o código, removendo o lock e criando um cache in-memory para as informações de menu. Essa refatoração de poucos minutos entregou:

• Redução do número de contenções de threads;
• Remoção das três queries do TOP 10 queries;
• Redução da pressão sobre o GC;
• Redução de custo de infraestrutura;
• Redução no custo de venda.

Reflexão

Como desenvolvedores, não devemos ser meros geradores de código. Cada linha que escrevemos impactam diretamente uma quantidade enorme de pessoas. Esse sistema atualmente roda em um varejo, onde uma análise global nos mostra que:

• Um bloco de código mal escrito significa maior consumo de hardware, logo aumenta o custo de infraestrutura;
• Se aplicação é lenta, o cliente escolhe o concorrente;
• Se aplicação é lenta, os colaboradores que utilizam a aplicação ficam ociosos, e ociosidade é custo.

Como desenvolvedores, precisamos entregar mais do que código, precisamos entregar valor para nosso cliente.