Eu participei como desenvolvedor de 4 projetos em Java nos últimos 12 meses, 3 deles tinham algo em comum: tinham uma arquitetura de referência, mais de 4 anos, baseados no struts 1.x, framework caseiro desenvolvido em cima do struts, modicações caseiras em APIs conhecidas sem contribuição com o projeto original [fork antigo ainda por cima], código altamente acoplado e sem coesão, arquitetura baseada em BOLOVO e principalmente sem testes [o último até que estava com uma tentativa de testes de aceitação com o Selenium mas com grandes dificuldades por conta de todos os problemas].
Em projetos antigos é comum encontrarmos esse tipo de situação, eu mesmo já criei meu framework caseiro em coisa por volta de 6 anos atrás, mas hoje em dia isso não só é algo abominável como um desrespeito pelos profissionais, ainda mais após tanta evolução nos últimos 10 anos.
Conversando com um amigo que trabalha em uma grande empresa de planos de saúde, ele me falou que o “arquiteto java” dessa empresa [conhecido por sua fama de criador de “Framearras”] convenceu a diretoria sobre um projeto recente que se baseia no desenvolvimento de um framework específico para a empresa [eles já possuem um framework caseiro que é um terror e bem conhecido por grande parte dos desenvolvedores locais].
É impressionante como não acaba essa tara de desenvolvimento de frameworks caseiros, qual a necessidade de uma empresa que tem TI como meio [e não como fim] de desenvolver um framework para desenvolvimento de software?
Olha que não é de hoje que eu falo sobre os perigos de frameworks caseiros, mas parece que os defensores desse tipo de abominação se reproduzem como coelhos.
Engraçado que no último projeto que participei eu recebi um treinamento de um dos criadores do framework caseiro que deveríamos usar na construção, alias na continuação de um sistema que está há 5 anos em desenvolvimento sem sinal de algo ir para a produção.
Os argumentos que ele usou foram os seguintes [anotei a frase para não esquecer]:
“Amigos, é importante um framework criado pela propria empresa para padronizarmos o desenvolvimento, diminuindo a curva de aprendizado e ganharmos na produtividade, utilizando padrões consagrados, obtendo reuso nos componentes de negócio e garantindo a manutenibilidade pela fácil criação de código, principalmente CRUD.”
Segredo do fracasso
Vou expor algumas considerações sobre essa frase dele:
Curva de aprendizado
Se algo é complexo de entender por quem conhece os padrões daquilo que se deseja desenvolver, é porque não serve mesmo. Não há como comparar um software opensource consagrado no mercado onde centenas de milhares de desenvolvedores já aperfeiçoaram com algo feito em casa.
Ganho na produtividade
A desculpa número um de todo framework caseiro é a famosa produtividade, sendo que voce sempre perde produtividade porque insere algo fora da normalidade no cotidiano do desenvolvedor. Além do que é insano voce ter uma produtividade no inicio – se fosse o caso, já que não é – comprometendo todo o ciclo de vida restante da aplicação por conta disso.
Porque é isso que acontece, todos esses frameworks caseiros são pensados e desenvolvidos para facilitarem a construção de CRUDs no inicio da aplicação e você tem que sacrificar todo o resto para satisfazer esse capricho que pode ser automatizado facilmente com tecnologias atuais.
Utilização de padrões
Ninguem pode saber que padrão utilizar antes de saber qual o problema, isso é impossível. Ou vai usar um martelo para furar uma parede ou uma furadeira para pregar um prego.
Reuso de componentes
Não existe reuso de objetos de negócios, nenhum processo é semelhante nem que seja na mesma organização ainda mais tentando reusar código por meio ide interface gráfica comum em projetos com dificuldade incial até de separação de pacotes.
Uma alternativa geralmente usada é se comunicar via API ou uma estrutura de serviço como WS, JMS, whatever e não aproveitando uma tela em um sistema distinto.
Aumento da manutenibilidade
Sistema como Frameworks caseiros sempre são dificeis de manutenção por que falta documentação, gente que conheça realmente [além dos próprios criadores], código sempre acoplado, falta de testes, maturidade, e principalmente propósito real [como não haver um existente no mesmo segmento].
Em todos os frameworks caseiros que trabalhei e não foram poucos, a manutenção é algo punitivo porque temos que satisfazer o framework e não o negócio.
Garantia da qualidade
Não há qualidade alguma em frameworks caseiros, pelo contrário, pelo conjunto de más práticas já expostas, o que acontece na realidade é que os sitemas desenvolvidos com esse tipo de ferramenta apresentam uma qualidade baixíssima.
Fork em frameworks do mercado
Problema em fazer um merge no futuro, voce não terá tempo e recurso suficiente para isso. Melhor solução seria submeter patch e codigo para o framework original e acompanhar o desenvolvimento deste. Deixa o desenvolvimento preso a versões antigas.
Associado a cascata.
Quase impossível você encontrar um framework caseiro em uma equipe ágeil, até porque isso fere vários dos valores e princípios.
Menos codificação
Na verdade duplica a codificação para satisfazer o framework.
Extensão de classes genericas
Acoplamento, referencia cíclica, etc… dá até preguiça de escrever.
CRUD Driven Design
Quebra o principio do XP que é fazer o mais importante e crucial primeiro, CRUD nunca é o mais importante. Se voce faz o CRUD primeiro, cria a regra de negócio e refaz todo o CRUD depois.
Geração de codigo sempre reescreve as informações, merge manual.
Frameworks caseiros são #ESFM. Vão complementando com as más práticas…
Typically chemist’s shop can sale to you with discreet treatments for various health problems. There are numerous of safe online pharmacies that will deliver medications to your address. There are divers medicines for each afflictions. Learn more about “viagra manufacturer coupon“. Maybe “viagra discount coupons” is a very much complicated matter. Matters, like “coupons for viagra“, are coupled numerous types of heartiness problems. If you need to take prescription medications, ask your pharmacist to check your testosterone levels before. Sometimes the treatment options may switch on erectile dysfunction remedies or a suction device that helps get an erection. Keep in mind web-site which is ready to sell erectile dysfunction drugs like Viagra without a prescription is fraudulent. When you purchase from an unknown web-site, you run the risk of getting counterfeit remedies.
Muito bom o post, CMil! O mais interessante foi que, hoje pela manhã, estava conversando exatamente sobre isso com o meu colega aqui no trabalho. (Sim, estou trabalhando em pleno sábado, rs.)
Vou indicar seu post para ele ler. Parabéns!
Abs
Assunto batido, mas é um problema que nunca muda!
Já trabalhei com vários frameworks caseiros, alguns até bonzinhos com algumas idéias interessantes, mas ainda assim os ganhos são irrisórios se levarmos em consideração os problemas trazidos por eles.
O problema é que frameworks caseiros são criados pensando em resolver problemas de CRUDs e relatórios, e não em resolver problemas de negócio (o que é realmente dificil, já que todo software é diferente), por isso nunca dão certo.
Enfim, por mais que tentemos pregar contra isso ainda seremos vistos como “do contra”.
Agora te pergunto, se este é um assunto tão batido então por que o governo federal está investindo pesado -nosso dinheiro, diga-se de passagem- em um big-mega-power-framework-caseiro (http://www.frameworkdemoiselle.gov.br/)?
Excelente artigo, Milfont.
Que leitura esplendida, parabéns pelo post, Milfont.
Você conseguiu em poucas palavras expor e explicar os principais problemas e motivos para não se criar um framework caseiro, parabéns!
Eu tenho me deparado várias vezes – nos dias de hoje, pasme! – com equipes pensando em desenvolver frameworks caseiros, com gerentes que não tem a mínima idéia e me chamam pra dar consultoria no framework caseiro deles (sim, isso acontece) e por aí vai.
Belíssimo post Milftont, sei na pele o que é isto cara! Sabe o que eu fico mais triste, é ver estas “peças raras” pregando a produtividade e a simplicidade. Como você mesmo disse, é produtivo apenas para criar um CRUD de código e descrição. Grande coisa!
Se os membros da equipe não tem conhecimento técnico para suficiente para resolver problemas de negócios, não pense duas vezes, demita-os (http://www.akitaonrails.com/2009/03/30/off-topic-net-negative-producing-programmer).
É triste ver estes “pseudo” arquitetos criando soluções “mágicas” e empresas e governos comprando estas coisas. Observando agora, estes frameworks caseiros são mais comuns só aqui no Brasil, não tenho conhecimento deste “fenômeno” em outros países.
@Alberto Leal, é um assunto que por mais batido nunca sai de moda 🙂
@Rafael Ponte, de idéia boazinha o inferno está cheio 🙂 eu não consigo ver nada de interessante e um FW caseiro e nunca vou parar de bater pesado nisso, agora mais ainda, isso é um desrespeito.
@Jeveaux, o que motivou esse post foi justamente eu tomar conhecimento que uma grande empresa nacional com uma experiência trágica com isso ainda pretende construir um segundo, aquela historia, errar pela segunda vez…
@Marcos Sousa , sabe que sinceramente eu nunca tinha pensado nisso? Vou investigar se esse fenônemo é tupiniquim.
Depois de inúmeros fatos comprobatórios da escolha errônea de frameworks caseiros para o mundo corporativo, o que resta fazermos para acordar as empresas para esse fato?
@Rafael Carneiro , sinceramente essa é uma pergunta que me faço diariamente e ainda não tenho uma resposta satisfatória.
Excelentes colocações, Milfont. Não há muito o que se comentar, você já sumarizou tudo muito bem e de forma muito clara e correta.
Em relação ao comentário do Rafael Carneio sobre o que resta fazermos, bem, não resta nada. Na minha pouca experiência, já vi 4 frameworks caseiros sendo construídos. Na primeira vez, era essencial, falo de épocas pré-Struts, Servlets ainda eram cachorros sem coleiras… Da segunda vez em diante, o que vi foram escolhas políticas e/ou falta de profissionalismo por parte do arquiteto responsável.
Sobre escolhas políticas é óbvio que sabe-se o que estará sendo construído, não existe a “culpa”, sim uma conjuntura – e todo profissional irá passar por isso durante sua carreira.
Agora, no que falo sobre falta de profissionalismo, falo da utilização da empresa como plataforma de curiosidade para experimentar tecnologias ou a falta de maturidade e não buscar soluções com pessoal especializado. Quando se trabalha numa empresa onde é realizada uma escolha nesses moldes, por mais que você não esteja envolvido na questão, você é sempre cobrado por seus pares profissionais de TI sobre a escolha realizada.
Então como “acordar as empresas para este fato”? Deixe claro sua posição desde o começo do projeto ou mesmo quando você chegar com a carroça andando. Enquanto não podemos decidir, temos que tentar influenciar. Não há argumentos contra fatos…
Oi Leonardo,
faz mais de um ano que bloguei sobre esse mesmo assunto, o Milfont também e algumas dezenas de outros blogueiros.
Concordo em gênero, número e grau com o seu comentário. Sobre a passagem a respeito de escolhas políticas, esse é um dos principais (senão o principal) focos do problema. É aí que mora o perigo: pessoas não técnicas tomando decisões.
Participei de um projeto que foi desenvolvido um framework caseiro. Perdemos meses refatorando, mudando, voltando e mudando novamente. Incluiam uma “feature” do sistema e o framework se quebrava por inteiro. Resultado disto? Mais consertos, remendos e band-aids pelo framework.
No final de muitas conversas e reuniões, foi decidido dar um fork no projeto e utilizar uma tecnologia (especificação) adotada no mercado. Conclusão disso tudo: tempo e dinheiro perdidos por falta de profissionalismo.
Enfim, devemos sempre duvidar de pseudo arquitetos que participaram desse tipo de processo e por onde passarmos fazermos o máximo para esse problema não mais ocorrer.
Eu vivo essa realidade… E sei como é complicado trabalhar com uma estrutura precária. Como diz o carneiro, o que devemos fazer pra mudar essa mentalidade?? @Rafael Carneiro, o grande problema é que normalmente quem toma as decisões são pessoas com uma mentalidade muito atrasada em tecnologia e sem conhecimento suficiente e não querem escutar quem tem…
Parabéns pelo post milfont..
Abração..
Pingback: No more DAO’s | Rafael Ponte
http://www.joelonsoftware.com/articles/fog0000000018.html
Pingback: Palestra Agilidade no Mundo Real - Milfont Consulting
Existe um antipattern que se chama “Reinvent the wheel”, que diz que não é necessário re-inventar a roda, uma vez que ela já exista. Mas aí vem a máxima desses arquitetos de frameworks caseiros: “Ah! Mas quando desenvolvemos o framework, não existia isso.” Constatando, o Struts surgiu em 2000 e nessa época surgiram outros mil frameworks iguais. Fico na dúvida se esses sistemas são tão velhos à ponto de reinventar a roda, por causa de um capricho da empresa ou do arquiteto ou se existia mesmo a necessidade do desenvolvimento de um próprio. Na minha opinião, se o segundo cenário foi contemplado, o sistema ainda deve estar em desenvolvimento e o framework deve ter sofrido poucas alterações desde então. Cuidado, você pode ouvir coisas do tipo: “Nosso sistema é desenvolvido em Java 1.4, pois o cliente exigiu isso”.
Não somente os frameworks MVC, mas a reinvenção da roda afeta os pequenos utilitários do dia-a-dia: as APIs! Cuidado! Até nas coisas pequenas temos os famigerados caseiros.