Frameworks, treinamento e qualidade

Estivemos a pouco visitando um cliente que pretende desenvolver/utilizar um framework de programação visando um maior controle e desempenho dos aplicativos que irão rodar na empresa. Hoje em dia eles não têm uma padronização na programação dos softwares da casa e, pior, estes não são instrumentados. Esta falta de instrumentação, por sua vez, é responsável por certo caos no dia a dia da operação, pois fica difícil: saber que parte do aplicativo está causando problemas; fazer um capacity planning; etc.

Conversando sobre as expectativas reais que eles deveriam esperar com o uso de um framework, alertamos:

1. Um framework não garante desempenho. A chance de uma query causar scan table ou um lock, ou de um programador causar um loop infinito ou um memory leak, ou etc., é independente do uso ou não de um framework. No entanto, um framework pode ajudar a prover informações em tempo de compilação (ex.: forçando a tipagem forte) ou execução (ex.: incluindo log e instrumentação) para que seja mais simples achar e corrigir erros;
2. Um framework não é barato. Ele exige um treinamento ostensivo para arquitetos e programadores, pois ele induz a uma forma de desenhar e programar um aplicativo. No entanto, quando a cultura está estabelecida, é normal conseguir melhor qualidade e produtividade devido ao reuso e alto grau de repetição nas tarefas de programação;
3. Um framework por si só não garante uma programação correta. É fácil errar uma fórmula, é muito simples escrever uma query que traz milhões de linhas, é simples armazená-las numa variável de sessão, é mais simples ainda fazer um binding destas milhões de linhas em um grid. Porém, com boas práticas de revisão de design e de programação é simples visualizar erros como estes.

Portanto, aviso então aos navegantes: frameworks devem ser acompanhados por treinamento, arquitetura e processos que garantam a qualidade, produtividade e desempenho. Sozinho, nenhum destes vem de graça.

Este caso me fez recordar também de um outro cliente que produz um software altamente dependente do bom uso do banco de dados e que me pediu ajuda para melhorar a qualidade do produto. Como ele não tinha nenhum especialista em banco de dados e vendo que boa parte dos problemas advinha disto (sim – ele tinha muitos processos), recomendei a ele a contratação ou o investimento na formação de especialistas na empresa. Neste instante, para a minha surpresa, obtive uma resposta veemente: - não quero ficar refém de um profissional caro como este!

Bem, pelo que me consta, até hoje o produto tem problemas de qualidade e desempenho!

O que há de comum nestes dois casos? Creio que até hoje ainda não há solução de software/hardware que garanta qualidade e desempenho de um aplicativo sem um investimento mínimo no lado do recurso humano. Treinamento, um mínimo de processos e ferramentas adequadas faz a diferença entre o sucesso ou fracasso no uso de uma tecnologia.

Estou errado?

Comments

• Anonymous
  April 16, 2009
  PingBack from http://asp-net-hosting.simplynetdev.com/frameworks-treinamento-e-qualidade/

• Anonymous
  April 16, 2009
  Otavio, Eu entendo framework basicamente como uma "pratica padrão", sera que estou errado ? Claro que frameworks geralmente tem N ferramentas, metodologias, recursos e bla bla bla mas eu creio estar claro para todos que ele não faz o serviço sozinho e muito menos é uma opção para quem quer evitar erros... é sim uma opção para minimizar um ambiente despadronizado OU iniciar um projeto bem elaborado. O caso que citastes de dependendia de um profissional eu creio que possa ser descomplicada caso exista ao menos uma documentação macro do processo, que ja ajudará muito o proximo desenvolvedor (de banco de dados no caso) a assimilar o que foi feito pelo profissional "caro". Aqui, optamos pelo velho e conhecido DFD para proporcionar uma visão ampla dos processos mais complexos e uma cartilha de boas praticas (NÃO USAR CURSOR, FAZER TUNNIG DA QUERY e algumas outras verificações basicas). Eu acrescentaria no seu hall de soluções (treinamento, processo, ferramenta) uma documentação (que deve ser o seu "processo") legivel a todos da area de TI... por isso eu creio que o bom e velho DFD ZERO ajuda muito. ps: aqui também nossas rotinas se concentram em banco de dados e por isso achei seu post muito interessante. att, Nilton Nodari

• Anonymous
  April 17, 2009
  Concordo plenamente, Nilton. Parte do trabalho do arquiteto é definir (documentando) as melhores práticas para que possam ser seguidas. Deixei isto como parte do processo (no sentido do TOGAF), mas vale a pena reforçar. Obrigado pela lembrança, Otavio

• Anonymous
  April 20, 2009
  Certíssimo. Quem faz o software são as pessoas. Frameworks são base. Na verdade, tudo é base. O código final vai ter que ser mantido e evoluído por alguém. Ignorar boas contratações é uma boa maneira de se tornar obsoleto.