Vitor Pamplona

Innovation on Vision: Imaging , Enhancement and Simulation

8 dicas para escolher um bom framework

 Frameworks são bibliotecas bem estruturadas que realizam uma função bem definida. Normalmente muito bem documentados e precisos, os frameworks são acoplados as aplicações finais para solucionar problemas comuns. No mundo Java, há uma diversidade muito grande destas bibliotecas, o que é excelente, pois além de criar uma certa competitividade entre os frameworks, permite a um desenvolvedor escolher qual a solução se adapta melhor para o seu problema. Por outro lado, escolher qual framework utilizar torna-se mais difícil, exige mais experiência e astúcia. Utilizar um determinado framework pode ser muito bom, ou ser muito ruim, tudo vai depender da escolha.

O problema principal não está só em escolher, escolher é fácil, já que existem muitos que fazem os mesmo serviço, o problema está em escolher o melhor framework. Abaixo eu listo oito dicas que não podem passar despercebidas durante o processo de escolha, de filtragem dos candidatos.

A primeira coisa a fazer é fechar os olhos para a moda . Moda? Sim, moda em desenvolvimento de software ou o termo em inglês, hype. Hoje em dia é muito fácil criar um projeto e dizer que ele é uma maravilha, mesmo sem funcionar direito ou sem ter os requisitos completamente desenvolvidos. E isso não ocorre só no mundo livre, nos softwares proprietários há muito marketing e pouca qualidade tanto em empresas pequenas quanto em empresas grandes. Lembre-se a propaganda não faz o software, por isso não se deixe enganar, sempre verifique se aquilo que é apresentado realmente é feito pelo software daquela maneira.

A segunda dica é ter cuidado com o que se lê na internet . Devido aos inúmeros fóruns e listas de discussão existentes na internet, onde gente de todo o mundo costuma apresentar a sua experiência com determinadas ferramentas, cria-se muita opinião e pouco fato nas publicações. Muita gente dizendo que conhece frameworks, mas na verdade não faz mais que utilizar o básico deles e, quando precisa entrar a fundo na tecnologia utilizada, a pessoa apanha feio. Diversas pessoas falarão positivamente sobre um framework, incluindo os apaixonados por tal tecnologia, mas para falar negativamente poucas aparecerão e destas poucas, a maioria delas só falará isto porque são apaixonados por uma tecnologia concorrente. Assim como a típica disputa Java e. Net. Tente ouvir quem está no meio de campo, quem conhece os dois frameworks de fato e quem já utilizou os dois. Valide os comentários, verifique quanta experiência a pessoa tem para falar aquilo do software. Após isso, analise se você não vai acabar caindo na mesma situação que aquelas pessoas caíram e que as fizeram trocar de tecnologia.

 A terceira dica é identifique os limites . Todo o projeto, framework, linguagem ou ferramenta tem pontos fracos. Nada escapa. Normalmente estes pontos fracos não ficam descritos na página inicial do projeto, portanto é necessário procurar. Estude, faça testes, busque alternativas de execução, analise os efeitos colaterais, cace um erro, descubra o que não foi pensado e analise o que você não sabe. O ponto fraco de um projeto pode ser o motivo para você ter que trocar de tecnologia no meio do projeto, um passo complicado e que gera muito prejuízo.

A quarta dica é sobre a dificuldade de aprendizado , a famosa curva de aprendizado. Será que vale a pena o investimento no aprendizado de um framework novo para a equipe? Alguns frameworks fazem coisas muito simples, mas são complexos de entender e / ou usar. O próprio mundo Java é complexo por default. Um bom exemplo para esta pergunta é o uso do Apache Lucene para criar consultas poderosas nos dados de sua aplicação. A ferramenta dá um poder de pesquisa formidável, mas a maioria dos desenvolvedores não está acostumada a trabalhar com uma ferramenta dessas. Eles terão que aprender a usá-la da forma correta. Na verdade, até podem conseguir algum resultado em pouco tempo, mas o risco de estarem utilizando a ferramenta de maneira incorreta é grande. Alguém precisará ensinar para que o seu uso torne-se viável, e até que isto aconteça geram-se custos para a empresa. Caso opte-se por não utilizar o framework, a maioria dos desenvolvedores sabe fazer um like no banco de dados e, muitas vezes, basta isso para solucionar o problema. Não é a implementação mais poderosa, mas funciona e não gera nenhum custo.

 Porém, caso a sua equipe já trabalhe com Lucene a algum tempo e já pagou pelo aprendizado, pode ser uma boa alternativa, utilizá-lo em todas as aplicações, mesmo nas menores, e esquecer o like. Por que? Primeiro porque os desenvolvedores podem ficar mal acostumados e quererem usar o like em tudo, claro, é muito mais fácil. Segundo porque a empresa cria um padrão nos softwares que ela faz, e normalmente quando isto acontece, várias classes utilitárias são criadas para facilitar o uso. Quem sabe, depois do período de aprendizado, utilizar o Lucene para uma equipe pode ser muito mais fácil que fazer um like no banco de dados.

A quinta dica é a mesma utilizada pelos instrutores de auto-escola nas aulas de direção defensiva. Qual é a primeira pergunta que deve ser feita quando o motorista deseja ultrapassar um carro? Não, não é aquela: “ está vindo carro contra? ”. Mas sim essa: “ Preciso realmente ultrapassar? ”. A mesma pergunta deve ser feita ao deslumbrar uma vaga para um framework. Será que eu preciso realmente colocar um framework aqui? Simplicidade e Necessidade, busque o escolhido. A cada nova biblioteca adicionada no sistema criam-se novas dependências, a equipe deve ser atualizada, deve-se aprender a trabalhar com ele e seu software deve ser distribuído com esta nova API. Ou seja, aumenta-se a complexidade sobre o software, e complexidade gera custos. Quando o framework faz mais do que você precisa e você não tem a opção de ter uma versão reduzida do mesmo, você tem custos desnecessários. Um bom exemplo são os servidores de aplicação. Muita gente os considera primordiais a qualquer aplicação de médio / grande porte, mas não usam sequer 10% de seus recursos. Esquecem que às vezes um servidor de requisições RMI pode resolver muito bem o seu problema. Por que ter um software pesado, cheio de arquivos XML de configuração, uma documentação de mais de mil páginas, com inúmeras possibilidades de integração se você só quer um servidor para aceitar requisições e devolver dados as aplicações clientes? Em alguns casos, como numa rede interna, nem usuário precisaria ser validado e os problemas de segurança simplesmente não existiriam, ou não seriam tão primordiais quando um software para internet. Quem usa o só a parte de SessionBeans Stateless do EJB e mais nenhuma, ou poucas funcionalidades dos servidores de aplicação, está se complicando a toa. Perdendo dinheiro em configuração e deploy quando nada disso é necessário. Portanto fazer o que não é necessário, não é bom.

 E o que você diria se seis meses depois que você escolheu um framework, este é descontinuado? É isto pode acontecer e aí restam poucas alternativas: Ou o seu software nunca precisará de melhorias neste framework, ou você terá que trocar de framework ou a sua equipe precisará aprender a desenvolvê-lo. Qualquer uma das três opções geram custos e custos que podem ser muito altos dependendo do grau de dependência do framework. A sexta dica, então, é a continuidade do projeto e a atividade da comunidade envolvida. Pesquisar sobre o futuro da API é primordial, faça um levantamento sobre os responsáveis pelo projeto e questione-os sobre o interesse em continuá-lo, principalmente se o projeto for open-source ou software livre. Se o projeto já está parado a algum tempo, não possui formas de comunicação com os desenvolvedores principais ou estes mesmos demoram muito para responder, o projeto pode estar sendo descontinuado. Normalmente a movimentação em listas de discussões, fóruns e a to-do list são lugares propícios a este tipo de investigação. Atente para o líder do projeto, é dele a responsabilidade de manter pessoas trabalhando, gerando código e documentação para o projeto.

Ninguém, em situação alguma, gosta de software lento. Exato, a sétima dica é: analise a performance . Claro que dez milissegundos não farão falta há uma requisição web, pois a própria requisição costuma demorar dez vezes mais que isso, mas se algum dia o software precisar colocar esta perda de dez milissegundos dentro de um laço grande, o usuário pode ter que esperar. Cabe a quem escolhe a tecnologia detectar exatamente em quais situações ela pode ser danosa ao sistema. O Hibernate, por exemplo, é uma excelente ferramenta de mapeamento O / R, mas torna o seu software mais lento do que se fosse feito com JDBC e queries nativas em relação ao banco utilizado. Porém o uso deste framework traz uma grande produtividade para a equipe de desenvolvimento. Quando usar um ou quando usar o outro vai depender da velocidade exigida pelo usuário. Vale ficar atento que muitos usuários não pedem um sistema rápido, mas na verdade eles querem!

Oitava dica. Abandone anseios pessoais . Lembre-se que você está escolhendo um framework para a sua equipe usar, não só para você. Esteja ciente de que o software será bem recebido pela sua equipe.

Resumindo:

  1. Elimine os hypes.
  2. Cuidado com o que se lê na internet.
  3. Busque os pontos fracos.
  4. Analise a dificuldade de aprendizado.
  5. Busque pelo escolhido.
  6. Analise a continuidade do projeto.
  7. Analise a performance da solução.
  8. Abandone anseios pessoais.

Posted in Jul 22, 2008 by Vitor Pamplona - Edit - History

Showing Comments

Oi Vitor. Excelente post. Gostaria de saber se seu blog tem um feed que mostre os últimos posts adicionados. Ao adicionar seu site no meu leitor de feed só consigo ver o último post.

- - nyarlathotep

- - Posted in May 31, 2008 by 189.89.109.115

Olá,

Segue a url do feed: http://vitorpamplona.com/lastChangesRss.pr

[] s

- - Posted in May 31, 2008 by Vitor Pamplona

Grato pela atenção. Consegui adicionar no Google Reader e ver todos os posts. Por algum motivo, só estou conseguindo ver o último post no gadget do IGoogle. Continue escrevendo, seus posts muito bons.

- - nyarlathotep

- - Posted in May 31, 2008 by 189.89.109.115

Excelente post, verdades que poucos gostam de ver e ouvir.

- - Edson Gonçalves

- - Posted in May 31, 2008 by 201.43.62.79

o_O. Esse post tu te puxo. Muito bom mesmo.

- - Vincent Maia

- - Posted in May 31, 2008 by 189.27.240.113

Bah, uns dos post dos blogs brasileiros de tecnologia com uma visão tão realista. Parabéns.

- - O

- - Posted in May 31, 2008 by 189.6.152.222

Nona dica: não pense em criar o seu framework antes de pesquisar sobre os existentes.

Já vi gente reinventando a roda e achando isso bonito. Tsc tsc.

- - Marcos Dell Antonio

- - Posted in May 31, 2008 by 201.86.65.43

É uma excelente forma para aprendizado.

Por conta dessas excentricidades eu já vi uma empresa que todos os softwares que ela desenvolve são feitos em framework próprio, independente da linguagem. Quando precisa desenvolver em uma linguagem nova o cara que criou (ou outro) porta o framework para a nova linguagem. Coisa de doido, acho que foi um dos melhores frameworks de persistencia e apresentação que já vi.

- - Eu

- - Posted in May 31, 2008 by 189.31.38.92

Vitor, baseado no que você escreveu quais são hoje os frameworks que se encaixam nas dicas acima?

- - Alexandre

- - Posted in Jun 2, 2008 by 201.9.203.9

Se eu soubesse essa lista eu teria postado a lista e não as dicas:)

[] s

- - Posted in Jun 2, 2008 by Vitor Pamplona

rsrsrsrs, é verdade sou novo no mundo java tenho uns 6 meses de muita dedicação, não conheço outra linguagem, mas fico de 11 a 13 horas por dia somente tentando aprender java, ja comprei inúmeros livros, tenho muitoooosssss endereços de blogs e sites que falam sobre java, e analisando francamente repito o post do amigo acima,

Um dos blogs brasileiros de tecnologia com uma visão tão realista. Parabéns.

- - Posted in Aug 18, 2008 by paulo henrique manhani

Parabéns pelo post hein cara

Adorei..

- - Carutcho - Reinaldo Torres

- - Posted in Oct 22, 2008 by 200.186.126.58

Verdade, muitas coisas precisam ser analisadas e testadas, eu mesmo estou substituindo a idéia de persistencia de um sistema que venho fazendo, pois o no inicio o uso de JDBC foi pouco produtivo, já que a manutenção de níveis mais internos da aplicação fora extremamente trabalhosa, o que me motivou a fazer usando TopLink ao invéz de Hibernate (Hibernate é incapaz de trabalhar com SQLite, ou extremamente dificultado), contudo quando uma manuteção refletia justamente uma das entidades, então o resultado era algo muito difícil de ser mudado, além de o código ser enorme e cheio de detalhes e algumas vezes tinha a impressão de o sistema ter vida própria.

Vendo estes problemas fui eu pesquisar formas de melhor persistencia e manutenção a níveis mais baixos, dentre elas estavam o NeoDatis ODB, Prevayler e DB4O (este último já exclui da minha lista pelo tamanho do mesmo), assim testei tanto o NeoDatis quanto Prevayler, do qual o vencedor foi justamente o NeoDatis, tanto em velocidade de inserção de vários dados quanto em simplicidade e melhor manutenção de sistema.

Claro que no final das contas estou rescrevendo completamente o sistema, contudo esta bem melhor organizado e bem mais facil de ser mantido, mas isso é por conta do framework escolhido? Nada disso, mas pelos padrões de projeto utilizados que motivaram a uma melhor estruturação.

Creio que uma dica a mais seria estudar quais padrões tais frameworks são feitos, pois a partir deles já terá uma melhor idéia de como devem ser utilizados.

- - cristo

- - Posted in Apr 21, 2009 by 189.70.162.131

Olá, gostei muito do seu POST eu citei ele no meu blog. Estou em busca de um Framework para PHP que utilize MVC e estou começando a pesquisar sobre o Codeigniter, qualquer ajuda será bem vinda. Comment for me... rs...

http://my.opera.com/danielpsf

Meu Blog, caso você queira conferir o que eu escrevi e citei sobre você!

Abraços.

- - Daniel Pedro dos Santos Fernandes

- - Posted in May 13, 2010 by 200.216.229.180

Add New Comment

Your Name:


Write the code showed above on the text below.