Está pensando em Framework? Não faça isso!

É, por mais incrível que pareça, isto é muito comum no mercado. Mas
não pense que falo só de Java. Está certo que 90% das empresas que
trabalhei até hoje, sendo de TI ou não, tem frameworks
feitos em casa.

Neste artigo vou argumentar porque é uma péssima
idéia fazer frameworks em casa e como isso pode ser muito ruim para sua
empresa e para sua equipe, ou algo parecido com isso. Trabalhei com
frameworks de VB 6.0, ASP 3.0, PHP, Java e até JS. Por incrível que
pareça já vi louco fazer framework para JS em empresa de negócios (não
TI).

Um Framework?

Vamos a algumas definições segundo o site thefreedictionary:

• Uma estrutura para suportar ou englobar algo, principalmente um
  suporte em forma de esqueleto para alguma coisa a ser construída
• Uma plataforma de trabalho
• Uma estrutura fundamental para trabalho
• Um conjunto de suposições, conceitos, valores e práticas que constituem uma maneira de ver a realidade.

Desculpem
se a minha tradução não foi a ideal, mas acho que consegui passar a
idéia geral da coisa. Bom, como vocês podem ver não existe nada demais
em um framework.

Exemplo de Framework

Sei
que você provavelmente estava esperando um jar mas, como pode ver, este
conceito saiu da vida real e depois foi parar na engenharia de software.
Voltando à definição de framework, eu gosto muito da última, “um conjunto de suposições, conceitos, valores e práticas que constituem uma maneira de ver a realidade”. Para
mim é a mais adequada quando falamos de software.

Acredito que
com isso o leitor já consiga estabelecer a diferença de
rotina/biblioteca para framework. Falando de frameworks Stripes, Rails,
Code Igniter, Django, etc., são exemplos de frameworks.

Alguns mitos de Frameworks

#1 Precisa de um super Arquiteto

Esse
é o primeiro mito. O pessoal acha que para fazer um framework precisa
de um super arquiteto que saiba tudo de todas as API que
existam. Logo, esse cara tem que ganhar muito e o pessoal deve ter medo
dele e, se possível, não o questionar como se ele fosse um semi-deus.

#2 Vai aumentar a produtividade dos desenvolvedores

Isso
é muito difícil, até mesmo por uma regra simples de esforço-retorno
80%-20%, logo se vende a ilusão de que o framework vai fazer o trabalho
dos colaboradores mais fácilmente, de forma mais divertida e, ao mesmo tempo, lucrativo para
empresa.

#3 Vai ser rápido e fácil de construir

Outra
lenda urbana. Nunca é rápido e muito menos fácil. Na prática o que
acontece é que quem faz um framework hoje em dia corre o grande risco
de cometer todos os erros que as outras pessoas do mercado já passaram,
além de gastar dinheiro e recursos da empresa de forma errada e sem
grande ROI.

#4 As soluções de mercado não atendem

Os
frameworks de mercado não atendem e não podem ser customizados ou é
muito esforço para usar os pontos de extensão dos mesmos. É mais fácil
construir um do Zero por que a implementação em casa vai ser melhor,
mais rápida e mais eficiente que a da ORACLE, IBM, MS e outras
empresinhas.

#5 Tudo é importante

Às
vezes não vemos frameworks por aí, e sim muros que separam o
desenvolvedor da realidade. É isso mesmo, é quase o deserto da matrix… O framework irá proteger o desenvolvedor desta crueldade e complexidade
imunda e absurda. E tudo isso com meia dúzia de @notações, XMLs de Bind
e algumas execuções do REGSVR32.exe myWTFDLL.dll.

#6 O Arquiteto ficará na empresa

A
pessoa que construiu o framework é extremamente comunicativa, documenta
muito bem o que faz e da treinamentos e, além disso, o código é tão bom
que qualquer mero mortal pode dar manutenção no código. No mais, isso
não é necessário porque o Arquiteto progenitor que pariu o framework
nunca irá sair da empresa e muito menos os seus sucessores.

#7 O framework atende todos os problemas passados, presentes e futuros

Esta
é bala 🙂 Pois é, uma vez feito o megazord, ele servirá para resolução de
todos os problemas que existem hoje, além dos problemas que já existiram
e os que vão existir. Também os que são criados pela “solução” serão
solucionados com alguns paths.

Caindo na Real

O
framework que sua empresa desenvolveu não é eficiente, existem pelo
menos 5 soluções de mercado que fazem a mesma coisa de forma muito
melhor e mais fácil. A Solução “solução” não deu retorno, você gastou
um monte, você tem muitos bugs e cada vez mais workaround.

O
“Arquiteto” que fez o megazord foi embora os dois substitutos depois
dele foram também. Ninguém mais quer mexer nisto e metade da equipe foi
embora por desmotivação, 3% ficaram porque descobriram que não sabem
mais programar sem o megazord e estão presos no deserto da matrix, e o
gestor da empresa nem sabe a metade destes problemas.

Fazer um
framework não é brinquedo, não é fácil, não é para qualquer um, você
precisa de um problema. E digo mais, precisa ter um cenário em que não
existem soluções prontas para esse problema ou que não possam ser
integradas e customizadas.

A missão e os valores da sua empresa
batem com a construção deste framework? Eu duvido muito. Ainda hoje existem
por aí frameworks feitos em COBOL, que foram feitos em casa há
cerca de 20 anos, mas que “funcionam”. A questão é: valeu a pena?
Duvido muito.

O Arquiteto senior não é aquele que acha que pode
construir um framework, mas sim é aquele que não quer fazer isso porque
prefere usar algo pronto e quer resolver os problemas do negócio.

Abraços e até a próxima.