Pessoal,
É comum algumas empresas ignorem frameworks conhecidos pelo mercado e usarem soluções próprias?
Soluções próprias digo em vez de usar JPA/Hibernate utilizam outras estratégias para trabalhar com JDBC puro e em vez de utilizar frameworks MVC como Spring MVC, JSF utilizam frameworks desenvolvidos internamente.
Mais do que deveria.
Cara, não é comum… apesar de existir lugares onde se usa um framework próprio, mas com certeza é por causa da regra de negócio envolvida pelo sistema.
Não vale a pena perder tempo criando algo que já exista no mercado e ainda gratuito… Pode acontecer tb de um cara achar que o Hibernate é uma bosta assim como o Spring MVC e outros n frameworks e tentar fazer um melhor… mas enfim… é muito custoso criar um framework… 99%(to chutando) do mercado usa frameworks externos!
Infelizmente sim. =/
Acontece bastante sob a justificativa de que assim a empresa tem um maior controle sobre a tecnologia.
Em alguns casos é justificável, mas é muito, muito raro quando eles ocorrem.
Na maior parte das vezes, é mero medo tolo mesmo.
O problema é que com isto normalmente grande parte da equipe acaba saindo da empres usando a justificativa de que quer conhecer as ferramentas de mercado.
Concordo em nunca reinventar a roda, se é para ignorar usar ORMs ou frameworks MVC usado pelas comunidades, ok, mas pelo menos use JDBC ou JSP/Servlet diretos sem inventar frameworks particulares.
Uma das perguntas que fazia em entrevistas era se a empresa usava algum framework próprio, caso positivo eu já descartava. Claro que já caí numa furada dessas por falta de vivência, mas depois nunca mais, pois desmotiva, e os clientes se ferram sem saber que estão nas mãos da empresa desenvolvedora, mesmo tendo os direitos dos fontes. Geralmente isso ocorre mais em fábricas de software.
Acho que muitas decisões são tomadas sem procurar caminhos dentro da própria tecnologia. Hibernate é um caso clássico, reclamam de lentidão, mas quando vai ver usam ele como bala de prata, sendo que em situações complexas ou críticas o ideal é usar SQL nativo, que ele mesmo possibilita mapear automaticamente ou usar mais outros recursos nativos do banco. Detesto purismo, o importante é o bom senso.
[quote=norbAns]Pessoal,
É comum algumas empresas ignorem frameworks conhecidos pelo mercado e usarem soluções próprias?
[/quote]
Sim, é comum. Isso é conhecido como “Sindrome de Não-Feito-Aqui” ( Not-In-House ). As pessoas têm tendencia natural a querer criar tudo. Afinal software é um meio criativo.
Muitas vezes as razões por detrás são relevantes e corretas e isso leva ao aparecimento de novas tecnologias ( o ant, o mavem , todos os NoSQL , etc… )
Mas a maioria das vezes é apenas porque podem. É comum em lugares com dinheiro e sem responsabilização como bancos e grandes empresas. A intensão muitas vezes é boa, mas acaba sendo deturpada pela politicagem dessas instituições. Sempre tem alguém mais alto que vc que é burro que nem uma porta e não entende as vantagens de certas escolhas técnicas.
Isto tem origem na contratação de pessoas sem experiencia e sem perfil para criar esses frameworks. Então, as pessoas fazem o que podem, mas é como contatar um pedreiro para fazer um casa. Existem conhecimentos que apenas o arquiteto sabe e irá se preocupar em aplicar.
Uma vez trabalhei numa empresa que tinha um framework bem simples de persistencia. Que usava objetos para persistir em jdbc. Bem simples, pré-hibernate. O framework era simples, mas não era extensível, tinha muitas falhas em termos de modelagem, uso de abstração, não usava interfaces em lado nenhum. Quando foi preciso exigir mais dele, tivemos que o rescrever. Depois eu fiquei muito supreendido quando descobrir que tinha sido um professor da USP que o tinha criado. Ou seja, criar uma framework exige um tipo de experiencia que um junior, ou alguém acadêmico não tem. Exige prática. Exige vc já ter passado pelo mesmo problema várias vezes. E sobretudo exige vc saber analizar tecnologia. Em outro lugar exisgiam o uso de Struts 1 com DisplayTag 1.0
O display tag é um component bacana, mas não quando vc em milhares de linhas (centenas já dá problema). A versão mais moderna do framewokr permitia cria mecanismo de paginação de forma a só procurar no banco o que precisavamos quando o usuario navegasse, mas o cliente, que era um banco, não deixava usar a versão 1.1. A razão ? Nenhuma, simplesmente não podiamos usar. O problema era que a diretriz do banco mandava usar aquela versão e se usassemos outra poderia dar problema em outras apliações porque todas as aplicações corriam no mesmo servidor usando as mesmas bibliotecas. Ou seja, falta de inteligencia ou uso de recursos para resolver um problema de infra. A opção era fazermos a nossa própria tag de tabelas, mas ai teriamos outros problemas de custo e prazo pois esse componente não estava previsto.
Em geral, vc sempre deve confiar em quem já funciona, mas não deve colocar todos os ovos no mesmo cesto. Ou seja, por exemplo, persistência, use o hibernate, mas isole sua camada de persistencia de forma que o resto do sistema não saiba que existe o hibernate. Desta forma, no futuro vc pode mudar a tecnologia sem ter que reescrever o software. Este isolamento não é trivial e pela comodidade e velocidade de implementação as pessoas simplesmente abdicam de ter estes cuidados e acabam fazendo um péssimo design que leva ao consumo absurdo de recursos que poderiam ser usados para coisas mais uteis.
Um outro fenômeno é a desconfiança natural da empresa contratar alguém de fora para fazer o design porque “é muito secreto o que eles estão fazendo” e isso acaba que pessoas não preparadas ganhem essa responsabilidade. É o equivalente a vc não querer chamar um médico ou um encanador e vc mesmo fazer a operação ou tentar mudar os canos. Quando é coisas simples, dá certo. Tipo um raspão ou desentupir a pia do lava louça. Mas quando complica , não dá certo. E o problema das pessoas comuns é não saber onde está a fronteira. Onde acaba "a coisa simples " e começa “a coisa complexa”.
Finalmente existe o pensamento “Vamos fazer de pois mudamos”. Isto é o pior. Muita gente acha que isto é ser ágil. Não. Isto é ser incompetente. Se ha um jeito melhor use-o logo de inicio. Se vc não o achou porque não procurou, procure melhor. Existem rios de informação sobre bom design e bons princípios. Claro, que nem sempre as pessoas vão entender as nuances e tem até uns idiotas dizendo que isso é sobre-engenharia. Só é sobre-engenharia quando não poupa seu dinheiro ou tempo. Existe uma fonteira em fazer um design flexível e criar uma máquina de Rube Goldberg e existem principios para vc saber a diferença. Nínguem disse que é fácil, mas por isso mesmo que criar um framework não é trivial. ainda para mais quando vc tentar criar uma framework que dará suporte a todos os sistemas da empresa.
Eu acho que criar uma plataforma de aplicação da empresa (normalmente chamado de framework ou “infra”) é uma necessidade e quando bem feito pode poupar muito dinheiro à empresa. Mas quando mal feito - e é a norma - pode levar a empresa à falência.
Isto é ainda mais verdade me java, onde a plataforma java em si, é apenas uma plataforma virtual e ela espera que vc crie a plataforma de aplicação em cima dela. A JEE é quase isso, mas não é completa pois só versa em um aspecto do ecossistema da aplicação. É por isso que precisamos de mais frameworks, mas juntá-los de uma forma intelegivel e coesa não é simples, embora seja necessário. Como a necessidade é a mãe da invenção ( e da gambiarra) as pessoas são levadas a criar coisas muito loucas para suprir a necessidade. mas não olham o custo do investimento nem do retorno e sempre pensam “depois a gente melhora”. Ou seja, já injetam débito tecnico à partida e são felizes assim. Depois essas pessoas saem da empresa e quem fica que se tem que haver com as más decisões dos anteriores, decisões essas que pela politica e custo da coisa, não poderão ser revogadas. Até que o custo explode e alguém pede um novo framework e tudo começa de novo…
Eu já presenciei isso quando trabalhei com Visual Fox Pro, como a Microsoft parou de dar manutenção na linguagem, o pessoal da empresa precisou criar libraries gigantescas pra sanar as necessidades e praticalizar os processos.Mas de Java, acho que é realmente perda de tempo, ao menos se tentar construir uma nova solução acho válido, ou uma outra que contém mais benefícios das ferramentas já existentes, mas não vai ser fácil.
As vezes é comum criarem frameworks que encapsulam frameworks sob pretexto de, caso aquele framework de mercado ser descontinuado, possa ser trocado por outro sem que o código funcional desenvolvido seja alterado. Porém não fazem um encapsulamento completo e acaba sempre sobrando algo do framework o que inviabiliza a idéia original.