Aqueles que entraram no site da Workana nestes últimos dias notaram as grandes mudanças realizadas no design e interface do usuário. São resultados de seis longos meses de desenvolvimento.
No começo de 2016, a nossa velha e querida interface, com suas larguras fixas, um Javascript imperativo, um CSS no super antigo Boostrap 2 e uma série de layouts duplicados para mobile, já tinha cumprido há muito tempo o seu ciclo tecnológico.
E mesmo que continuássemos sobrevivendo às mudanças ocorridas na indústria, era evidente que estávamos limitados tecnologicamente, já que um produto como a Workana necessita um processo de iteração rápida. Para a sua startup não ficar para trás, te recomendamos esta incrível ferramenta para criar o seu próprio site 😉
Requisitos para uma nova Frontend
Na Workana não acreditamos em grandes mudanças disruptivas e preferimos um processo de iteração rápida. No entanto, uma nova interface e com um toolchain moderno, ainda dava margem para uma dívida tecnológica, difícil de superar com um desenvolvimento incremental.
Entrar pelo caminho de uma grande mudança incluía um risco enorme para um produto que está em constante mudança. Por isso, foi fundamental, à medida que se exploravam protótipos, definir e redefinir o alcance da difícil tarefa de escrever um novo frontend:
Dispositivos móveis em primeiro lugar! Um site, cuja principal missão é facilitar as novas formas de trabalho para milhões de pessoas, devia ter entre os seus principais objetivos ser completamente funcional (e agradável) para todo tipo de dispositivo. Veja aqui como criar o seu App!
Manter toda a funcionalidade pré-existente. A Workana tem dezenas de páginas e seções que diariamente entregam ferramentas de trabalho para centenas de freelancers e clientes. Esta ampla funcionalidade é resultado de um processo paulatino de desenvolvimento e melhora constante através do A/B testing. O nosso futuro novo frontend deveria manter toda esta funcionalidade já testada e, devido ao scope e ao acompanhamento das nossas métricas, também não podia ser estendido. No entanto, era absolutamente necessário reintegrar de forma contínua todas as melhorias que acontecesse no nosso campo principal do código durante o desenvolvimento.
Unificar e conciliar todos os nossos componentes gráficos. Ao longo dos anos, o nosso velho frontend sofreu múltiplos acréscimos nos componentes gráficos, que por diversos motivos foram deformando a normativa da interface, que por si só já era pouca definida. Era hora de unificar e reorganizar esse caos por completo: ícones, badges, labels, flash messages, elementos de formulário, paletas de cores, dezenas de fontes, boxes e um extenso etecetera deveria ser convertido em um toolkit com componentes lógicos, reutilizável e acima de tudo uniforme.
SEO: Conservar as nossas métricas de posicionamento. Este objetivo teve grandes implicações nas decisões tecnológicas do desenvolvimento, a compatibilidade no rooting das URLs, o HTML do servidor e outras questões que afetam o posicionamento e que limitam o uso dos frameworks SPA. A nossa equipe de Growth não ficaria contente o suficiente se o robot da Google começasse a mostrar de um dia para outro um único DIV vazio ao estilo React: <div id=”reactInit”></div>. Correto?
Performance, corre frontend corre! Ainda que velho, o nosso antigo frontend funcionava rápido e fluente: durante anos sofreu vários micro e macro otimizações. Então, o novo frontend não poderia diminuir, em nenhuma circunstância, a velocidade do produto. A performance foi um requisito horizontal durante todo o desenvolvimento.
O que tínhamos?
Seis meses atrás, o nosso campo principal no repositório da Workana tinha 923.116 linhas de código, das quais em torno de 300.000 mil eram formatações HTML, Javascripts, CSSs e outros assets dedicados ao front.
O sistema de geração de assets comprimidos (nosso build de JS e CSS) não entendia o node_modules nem o jsons, declarando versões e dependências. No grande array do php as relações entre os nossos Controller::actions e os assets eram definidas para servir a uma página específica. As fontes desses assets, mesmo que fossem de bibliotecas de terceiros ou códigos de aplicação, estavam versionados diretamente ao nosso repositório.
Cada página tinha o seu próprio bundle de assets JS/CSS e gerava um arquivo. Muitas das nossas bibliotecas acabavam sendo duplicadas em centenas de bundles gerados por cada página, para a tristeza dos sofisticados cachês dos browsers de hoje em dia.
Em geral, o Javascript era executado dentro do document load, e enriquecia o comportamento dinâmico do site, com uma lógica, fortemente imperativa. O Chat estava codificado no Angular 1 e lodash, agregando duas dependências enormes que não eram utilizadas no resto dos componentes.
O nosso layout principal era completamente estático, por isso várias páginas eram duplicadas para que pudessem servir aos dispositivos móveis de maneira especial. Esta duplicação era propensa a erros e acima de tudo, a origem das inconsistências visuais no produto. Nós estávamos longe de entregar uma experiência móvel estável pelo nosso site. Estamos te deixando meio tonto com este vocabulário técnico? Então, pergunte aos melhores programadores freelance como criar o seu site
Definição do plano e sua execução
Pedir a um desenvolvedor que entregue uma estimativa da quantidade de horas que um projeto pode demorar, do qual seu scope está limitado às interpretações criativas de um conceito como: o novo frontend sobre um codebase com aproximadamente um milhão de linhas, é o mesmo que dizer para que exercite as suas habilidades na ficção literária.
Todos nós já sabemos que o começo de muitos projetos de desenvolvimento é repetitivo e torpe. Por diversas razões, mas no final das contas, o verdadeiro plano surgirá logo depois que você desenhar um scope experimental com objetivos e uma exploração que inclua a codificação de possíveis protótipos com as diferentes opções.
Esta manipulação física do código, de acordo com a nossa experiência, é praticamente a única maneira de dimensionar projetos com estas características. O novo frontend da Workana não foi a exceção. Apenas no começo com a codificação dos protótipos, conseguimos definir os objetivos e projetar o plano a ser executado:
Novo toolkit gráfico. Foi produzido um toolkit gráfico com componentes HTML/CSS estabelecido no Bootstrap 3, que definiu e padronizou os diferentes componentes usados no nosso site. O toolkit começou como uma representação estática dos nossos principais elementos de design, e foi crescendo à medida que avançávamos no desenvolvimento. A codificação dos componentes reutilizáveis permitiu que a equipe do DEV ajudasse a diagramar as páginas. Com o novo feedback da tarefa poderíamos iterar as ideias centrais e consolidar a galeria de componentes.
Migração página a página. Com o toolkit definido já poderíamos começar a diagramação página a página. E começamos pelo mais fácil: o login! Fazer a migração significava substituir as velhas classes do Bootstrap 2 a 3, incorporar os nossos novos componentes, utilizar o sistema de grades responsivas e migrar o Javascript para o Vue.js.
Novo build de assets. O sistema do build foi baseado inicialmente no gulp e o elixir do Laravel que tratavam, entre outras coisas, do uso do Webpack 1. O Laravel e os seus bons defaults nos permitiram configurar rapidamente um ambiente de desenvolvimento moderno com transpiler do ES2015, live reload, otimizado com imagens e outras conveniências. Chegando perto, as nossas exigências do deploy começaram a crescer em busca de maior desempenho e otimização. A exigência de uma flexibilidade maior nos obrigou a desconsiderar o uso do Laravel e Gulp para migrar diretamente ao recém lançado Webpack 2. Hoje, nós contamos com ferramentas como o versionado do hash de imagens, sons, url inliner no CSS/LESS, code spliting, minificar, compreensão e toda a parafernalha que um toolchain moderno de frontend nos acostumou.
Vue.js entre a modernidade e o simples
A grande quantidade de frameworks Javascript e as suas versões (lançadas e rejeitadas) colabora com o grande estresse gerado à companhia na hora de escolher uma tecnologia chave para acompanhar durante vários anos o seu produto. Gostaríamos de relembrar algumas reflexões, do porquê o Vue.js provou ser a melhor opção, para refletir um pouco sobre o que nós tínhamos e o que queríamos alcançar.
- Curva de aprendizagem simples.Muito tem sido dito sobre o Javascript Fatigue. Um dos ecossistemas mais dinâmicos de uma indústria já conhecida como inovadora, ele produz constantemente novos setups, paradigmas e tecnologias com elevadas curvas de aprendizagem. A tarefa de migração da Workana era muito grande para fazer exclusivamente com a equipe do frontend, por isso foi fundamental para nós que outros DEVS do core puderam colaborar com esta tarefa. O Vue.js é de longe um dos frameworks modernos mais fácil de entender, devido aos seus bons defaults e consistência.
- Suporte da indústria.Na hora de decidir sobre a migração, o Vue.js já tinha sido adotado como o framework Javascript oficial do Laravel ganhando mais tração. Além disso, o seu principal mantenedor permitia financiamento para se dedicar 100% ao seu desenvolvimento. Com uma documentação de primeiro nível e uma comunidade em crescimento, ele provou estar pronto para a produção.
- Fácil de integrar com o legacy libraries.Estava fora do nosso alcance reescrever bibliotecas completas que já estavam funcionando corretamente. O ciclo de vida dos componentes do Vue.js é claro e fácil de entender. Usando o ready dos componentes ou carregando callbacks no $nextTick poderíamos integrá-los facilmente com as bibliotecas e plugines jQuery que manipulavam o DOM por conta própria, nas diferentes etapas do life cycle dos nossos novos componentes.
- Templates inline e o SEO. Vue.js permite escrever o template dos componentes diretamente no html do documento, apenas especificando o atributo do inline-template:<MyComponent inline-template />. Este approach estava perfeito para a Workana, porque nos permitiu seguir com as nossas formatações geradas no PHP e continuar, de maneira fácil, indexáveis nos buscadores.
- Rápido e moderno.js está entre os frameworks mais rápidos e leves do Javascript. Implementa eficientemente as formatações declarativas e reativas do Core, com técnicas modernas como o pre render no virtual dom.
Para onde vamos
Não é possível finalizar um projeto enquanto um produto ainda está vivo, mas é importante para qualquer equipe reconhecer as suas metas significativas, com o objetivo de adquirir perspectiva, valorizar o trabalho realizado e reconhecer os próprios erros. Em definitiva, isso servirá para identificar melhor quais são os desafios tecnológicos que a nossa equipe terá pela frente.
Nós acreditamos que o lançamento da nova interface finca bases sólidas e modernas para um novo começo do nosso ciclo de iteração. E que com isso, virão pequenas e grandes novas funcionalidades, carregar mais rápido, uma melhor experiência nos aparelhos móveis e um site mais fácil de usar para todos os nossos clientes e freelancers. Para todos aqueles que usam diariamente a Workana como uma nova forma de trabalhar que está constantemente mudando, e que esperam do nosso produto o mesmo dinamismo e capacidade de adaptação.
Emilio Astarita é frontend developer e trabalha na Workana na área de Desenvolvimento.
É a sua vez de criar ou renovar o seu site!
Contratando os profissionais freelance e seguindo as boas práticas será fácil, rápido, efetivo e de grande qualidade. Vamos te contar como fazer! ?
Conheça os melhores profissionais para criar o seu site:
– Diagramadores no topo do ranking
Se você é um profissional independente, veja as ferramentas criadas exclusivamente para ti no VidaFree.la, como por exemplo, a Calculadora Freela, que te ajudará saber quanto cobrar como freelancer, ou ver em tempo real quanto os freelas da América Latina cobram por hora.
Para começar a trabalhar de forma independente, dê uma olhada nos projetos publicados na Workana e envie a sua proposta. Ou você também pode empreender: crie um projeto na Workana e contrate freelancers que te ajudarão a desenvolvê-lo.
