Esta 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, esta certo que 90% das empresas que trabalhei ate hoje, sendo de TI ou de negocio(não TI) tem frameworks feitos em casa.
Neste post vou argumentar por que é 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:
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 de mais em um framework.
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ácil, divertido 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...
As vezes não vemos frameworks por ai e sim muros que separam o desenvolvedor da realidade é isso mesmo é quase o deserto da matrix...
Neste post vou argumentar por que é 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:
- 1 - Uma estrutura para suportar ou englobar algo principalmente um suporte em forma de esqueleto para alguma coisa a ser contruida.
- 2 - Uma plataforma de trabalho .
- 3 - Uma estrutura fundamental para trabalho.
- 4 - 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 de mais em um framework.
Exemplo de Framework
Sei que você provavelmente estava esperando um jar, mas como pode ver este conceito sai da vida real e depois foi parar na engenharia de software. Voltando a definição de framework, eu gosto muito da 4 definição 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 precise saber tudo de tudo que API que exista, e 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...
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 precise saber tudo de tudo que API que exista, e 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ácil, divertido 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...
As vezes não vemos frameworks por ai e sim muros que separam o desenvolvedor da realidade é isso mesmo é quase o deserto da matrix...
Deserto cruel da realidade da matrix
O framework ira 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 ficara 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 por que o Arquiteto progenitor que pariu o framework nunca ira 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 servira para resolução de todos os problemas que existem hoje além dos problemas que já existiram e os que vão existir e o que são criados pela "solução" também 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 a equipe metade foi embora por desmotivação, 3% ficaram por que 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.
O missão e os valores da sua empresa batem com a construção deste framework? Eu duvido muito. Existem frameworks feitos em COBOL por ai hoje em dia que foram feito em casa a cerca de 20 anos atrás mas que "funcionam". A questão é valeu a pena? Dúvido muito.
O Arquiteto senior não é aquele que acha que pode construir um framework mas sim é aquele que não quer fazer isso por que prefere usar algo pronto e quer resolver os problemas do negócio.
Abraços e até a próxima.
#6 O Arquiteto ficara 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 por que o Arquiteto progenitor que pariu o framework nunca ira 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 servira para resolução de todos os problemas que existem hoje além dos problemas que já existiram e os que vão existir e o que são criados pela "solução" também 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 a equipe metade foi embora por desmotivação, 3% ficaram por que 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.
O missão e os valores da sua empresa batem com a construção deste framework? Eu duvido muito. Existem frameworks feitos em COBOL por ai hoje em dia que foram feito em casa a cerca de 20 anos atrás mas que "funcionam". A questão é valeu a pena? Dúvido muito.
O Arquiteto senior não é aquele que acha que pode construir um framework mas sim é aquele que não quer fazer isso por que prefere usar algo pronto e quer resolver os problemas do negócio.
Abraços e até a próxima.