No desenvolvimento de projetos de software, saber quando recorrer a uma biblioteca/framework e como optar por uma entre muitas, não é tão óbvio quanto parece. Neste artigo decidi sintetizar o processo. Tentarei abstrair-me da linguagem/runtime (PHP, Java, .NET, etc.) em causa, visto que os conceitos são transversais.
Não confunda bibliotecas, frameworks, serviços, boilerplates e APIs.
- Biblioteca: conjunto de recursos (métodos, funções, ficheiros, etc.) relacionados entre si, incluidos no projeto sob a forma de “pacote” (ex: jQuery, Apache Commons para Java, Intervention Image para PHP, AFNetworking para iOS, Math.NET para .NET)
- Framework: “base de trabalho” ligada a pelo menos uma camada de software, que oferece uma forma diferente de fazer as coisas de forma mais simples (pode embutir bibliotecas) (ex: AngularJS, Spring para Java, Laravel para PHP, JSONModel para iOS, Ruby on Rails para Ruby);
- Serviço: conjunto de capacidades oferecido por uma entidade externa à aplicação, numa rede local ou na cloud (ex. Firebase);
- Boilerplate: projeto sample a usar como ponto de partida (ex. HTML5 Boilerplate);
- API: a “cara” (inputs/outputs) de um sistema (que por sua vez pode ser uma biblioteca ou serviço). Uma API é a interface para o programador; uma GUI é a interface para o utilizador.
Gostei especialmente da seguinte definição:
A library is a set of reusable functions or data structures that are yours to use. A framework, on the other hand, has an architecture or programming model, which requires an application be designed (divided into modules) in a certain way (application architecture) to use it. I like to think that while you use a library, a framework uses you.
Porquê usar bibliotecas e frameworks?
Reutilizar é uma palavra de ordem em engenharia de software. Evitar “reinventar a roda” é a base racional para a utilização de bibliotecas e frameworks. Evite desenvolver software que não seja o “core do seu negócio”. Não faz sentido refazer código criado, testado e mantido por outros que se dedicam a isso. É para isso que existem recursos “empacotados”, prontos a usar.
Uma aplicação pouco complexa (ex: intranet, app iOS) pode recorrer a dezenas de bibliotecas e algumas frameworks. A maioria é gratuita e muitas são open source.
O “problema” é que existem inúmeras formas de resolver o mesmo tipo de problema. A internet, um espaço sem barreiras, tem incontáveis ofertas. Por onde começar? Como filtrar? Deve então ser feita uma abordagem sistemática no processo de seleção.
Precisa da biblioteca ou framework?
Em primeiro lugar deve questionar se realmente precisa de uma nova biblioteca ou framework. O problema que está a resolver é um problema comum (de outras pessoas/projetos)? Se sim, de certeza que alguém já se debruçou sobre o assunto. Considerar o uso de uma biblioteca/framework torna-se compensador em casos de uso deste género:
- algoritmos comuns, tais como ordenação ou tratamento de datas;
- importação/exportação de/para um formato (Excel, PDF, etc.);
- criação de uma cache;
- autenticação e autorização;
- animações (efeitos gráficos);
- serialização e deserialização de XML ou JSON;
- consumir ou providenciar uma API REST;
- abstrair comunicação de rede;
- leitor de multimédia;
- tarefas cron;
- sistema de templates;
- mediar a transformação entre objetos e tabelas/relações (ORM);
- construir interfaces gráficas (widget toolkit);
- entre muitas outras.
Se só irá tirar partido de uma parte diminuta de uma biblioteca /framework talvez nem devesse usá-la. Será que a linguagem/runtime não traz a maioria daquilo que precisa? Será que precisa apenas de uma microbiblioteca/utilitário e não uma framework gigante?
Na altura de decidir incluir uma biblioteca deve ter em conta:
- o consumo extra de recursos (latência de rede, tempo gasto em compilação, deploy e runtime, custos de memória)
- a criação de mais uma dependência tecnológica;
- o tempo de aprendizagem;
- a inclusão de código desconhecido;
- possíveis incompatibilidades com o restante software.
Ao usar uma framework, para além dos pontos referidos acima, deve considerar também:
- algum risco de tempo/esforço perdido caso a escolha tenha sido mal feita;
- que é mais provável que os programadores deixem de conhecer as verdadeiras API;
- possíveis imposições (i.e. uma framework pode impôr uma forma de trabalhar e tornar difícil não usá-la).
Ou seja, não tem mal adicionar bibliotecas/frameworks ao projeto se estiver ciente do peso das suas desvantagens.
Como começar?
Agora que decidiu usar uma biblioteca ou framework, o que fazer? Está na altura de ir ao Google e fazer um levantamento inicial. Provavelmente existem dezenas para o ajudar no seu objetivo. Vamos por eliminação de hipóteses.
Existem problemas de diferentes níveis de abstração (ex. ordenar uma lista é mais baixo nível que criar uma loja online), pelo que deve adequar o nível da biblioteca ao nível do problema. É então imperativo que conheça muito bem o problema que quer resolver.
Não é altura de decidir, pelo que não entre em análises minuciosas nesta fase; lembre-se que isto é só um levantamento inicial. Considere apenas aquelas ligadas ao seu ambiente de desenvolvimento (Node.js, Java EE, Swift); descarte aquelas que pouco ou nada se ligam ao problema a resolver. Descarte as que fazem muito mais do que irá usar a médio/longo prazo.
O Stack Overflow, a Wikipédia e artigos de opinião e/ou comparativos são bons pontos de partida. Projetos alojados no GitHub têm a enorme vantagem de lhe dar metainformação (ex: estrelas, pull requests, contribuidores, etc.):
É provável que tenha ficado com cerca de 6~10 candidatas nesta fase.
Como filtrar?
Além dos motores de pesquisa, por vezes os repositórios de bibliotecas são excelentes pontos de partida (pois muitos têm boa categorização, muita metainformação e implementam alguma “seleção natural”). Por exemplo:
- para Android, o Android Arsenal;
- para PHP, o Packagist;
- para Java, o Maven Repository;
- para iOS, o CocoaPods;
- para Node.js, o npm registry;
- para Ruby, o RubyGems.
Analise a missão da biblioteca/framework, a sua documentação, os samples/demos, e os seus fóruns/comunidades. Se puder, evite versões “1.0” (e abaixo); é provável que ainda não tenham atingido a maturidade necessária. Analise as licenças de software, eliminando as que não se coadunam com o que pode usar no contexto do seu problema.
Bibliotecas e frameworks de empresas credíveis ou de fundações open source (ex. Google, Facebook, Pivotal, Apache Software Foundation, jQuery Foundation) oferecem mais confiança que as feitas por individuais desconhecidos (mas há exceções).
Após esta análise deverá ter reduzido as candidatas a 2~5. Se ainda estiver confuso ou se a escolha for decisiva no projeto (geralmente é mais em frameworks do que em bibliotecas), recorra a matrizes de decisão (opcionalmente com pesos). Tais matrizes podem ajudar a consolidar/documentar estes estudos e a apresentá-los aos decisores. Têm o seguinte aspeto:
| Peso
[a importância que este critério tem para o projeto/problema] |
biblioteca 1
[calculado com (pontuação 1 a 5) * peso] |
biblioteca 2 | biblioteca 3 | |
| Popularidade | ||||
| Documentação | ||||
| Sustentabilidade | ||||
| Personalização | ||||
| Suporte | ||||
| Peso extra no projeto | ||||
| Velocidade | ||||
| Maturidade | ||||
| Expansibilidade | ||||
| Tempo de aprendizagem | ||||
| Facilidade de integração e uso | ||||
| Boas práticas | ||||
| <outros critérios> | ||||
| Total | 100 | ∑ peso(i) |
Uma forma de aferir a popularidade é utilizando o Google Trends. Por exemplo:
No exemplo da Wikipédia abaixo vemos o comparativo de funcionalidades de web frameworks para Java (as linhas estão trocadas com as colunas, face à tabela anterior):
Como decidir?
Não faça a pergunta: “Qual a melhor biblioteca?” mas sim, “Qual é a melhor biblioteca para este problema?”
Evite usar algo por capricho ou curiosidade. Fuja de argumentos vazios de valor, emocionais ou subjetivos:
- «Já usei e adorei»
- «O Facebook usa e é espetacular»
- «É o que está a dar; toda a gente está a usar!»
Foque-se apenas nos argumentos técnicos e factuais:
- Qual é o grau de correspondência entre a biblioteca e o problema a resolver?
- Qual a qualidade/quantidade de documentação?
- Quão frequentes são as versões (e qual foi a última)?
Está na altura de fazer provas de conceito (PoC, protótipo ou piloto). Foque-se em implementar 1 ou 2 funcionalidades fulcrais “de cima a baixo”. Para tal, pense em operações decisivas no seu problema/projeto. Por exemplo: “é imperativo ter uma tabela de utilizadores com ordenação, filtros e edição inline”. Quais são aquelas funcionalidades que não podem faltar e sem as quais o produto irá falhar? São essas que quer pôr à prova nas bibliotecas/frameworks pré-selecionadas.
O esforço envolvido numa decisão deve ser diretamente proporcional à sua importância. Para pequenas bibliotecas, gaste menos tempo. Para frameworks decisivas, gaste mais tempo. Por outro lado, não precisa de aplicar todos os métodos mencionados. Às vezes basta uma boa leitura do GitHub para sentir confiança numa pré-filtragem ou até decisão.
Seja “advogado do diabo”: em vez de tentar mostrar porque é que a biblioteca/framework deve ser usada, tente mostrar porque é que não deve ser usada. Se não conseguir, é um bom indicador.
Cuidado para não entrar em detalhes; o objetivo dos PoC é considerar ou descartar algo caso não cumpra um objetivo que considere basilar. Cada PoC pode ser feito paralelamente (por diferentes programadores). Deve submetê-lo como branches no seu repositório de versionamento.
Caso o problema a resolver seja fulcral para o projeto, aposte também em testes comparativos de performance. Por exemplo, se estiver a avaliar uma biblioteca para parsing de JSON, faça uma bateria de testes exaustiva que permita avaliar cada uma em condições extremas e excecionais (ex. ficheiros pesados, nós grandes, etc.). Para complementar a análise e ajudá-lo na decisão, faça pesquisas do tipo “A vs B” (ex: “volley vs robospice”, “imageloader vs glide”) e valorize opiniões de quem já usou as ferramentas.
Eleja um PoC como vencedor. O código do PoC eleito pode ser aproveitado para o projeto.
Conclusão
Antes de decidir usar uma biblioteca/framework, questione se realmente precisa, porque o seu uso não traz só vantagens. Faça uma rápida análise custo/benefício: serão as desvantagens superiores aos benefícios?
No processo de escolha deverá inspirar-se no método científico (em departamentos que deviam ser de R&D, muitas vezes esquece-se o valor do “R”):
- O investimento de alguns dias nestas experiências pode ser muito compensador, pois a escolha errada pode trazer um impacto muito maior para o projeto.
- Não encare como “tempo perdido” se uma experiência/PoC não foi um sucesso; algo ter falhado também é conhecimento valioso.
- Ao argumentar, tente que os argumentos “em cima da mesa” sejam factuais (refutáveis).
- O facto de a ferramenta X ter resultado bem no projeto Y não é um argumento forte (salvo se os projetos forem muito semelhantes).
- Seja humilde e assuma que fez uma má escolha, se for caso disso. Quanto mais cedo o fizer, melhor. Tenha escolhido bem ou mal, há lições a tirar e experiências a reter.
- Se tiver de voltar a fazer o mesmo tipo de escolha, volte a colocar tudo em causa, repetindo o processo de escolha; nascem e morrem bibliotecas/frameworks esporadicamente e o próprio paradigma do problema é evolutivo.
Por fim, lembre-se que não há bibliotecas que resolvam tudo nem bibliotecas que não resolvam nada. Cada problema exige uma escolha cuidada e personalizada de uma ou mais bibliotecas.