Programador frontend — tarefas, uma a uma

Transformar um desenho numa interface que funciona

Esta é a tarefa mais exposta de toda a engenharia de software, por uma razão mecânica: a entrada é visual, a saída é texto, o correto verifica-se de imediato a olhar, e os dados de treino são a web pública. As ferramentas que geram um ecrã a partir de uma imagem ou de uma frase chegaram a qualidade utilizável antes das que geram um serviço de backend.

Um ecrã que aparece não é um ecrã que entra em produção. Nada diz sobre se o resultado é mantível, se encaixa num sistema de design existente, ou como se comporta nos estados que ninguém desenhou — vazio, a carregar, erro, meia lista.

Os estados que ninguém desenhou

A geração trabalha a partir do caminho feliz porque é isso que uma maqueta contém. Os outros estados são onde vive a maior parte do código real, e decidir o que cada um deve fazer é um juízo de produto sobre este produto concreto e não um padrão a ir buscar.

É um juízo sobre onde está o trabalho, não uma medição dele. As equipas não contam que parte do seu código frontend é tratamento de casos-limite, pelo que não há número com que confrontar isto, e o equilíbrio varia enormemente entre uma página de marketing e um ecrã de negociação.

Fazer com que sobreviva a aparelhos e redes reais

Aqui as ferramentas medem e sugerem melhor do que as pessoas — os orçamentos de desempenho, as auditorias e a análise de perfil são exatamente o género de verificação mecânica em que o software é bom. O que não conseguem é decidir que compromisso aceitar, porque isso depende de quem são mesmo os teus utilizadores, que é um facto sobre o negócio e não sobre o código.

Nada aqui diz quantas horas isto leva nem se as equipas sequer o fazem — grande parte do trabalho de frontend que é publicado nunca recebe esta atenção, e as ferramentas existirem não significa que tenham sido corridas.

Fazer com que funcione para toda a gente, porque é obrigatório

Os verificadores automáticos apanham uma minoria das falhas reais de acessibilidade e não conseguem julgar se um percurso é utilizável por alguém que não vê. Esta tarefa é também a que está a passar de boa prática a obrigação legal em vários mercados, o que muda quem responde e não o quão difícil ela é.

A direção aqui assenta na forma do requisito e não num resultado medido; o que a resolveria é uma ação de fiscalização que nomeie uma interface concreta e o que nela estava errado. Os requisitos variam consoante o mercado e consoante o produto se dirigir ou não ao consumidor.

Ser dono dos componentes que todos os outros usam

Gerar ser barato torna isto mais sustentador de carga, e não menos: quando qualquer pessoa produz um ecrã em minutos, o que mantém um produto coerente é a camada de restrições, e alguém tem de a segurar. O trabalho é recusar e versionar mais do que criar.

Que isto seja um posto ou uma tarefa acrescentada depende inteiramente da dimensão da equipa, e quantas equipas lhe atribuem alguém de forma deliberada é coisa que ninguém conta.

Construir interfaces para coisas que respondem

Isto é trabalho que não existia antes de as funcionalidades generativas chegarem aos produtos, e não tem padrões assentes — neste momento cada equipa está a inventar como mostrar que uma resposta pode estar errada. Cai no frontend porque é uma pergunta sobre o que o utilizador vê, e não sobre o que o modelo faz.

Aparecer trabalho novo não é o mesmo que efetivos novos: isto está a ser absorvido pelos lugares existentes, e nada aqui diz que alguém tenha sido contratado para o fazer.