A divisão do software em camadas, atualmente, é certamente uma das formas mais eficientes de se estar organizando a sua aplicação. Facilitando a manutenção, reaproveitamento de código, etc. Vale salientar que camada no inglês tem duas palavras: Tier, a camada física e Layer, camada lógica. No entanto, criar um grande número de camadas além de desnecessário acaba deteriorando a desempenho do seu software. Assim surgiram as chamadas delay layer, camadas lógicas que apenas servem para passar à informação a diante, gerando atraso na reposta e consumo desnecessário na memória. Esses atrasos em alguns casos acontecem fora da parte lógica da aplicação. Acontecem no processo de desenvolvimento (fora do código), pessoas ou profissionais que acabam gerando um atraso na resposta, delay tier, conhecido carinhosamente como os “tios da senha”.
Figura 1: O tempo de resposta das aplicações hoje é um fator fundamental
Exemplificando como eles funcionam, podemos citar funcionário que aperta o botão no elevador, vale ressaltar que não estamos desmerecendo nenhuma profissão. O elevador possui uma interface bastante simples e basta se pressionar o botão com o andar desejado. Você precisa informar o andar desejado ao funcionário e ele por sua vez apertará o botão. Essa chamada gerará um atraso natural até você informar o andar desejado e esse profissional executar sua ação, quando entrarem dez pessoas simultaneamente essa demora será “gritante”.
As empresas não o contratam diretamente, alguns preferem chamar de Arquitetos, gestores de aplicação ou DBAs, são profissionais que centralizam alguns até mesmo todos os processos de software de uma empresa. Essa ação gera um pseudo controle para a empresa, porém, acaba gerando atraso tanto nas escolhas de tecnologias quanto na execução de um script, alteração no banco de dados etc. e esses atrasos impactam diretamente a entrega desse projeto.
O fato é que as tecnologias, requisitos, metodologias, etc. surgem muito rápidos, assim nascem várias siglas (UX, DDD, TDD, BDD NOSQL, NewSQL, bid data, integração contínua, etc.) e deixar essa responsabilidade na mão de apenas uma pessoa ou uma pequena equipe se torna um erro. Por alguns motivos:
Caso os detentores das senhas, se desmotivarem e parem de se atualizar profissionalmente. O parque tecnológico da empresa em pouco tempo virará artefato de museu.
Centralizar decisões técnicas para todos os projetos é um grande erro! Ninguém melhor que um membro da equipe para decidir qual ferramenta é a mais interessante para um requisito específico. Sem falar que pode gerar uma padronização equivocada, ou seja, para todos os problemas a mesma solução. Dizer que para todos os problemas precisamos de um martelo é dizer que os parafusos também são pregos.
Figura 2: Centralizar decisões técnicas não é uma boa escolha
O aumento demasiado do ego, isso mesmo, um técnico com um ego muito grande faz com que toda a empresa use tecnologias do seu “mundinho” para que assim ele seja o maioral.
Atraso na resposta, fazer com que muitos processos passem na mão de uma pessoa, quando existir muitas requisições de várias pessoas em algum momento gerará um atraso, é o caso do elevador quando entram dez pessoas ao mesmo tempo.
Mau aproveitamento de um profissional, se queremos executar um simples script ou renomear um campo de uma tabela, para que precisamos de um DBA para uma atividade tão trivial? Seria mais interessante que ele estivesse ajudando em atividades como: trabalhar para dar maior desempenho e diminuir o tempo de resposta no banco, definir índices, ajudar na escalabilidade do banco, uma mudança de estratégia para um banco NOSQL ou NewSQL, bigdata, ajudar na criação de queries com mais desempenho ou talvez criação de views, etc.
Abandono na qualidade do projeto, o software que usa ferramentas muito antigas será a janela quebrada do seu projeto.
Desmotivar a refatoração do projeto, o fato mais comum para os requisitos é que eles mudam com uma grande facilidade, desse modo, a refatoração é importante tanto para um código e banco mais limpo tanto para um bom desempenho para a aplicação. Quando para realizar tal atividade precisa passar por um processo demorado, essa atividade acaba sendo muito custosa para o projeto e em alguns casos sendo descartável.
Ou o que eles precisam fazer?
Acredito que o primeiro passo é entender que engenharia de software não é comparável com outras áreas, assim, possuem características e metodologias próprias. Em seguida a área evolui muito rápida e precisamos evoluir junto com ela simplesmente “parar no tempo”.
Em relação das ações, o que eles precisam fazer é o processo totalmente inverso, ou seja, o de não centralizar informação e facilitar o acesso ao conhecimento. Descentralizar é fazer com que as informações circulem de maneira mais “livre” e que as soluções partem de qualquer parte da empresa. Estimular atividades como codingdojos, participação de eventos, wiki na empresa, etc. Uma equipe autogerenciável deve ser o sonho de qualquer gestor de TI que esteja em 2012.
Remover os atrasos do processo software é crucial para manter um ciclo saudável no desenvolvimento. Conhecer a filosofia “toyotismo”, que se tornou base para as metodologias ágeis, e dizer adeus ao “Taylorismo”, filosofia de Taylor que visa centralizar as decisões, é um pequeno passo para isso. Desconcentrar processos e decisões de software é muito mais do que apenas remover uma camada física desnecessária, delay tier, também é criar uma equipe auto-gerenciável, impedir que a empresa vire um museu, permitir que existam opções para solucionar um problema e que a mais adequada seja utilizada, deixar fluir a informação e fazer com que os profissionais se atualizem e utilizem tal conhecimento. Sobre tudo demonstrar que gosta do que faz e passar esse prazer para os outros membros da equipe, estimular para que eles também façam o mesmo.
Finalizamos aqui este artigo, espero que tenham gostado. Até a próxima.
