Um dos aspectos mais interessantes (e empolgantes!) da tecnologia, é que ela está sempre mudando e se renovando. Quem está na área há um certo tempo já sabe da importância de estar sempre estudando e quebrando antigos paradigmas. A tecnologia que é o hype hoje, pode ser o grande fracasso de amanhã.

Veja o exemplo do Java: hoje muita gente faz piada e diz que a linguagem e sua plataformas são horríveis, lentas e verbosas. Entretanto, há alguns anos (e não muitos, viu) você encontrava um programador Java a cada esquina.

Contudo, adotar uma tecnologia nova em um projeto no mundo real é um passo que deve ser medido no maior número possível de ângulos diferentes. Isso porque quando estamos tratando de projetos reais, estamos falando de empregos, empresas, pessoas, processos e dinheiro (às vezes, muito dinheiro).

Apesar de toda a empolgação de ter uma nova tecnologia que pode reduzir pela metade o seu esforço atual, precisamos ser profissionais e avaliar se faz realmente sentido adotá-la em curto, médio e/ou longo prazo dentro do projeto.

Mas como fazer essa análise de maneira adequada? Como saber quais pontos avaliar antes de sair usando a tecnologia? Foi para ajudar neste questionamento que a engenheira Sacha Greif fez uma grande pesquisa que resultou no seu artigo “The 12 Things You Need to Consider When Evaluating Any New JavaScript Library”.

No artigo original ela trabalha dentro do mundo do JavaScript. No entanto, acredito que os pontos levantados são válidos para qualquer tecnologia.

Os 12 pontos apontados pela autora, são:

• Features: este ponto diz respeito às funcionalidades que essa tecnologia vai te proporcionar. Ela vai permitir otimizar o seu workflow ou somente é um outro jeito de fazer a mesma coisa? O que ela realmente agrega ao seu projeto?
• Stability: além das funcionalidades, precisamos estar muito atentos à estabilidade do projeto. Com que frequência sai atualizações? O que são essas atualizações? Existem versões LTS dessa tecnologia? Há casos de sucesso no mercado que a utilizam?
• Performance: este é outro ponto chave que quase não preciso comentar. A tecnologia que você quer usar é performática? Ela realmente aumenta a velocidade da sua aplicação? E da sua equipe?
• Package Ecosystem: este item é mais voltado ao mundo JavaScript, mas ainda assim é bastante válido. Você sabe quais as tecnologias que dão suporte ao que você quer usar? Como são estes tópicos que estamos estudando para as dependências deste projeto? Afinal, de que adianta usar um projeto que possui vulnerabilidades de terceiros? Por osmose você poderá passar estes mesmos problemas para a sua aplicação.
• Community: como é a comunidade desta tecnologia que você quer utilizar? É forte? Há meetups/eventos relacionados? Há grupos regionais/nacionais ou somente grupos estrangeiros? É importante avaliar isso para saber como a tecnologia está engajada dentro do seu meio.
• Learning Curve: dificilmente seu chefe permitirá que você adote uma tecnologia em que a curva de aprendizado é muito longa. Projetos precisam ser entregues com rapidez e um tempo dedicado somente para estudos pode sair muito caro.
• Documentation: tão importante quanto a comunidade é a própria documentação do projeto. É por meio dela que você será capaz de compreender como ela funciona e porque foi implementada daquela maneira.
• Tooling: há um tempo era muito difícil aprender o React e isso se dava ao fato do ferramental necessário para conseguir utilizá-la ser extenso. Era preciso aprender o que era Babel, Webpack, Gulp, ES6, etc. E isso era bastante complicado. Hoje não é mais assim, mas note como isso atrapalhou em parte a adoção da tecnologia. É importante avaliar o que é necessário aprender junto a tecnologia que você deseja utilizar.
• Track Record: este aspecto diz a trajetória da tecnologia. Ela já está consolidada? Como foi sua adoção? Quais os casos de sucesso? E os de fracasso? É importante conhecer a história da tecnologia para ter uma ideia melhor sobre o seu futuro.
• Team: quem está por trás da tecnologia? Há algum movimento ou organização que suporta e regulamenta o desenvolvimento desta tecnologia?
• Compatibility: não há nada que faz menos sentido na programação do que querer usar algo que não é compatível com o que você já tem. Para projetos novos isso não costuma ser um problema, mas para os que já estão na estrada há algum tempo, isso pode ser determinante.
• Momentum: este item reflete exatamente a ideia de ter cuidado com o hype. Não é porque todo mundo está usando e falando, quer dizer que seja o melhor para você. Novamente, o exemplo do Java. Será que faz sentido trocar todo seu backend para Node só porque é o que está bombando? Talvez faça, mas jamais tome esta decisão por impulso, sempre avalie este e os outros onze itens anteriores.

E você? O que achou destes pontos? O que você e sua equipe avaliam na hora de adotar um tecnologia? Compartilhe conosco aí embaixo!

Referências

• https://medium.freecodecamp.org/the-12-things-you-need-to-consider-when-evaluating-any-new-javascript-library-3908c4ed3f49