React Developer: as competências essenciais e o futuro da função

Fotografia de Marina Pinho
Escrito por

Marina Pinho

Communication Manager

Frontend, frontend… a arte de criar websites não só funcionais, mas também apelativos e intuitivos. Mas afinal, o que faz realmente um Frontend Developer? Quais são os seus maiores desafios? E como é que alguém pode seguir esse caminho?

Nesta entrevista, falamos com o Maicol, Frontend Developer na Dellent, apaixonado por tecnologia e por tudo o que envolve transformar ideias em interfaces funcionais. Ao longo da conversa, partilha connosco o seu percurso profissional, as experiências que o levaram a especializar-se em React, o que mais o entusiasma no desenvolvimento frontend e como vê a evolução da área com o avanço da Inteligência Artificial. Uma conversa descontraída, mas cheia de dicas sobre código, design e o futuro do desenvolvimento web.

Conta-nos um pouco sobre o teu percurso profissional. Como começaste na área do desenvolvimento frontend?

Comecei há quase 13 anos. Tudo começou quando trabalhava numa gráfica e queria ser designer nessa mesma empresa. Fiz a licenciatura em Design Gráfico e foi aí que tive o meu primeiro contacto com HTML e CSS.

A partir daí, fiquei dividido entre seguir o caminho do design gráfico ou do desenvolvimento frontend. Comecei por trabalhar como designer, mas ia sempre codificando algumas coisas. A transição para frontend aconteceu de forma natural, quando dei por mim, já passava mais tempo a programar do que a criar layouts ou peças de design.

Quando é que descobriste que React seria o teu foco? Porquê essa escolha?

O Angular.js surgiu quando eu já trabalhava com Frontend e Wordpress, e veio resolver muitos problemas que tínhamos, especialmente para quem criava funcionalidades que abriam apenas em pop-ups no site. Quando apareceu eu abracei o Angular, virei um fanático pelo framework, até que surgiram o Vue.js e o React. Comecei a trabalhar com os três durante algum tempo, mas percebi que a comunidade estava a adotar cada vez mais o React e percebi que tinha de me focar apenas num para me tornar um especialista. Acabei por escolher o React e não me arrependo até hoje. 

A comunidade acabou por preferir o React porque o Angular teve bastantes dificuldades no início. Quando lançaram o Angular 2, quem já programava com a versão anterior teve praticamente de reaprender tudo, porque o framework era completamente diferente. O React não passou por isso: foi evoluindo de forma natural, sem obrigar os programadores a reaprenderem tudo a cada nova versão. Além disso, a forma de escrita do React é mais declarativa, mais direta, não é preciso “enfeitar” tanto o código para as coisas acontecerem. Essa simplicidade fez com que se tornasse o favorito de muita gente.

Hoje existem outras ferramentas muito boas, como o Vue.js, que considero uma mistura interessante entre o Angular e o React. Também gosto do Svelte, que tem crescido bastante. Ainda assim, para mim o React continua a ser o melhor até porque oferece muitas possibilidades. O que aprendes com o React para web pode ser aplicado no desenvolvimento de aplicações móveis com o React Native. A abordagem e o conceito são os mesmos, há apenas pequenas diferenças. A comunidade valorizou muito isso também.

Que tipo de projetos fizeste antes de chegares ao ponto onde estás hoje?

Já fiz bastantes coisas. Desde simples landing pages e sites institucionais até sistemas de backoffice complexos, com relatórios gráficos detalhados e grandes filtros de dados. Um dos projetos mais interessantes foi um sistema de desktop feito em React para uma rede de lojas de estética e cosmética no Brasil.

Esse sistema permitia gerir agendamentos, produtos e até fazer pedidos diretamente à franqueadora. A empresa chamava-se Sobrancelhas Design, tinha várias franquias e precisava de uma solução centralizada para gerir tudo. O franqueado podia instalar a aplicação no desktop e, a partir dali, controlar toda a operação: agendamentos, faturação, gestão de stock e pedidos de produtos.

O grupo principal enviava-nos as necessidades de novos módulos, e nós desenvolvíamos e integrávamos tudo nesse sistema. Como era feito em React, acabaram por surgir várias ferramentas derivadas desse projeto, que depois foram aproveitadas internamente e em outras áreas do grupo.  

O que é que mais te entusiasma no desenvolvimento frontend?

O que mais me entusiasma hoje em dia é ver o que estou a fazer. Acho que, quando crio alguma coisa e consigo ver o resultado, mesmo que pareça impossível e que passe dias ou horas a tentar, é isso que mais me deixa feliz.

Nem é tanto o momento da entrega, às vezes é o próprio projeto. Neste momento estamos a trabalhar num projeto bastante desafiante e já fiz quatro ou cinco POCs (provas de conceito) para testar a viabilidade de tudo, e já quero entregá-lo exatamente assim.

Preferes trabalhar na lógica, no design ou na ligação entre ambos?

Na ligação entre ambos, porque só com o design ou só com a lógica não se tem um produto final. Fica apenas uma funcionalidade ou um conceito. Quando juntamos os dois, aí sim temos um produto completo.

Acho que todos têm a sua importância, mas o que realmente gosto é de pegar no layout, codificá-lo, aplicar a lógica e ver tudo a funcionar… e rezar para que não haja bugs [risos].

Há algum projeto ou funcionalidade que tenhas desenvolvido e que te tenha dado especial orgulho?

Sim, há um projeto de 2019 de que me vou sempre lembrar. Era uma aplicação em React Native, criada para alunos entre os 8 e os 12 anos. Era um jogo, muito parecido com o Duolingo, em que o utilizador passava de nível. Entrava, por exemplo, na área de Matemática, respondia a 10 perguntas e ganhava poderes, podia comprar perguntas secretas…havia imensos recursos.

Para mim, foi um dos melhores projetos em que trabalhei. Tivemos um prazo muito apertado para lançar a primeira versão, porque o ano letivo não parava e o lançamento tinha de acontecer. De repente, começámos a receber feedback de quase todos os alunos, e nos analytics víamos pessoas a jogar durante quase 20 horas. A taxa de acesso era altíssima.  Para mim foi um dos melhores projetos até hoje.  

Em que tipo de projeto estás atualmente a trabalhar? É um produto, plataforma ou aplicação interna?

Atualmente trabalho num produto voltado para que o próprio cliente consiga gerir as informações que adiciona no seu site. Gerencio um CMS que desenvolvemos e, além disso, estamos a criar um estúdio associado a esse sistema.

A ideia é que, em vez de o utilizador ter de aceder ao CMS e preencher vários formulários para publicar um artigo, por exemplo, possa fazê-lo diretamente no site final, com drag and drop, edição de imagens e visualização imediata das alterações.

É um sistema que funciona antes do site e alimenta todas as suas informações. Tem um dashboard, um backoffice, onde é possível gerir artigos, parceiros, categorias e tags, tudo o que depois é refletido no website.

Pessoa a programar num portátil com código visível no ecrã, num ambiente de escritório com monitor externo, caneca e planta decorativa.

Qual é o setor do cliente? E qual o papel da tua equipa dentro desse contexto?

O setor é o das telecomunicações, e o papel da minha equipa é justamente garantir a ligação entre os editores e o site final. Criamos todas as ferramentas de que o editor precisa para que tudo funcione, para que tu, como utilizador, consigas aceder ao site, ler artigos, ver notícias e receber recomendações através do algoritmo.

Hoje, desenvolvemos não só o CMS, mas também outras ferramentas de uso interno que dão suporte a todo esse processo e tornam possível que o conteúdo chegue ao utilizador de forma fluida.

Como está estruturado o teu dia a dia?

Na nossa equipa não temos daily, o que achei estranho no início, mas a comunicação entre todos é tão boa que realmente não faz falta. Estamos sempre a atualizar-nos pelo chat do Slack.

Trabalhamos com tickets que são abertos para nós, mas não seguimos exatamente o modelo Scrum. No novo produto que estamos a desenvolver, por exemplo, ainda estamos na fase de descoberta, por isso, os tickets que temos abertos são mais focados nessa etapa. Quando a equipa de produto definir o conceito final, aí sim devemos passar para algo mais próximo de um kanban, para termos um melhor direcionamento.

Temos uma rotina de tasks já definida, mas pode sempre surgir algo mais urgente. Não seguimos uma lógica de sprint,  é um processo mais contínuo, quase em modo cascata: as tarefas vão chegando e nós vamos executando.

Que stack estão a utilizar?

Nestes projetos estamos a utilizar React com Next.js. No CMS usámos uma ferramenta chamada Payload CMS. Também utilizamos Redis para caches internos, onde precisamos manipular algumas informações, e RabbitMQ para a parte de mensageria. Por exemplo, quando alguém edita algo, é disparada uma mensagem para quem estiver a ouvir e poder atualizar também.

Usamos ainda Svelte, que é um “concorrente” do React. Já trabalhámos também com Solr, que serve como uma espécie de cache, mas depois mudamos para o Varnish, que faz o cache diretamente. Assim, em vez de o frontend consumir o CMS de forma direta, passa primeiro pelo Varnish, que gera o cache e evita chamadas desnecessárias ao CMS. Acho que isso resume bem a maior parte da nossa stack.

Trabalhas lado a lado com designers e backend? Como é feita essa colaboração?

Temos uma equipa de design, embora não trabalhem diretamente connosco no dia a dia. Eles abrem muitas issues relacionadas com usabilidade, principalmente no CMS, e colaboram mais de perto com a equipa de frontend. O nosso trabalho também passa por eles quando há alguma alteração ou melhoria a implementar, mas não é uma colaboração tão próxima neste projeto.

Os designers são responsáveis por criar o layout do site final, que depois o frontend consome e codifica. Já nós, que trabalhamos mais com JavaScript, acabamos por ter um papel bastante próximo do fullstack: criamos muitas aplicações, gerimos as nossas próprias bases de dados e tratamos da manipulação dessas informações para que o frontend possa consumir diretamente e o produto funcione corretamente.

No geral, é uma equipa bastante grande. Funciona mais ou menos assim: começa com o editor, depois entra a equipa de requisitos, seguida pela equipa de design que também faz um pouco de frontend, com HTML e CSS, depois vem a nossa equipa, focada em JavaScript, e a equipa de frontend que trabalha com Golang. Existe ainda uma equipa responsável pela importação de conteúdos, já que muitos artigos vêm de parceiros externos e precisam de ser tratados antes de voltarem ao CMS para que o frontend os possa consumir. E, claro, há também as equipas de segurança. Enfim, é bastante gente [risos]. 

De que forma é que achas que o teu trabalho está a contribuir para o desenvolvimento do projeto do cliente?

Acredito que o meu impacto hoje está em conseguir entregar ao editor, de forma simples, tudo o que ele precisa para publicar um artigo no novo site. Acho que isso, por si só, já representa um grande contributo. Além disso, tenho procurado criar soluções mais práticas e eficientes.

Implementamos várias ideias, principalmente relacionadas com IA e como trabalhamos com artigos, ela encaixa-se muito bem nesse contexto para sugestões de tags, melhorias no texto e até extensões de browser para apoiar o trabalho do editor.

Mapeamos essas ideias e, pessoalmente, adoro desenvolver pequenos projetos e POCs (provas de conceito) para validar se realmente fazem sentido. Aliás, o novo produto acabou por nascer exatamente desse tipo de experimentação.

Que competências achas essenciais para quem quer seguir esta função?

Mudou muito, mas hoje acredito que quem trabalha com frontend não pode ser preguiçoso. Mesmo quando o trabalho é cansativo e exaustivo, ter de criar inúmeras funcionalidades que às vezes fazem praticamente o mesmo, ou lidar com pequenos bugs que não chegam a quebrar nada mas que  é importante não ignorar. O frontend tem de estar sempre atento e procurar corrigir, mesmo o que parece insignificante.

Outra coisa essencial é procurar sempre feedback. Isso motiva muito, principalmente quem está a começar. Mesmo que o retorno seja algo como “podemos melhorar o layout” ou “poderíamos tornar a usabilidade mais intuitiva”, é esse tipo de comentário que ajuda a crescer.

Por isso, diria que o fundamental é: não ter preguiça, ir atrás dos pequenos detalhes, manter-se atualizado, porque o frontend muda constantemente, e saber lidar com feedback, usando-o para melhorar.

Além disso, ter sensibilidade para o design é muito importante. Entender conceitos como grids, espaçamentos e composição ajuda bastante na hora de codificar, porque passas a construir com base em princípios sólidos. Ah, e o inglês também é essencial, é onde encontras muito conteúdo de criadores e referências mais avançadas na área.

Programador concentrado a escrever código num portátil, com monitor externo ao lado e espaço de trabalho organizado e moderno

Que conselhos darias a quem está a aprender React agora?

Diria que, assim que aprenderes React, deverias tentar aprender também React Native,  porque, na minha opinião, já terás aí cerca de 80% do caminho feito. O ideal é focar nessas duas tecnologias e aprender também a publicar aplicações, porque esse conhecimento permite-te desenvolver muitos projetos praticamente sozinho.

E, claro, não te limites apenas a isso: o foco deve ser sempre o JavaScript. O React é apenas uma ferramenta que o utiliza, por isso é importante aprender os dois em conjunto.

Achas que a função de frontend developer vai mudar com a evolução da IA?

Acho que já mudou. Ainda escrevemos muito código, mas acredito que quem está a começar, os perfis mais júniores, pode acabar por ter algum receio ou usar IA para tudo, sem questionar ou tentar perceber o código.

Eu próprio uso bastante IA. Na verdade, sempre tivemos o hábito de recorrer à web ou ao Stack Overflow para procurar soluções e perceber porque é que algo não funcionava,  hoje faço isso com a IA. Uso-a como ferramenta de pesquisa ou para me ajudar quando estou concentrado numa lógica e preciso de criar funções que já sei fazer, mas quero poupar tempo. Peço à IA, confiro o resultado e valido se está tudo certo.

Acredito que, no futuro, talvez ainda não num futuro próximo, possamos chegar ao ponto de apenas descrever o que queremos e ver o código a ser criado automaticamente. Mas, se fizermos isso hoje, o resultado seria um projeto todo quebrado, ainda não estamos nesse nível de fiabilidade.