nome

Hype ou maturidade: percursos sobre a escolha de uma nova tecnologia para seus projetos web

Publicado em 12 de dezembro de 2018
Autor: Mateus Ávila Isidoro

Desafio o leitor a encontrar alguma área no mercado que tenha uma transformação tão rápida e intensa quanto as necessidades de atualização dos front-ends. Acho que o leitor desta postagem deve estar-se perguntando se alguma outra profissão tem que lidar com necessidades de aprimoramento e reaprendizagem a uma base tão descartável quanto um copo plástico.

O mundo da tecnologia evolui, de certa forma, regidos pela lei de Moore. De acordo com a lei de Moore, o número de transistores dos chips teria um aumento de 100%, pelo mesmo custo, a cada período de 18 meses. Em 18 meses, o chip que utilizaríamos estaria obsoleto, apesar de fazer inúmeros cálculos matemáticos por décimos de segundos.

No mundo front-end, temos quase uma timeline parecida, se consideramos as tecnologias que vem ganhando forma de um jeito intenso. Para facilitar o entendimento da linha do texto, vou listar abaixo uma pequena timeline dos últimos 12 anos, considerando o tempo que estou desenvolvendo profissionalmente, pela quantidade de frameworks que trabalhei e alguns que surgiram e mudaram a coisa toda:

  • jQuery, de agosto de 2006 – revivendo a linguagem javascript a níveis nunca imaginados.
  • SASS – início da era das folhas de estilo dinâmica, na mesma época que o Ruby começou a expandir-se a partir do Rails
  • Node.js, de maio de 2009 – Javascript no servidor a partir do motor V8, e o início do surgimento do termo fullstack
  • Sencha Touch, julho de 2010 – temos o início da corrida do mobile
  • AngularJS, de outubro de 2010 – o início dos frameworks de JS. A curva de aprendizado na época era um meme
  • jQuery Mobile, de outubro de 2010 – resposta da equipe do jQuery ao Sencha Touch.
  • Stylus, em março de 201
  • Bootstrap, de agosto de 2011 – praticamente virou requisito das empresas contratarem profissionais que sabem mexer com Boostrap
  • Media Queries, possibilitando layouts responsivos, teve especificação em junho de 2012 – os browsers deram suporte antes da especificação, mas teve antes uma corrida por desenvolvedores que soubessem fazer layouts responsivos.
  • Bower, em 2012, para gerir dependências de projetos no front-en
  • React, de maio de 2013 – o início da era dos componentes e da reusabilidade de código ganha novos horizontes.
  • Ionic, em 2013, surge como um port de AngularJS para dispositivos móveis (feito em cima do Apache Cordova)
  • NPM, em resposta ao Bower, cria o repositório de JS mais utilizado do mercado atualmente
  • Vue.JS, de fevereiro de 2014
  • Material Design, junho de 2014 – o Google entra em peso definido seus padrões para um design mobile.
  • Graph QL, uma resposta ao modelo de requisições que era definido como padrão via RES
  • Angular 2, de setembro de 2016 – mudando toda a sintaxe do AngularJs, focado no mundo corporativo.
  • Yarn, em outubro de 2016, um concorrente do NPM que oferece melhor gestão de dependências.

A listagem é grande, e certamente faltou muita coisa – e muita coisa da lista nem cheguei a olhar ou testar. O que ocorre é que basicamente impossível dominar todas as tecnologias sem usar o bom e velho stack overflow.

Considere que cada situação onde o desenvolvedor está inserido define o caminho que ele irá escolher. Antes de prosseguirmos, vou passar um feedback da minha situação de trabalho atual: sou desenvolvedor solo da Café das 4, tenho controle total da stack que vamos utilizar em qualquer projeto. Logo, seria o ambiente perfeito para testar todas as tecnologias em modo bleeding edge. Porém, mantenho-me razoavelmente conservador no timing de início de mudança de paradigma. Eu sigo a regra do 1 ano.

Regra do 1 ano

Estabeleci pra mim a regra do 1 ano para migrar de tecnologia. Isto ocorre pois imagino que uma tecnologia estará com bastante material para consulta além da programação, e muitos desenvolvedores que se antecipam colocam seus problemas no stack overflow. Esta base é importante para mim, que sempre procuro em diversos locais soluções para meus problemas.

Em 1 ano, vemos se a tecnologia ganhou muitos adeptos, se as correções mais importantes após os lançamentos foram realizadas, e como os mantenedores do software lidam com as issues do github. Ou se a tecnologia não vingou ou foi um fiasco retumbante. Aqui devo comentar o caso do rucksack.

Rucksack – não correspondeu ao hype

Eu cometi um pecado no meu preceito da regra do 1 ano: resolvi experimentar o rucksack na época do lançamento, pois não estava curtindo o LESS e queria mudar. No início, ele estava cumprindo o que prometia, com facilidade de criar CSS. entretanto, para gerar um background de imagem, não rolava, pois o compilador quebrava. A frustração foi tão grande que migrei o projeto de teste para o Stylus.

Pode parecer que não persisti o suficiente, mas vi que as issues não estavam sendo respondidas e tinha pouca adesão de desenvolvedores – tanto que eu resolvi testar por que um amigo indiciou, e ele acabou não usando mais também.

Se eu seguisse a regra do 1 ano, estaria seguro da minha decisão.

Maturidade da tecnologia é o caminho final?

O que funciona comigo, que sou conservador na implementação de novas tecnologias, pode ser um inferno na terra para outro desenvolvedor mais arrojado. Não há uma ciência exata que determine quais escolhas um desenvolvedor precisa seguir, mas há questões que precisam estar na mesa para a tomada de decisão.

Imaginamos a seguinte situação hipotética: uma empresa tem 10 desenvolvedores, todos fullstack, com um background em react. Se traçarmos uma média de tempo de experiência na tecnologia, o desenvolvedor mais especialista tem 3 anos de experiência, e o mais iniciante 1 ano. A equipe sentiu que precisava inovar. Foram colocadas na mesa de discussão os seguintes dados:

  • O cliente acredita que inovação não é só no discurso, e sim afetar todas as estruturas de sua empresa.
  • Há paciência do cliente para as primeiras entregas.
  • A versão inicial desta tecnologia possui uma excelente documentação.
  • Ou o projeto é interno, pra deixar em maturação.

A César o que é de César: muitas informações preciosas sobre estas conclusões obtive com os excelentes desenvolvedores da Taller, que tem um blog riquíssimo para gestão de equipes de desenvolvimento. Um abraço especial para o Lucas Constantino pelos insights.

Nesta situação, acredito que temos o caminho ideal para a que o estudo de uma nova tecnologia seja feito. Para melhorar, se os membros da equipe mandarem issues para os mantenedores, a maturidade da tecnologia chega bem mais rápido.

Caso alguma das questões acima não esteja de acordo, a implementação bleeding edge (ou, se preferir, a nível de lançamento) irá falhar em algum ponto. Logo, percebemos que o discurso de inovação torna-se vazio quando não se cria um ambiente favorável para que ele ocorra.