Métricas para o uso de bibliotecas de terceiros
O desenvolvimento de software nos dias de hoje, como muitas outras áreas, está cada vez mais padronizado. Com isso se tem menor número de códigos escritos e maior número de bibliotecas de terceiros. Quando digo biblioteca, me refiro a códigos em geral (frameworks, libs, classes).
Esse fato é visto por uns como ponto positivo, mas por outros como negativo.
Mas o caso é não podemos ter essa visão única para o caso geral de todos os códigos adicionais de terceiro, pois existem várias situações que podem mudar o cenário.
Antes de tomar uma iniciativa de importar uma lib devemos avaliar idéias de outras pessoas em relação à ela. Para isso basta entrar em alguns fóruns ou fazer uma busca rápida na Internet. Nesses sites podem-se encontrar muitos prós e contras para a lib e, baseado nelas, é possÃvel descartá-la. Lembrando que à s vezes o que é considerável contra por alguém, pode ser uma coisa simples para outra pessoa. Portanto vale uma leitura mais crÃtica, analisando a viabilidade no projeto e na situação em que está. Outra coisa que vale destacar é o nÃvel de seriedade do site em que se encontraram as opniões, pois é o mesmo que ler uma notÃcia em um site especializado, ou um blog crÃtico que te direciona para outras visões da mesma notÃcia, ou em um blog que distorce as informações focando ideologias próprias.
Nessa pesquisa é bom ver como é a licença para uso nos projetos comerciais, se o projeto é ativo com muitas atualizações de versões ou se as atualizações de versão são apenas para correção de bug, se ela é livre para modificação, etc.
Passando a etapa de pesquisas, passamos para a parte prática, onde deve-se fazer uma comparação de desempenho de funcionalidades com e sem ela, além de ver se a lib te proporciona a escalabilidade necessária para o que seu sistema precisa.
Ainda temos que ver quais as limitações práticas que ela terá e o quanto é custoso para contorná-la com a forma convencional ou utilizando outra lib. Por último, temos que ver qual é a curva de aprendizado para usá-la e pensar que no projeto podem ter muitas pessoas trabalhando com o mesmo código (mesmo que seja um projeto pessoal, sempre temos que pensar dessa forma para garantir um bom código). Então, pensar na manutenção do código futuramente.
Essa é mais uma daquelas análises que variam de projeto para projeto e o nÃvel que essa estatÃstica precisa alcançar varia da mesma maneira. Mas com uma boa análise diminui-se a probabilidade de um erro, consequentemente melhorando diretamente na produtividade do desenvolvimento.
Fonte: Imasters
