O que desenvolvedores back-end deveriam aprender sobre front-end

Há alguns anos a ideia que se tinha de desenvolvedores front-end, era daqueles caras descolados que sabiam recortar um layout em alguma ferramenta de edição de imagens, aplicar em folhas de estilos utilizando tableless (não comentarei sobre a era das tables), construir formulários elegantes, arredondar bordas e algumas animações/transições em javascript. Além de tentar fazer tudo isso funcionar na maior quantidade de versões de navegadores e sistemas operacionais diferentes. Aliás, o próprio termo “desenvolvedor front-end” é recente, antes eram chamados bizarramente de “webdesigners”. O fato é: as skills desse cara aumentaram à medida que as tecnologias de front-end evoluíram.

É claro que ainda há diferentes competências quando se fala em desenvolvimento front-end, um lado mais voltado à arte, define cores, tipografia, fontes, imagens, espaçamento, etc. O outro, mais próximo de você – desenvolvedor back-end codeiro, mete a mão no código, geralmente javascript, para construir plug-ins, controllers, serviços, diretivas, testes e muitas outras coisas que todo desenvolvedor back-end faz no seu dia-a-dia. E é nesse ponto que eu queria chegar, nas tecnologias de front-end que desenvolvedores back-end deveriam, no mínimo, saber que existem. Note, não vou esmiuçar cada uma delas, apenas comentar sobre sua importância para o mundo. Vamos lá.

HTML 5 + CSS 3

Começando pelo óbvio: HTML 5. Sua utilização já é realidade na web, suportado por diferentes versões de navegadores, sua grande vantagem está na semântica atribuída às paginas, contribuindo para técnicas de SEO. Além de possuir uma série de recursos e propriedades novas, principalmente relacionadas aos formulários, melhorando a usabilidade. Ao lado do HTML 5, vem o CSS3, aprimorando sua versão anterior com melhorias na transição de efeitos, inclusão de novos seletores, bordas arredondadas e sombreamento, sem a necessidade de workarounds. Considere utilizar pré-processadores e frameworks de CSS, como SASS e LESS, para melhorar a produtividade e diminuir a replicação de código. Com eles você pode deixar a construção de folhas de estilo mais “programáticas”, definindo variáveis para reutilizá-las em diferentes seletores; aninhamento de seletores um dentro dos outros; mixins para agrupar várias propriedades e até mesmo operações matemáticas, a exemplo de tamanho de fontes.

JavaScript

JavaScript é o motor de tudo que roda no client-side, com ele podemos manipular o DOM de cada página, alterar o CSS e melhorar a experiência do usuário. Entretanto, mexer com javascript puro pode ser uma dor de cabeça e não é nada produtivo. Para contornar esse problema, surgiram bibliotecas que abstraem sua complexidade em funções mais simples de serem utilizadas, a mais famosa e quase onipresente é o jQuery. Entre suas vantagens estão: acesso facilitado a elementos do DOM, manipulação de conteúdo, suporte a diversos eventos, variedade de efeitos e transições, simplicidade para realizar requisições AJAX e cross-browser. Com uma comunidade bastante ativa, existem uma infinidade de plug-ins para fazer quase tudo que você precisar, com pouca ou nenhuma customização.

Manipular o DOM pode parecer bacana, mas em projetos com front-end mais complexo, a manutenção desse código fica complicada e difícil de testar. Aí que entra os frameworks MVC, ou MVW (Model View Whatever) cliente-side, como o AngularJS, criado pelo google, ele possuí um recurso chamado Two-way Data binding que vincula elementos da página ao seu escopo de controle, onde qualquer alteração no modelo reflete na view e vice-versa, sem necessidade de manipulação de DOM e facilmente testável. Em frameworks desse tipo, foram introduzidos recursos de injeção de dependências, diretivas, controllers, services e filters, além de favorecer o teste automatizado de suas funcionalidades. Com o mesmo propósito do AngularJS, temos o Backbone.js e Ember.js, com algumas diferenças entre eles, existem vários benchmarks comparando-os na web. Vale a pesquisa para identificar qual melhor se encaixa no seu projeto.

Gerenciar dependências

Gerenciar dependências é uma tarefa corriqueira para desenvolvedores back-end. Quando se falava em front-end, baixar as bibliotecas necessárias pro seu projeto sempre foi uma tarefa manual e suscetível a erros: entrar no site do projeto, baixar a versão desejada, salvar no diretório correto, atualizar versões antigas. O Bower é uma ferramenta que possibilita gerenciar pacotes front-end de maneira automatizada e configurável, criado pela equipe do twitter. Para instalar o Bower você precisa do node.js instalado em sua máquina, a partir daí, com poucas linhas de comando pode-se começar a baixar as dependências do seu projeto, inclusive com configurações de versões específicas ou mais recentes, busca de pacotes, informações dos repositórios e diversos outros recursos. Uma mão na roda.

Automatizar tarefas

Assim como gerenciar dependências, automatizar as tarefas de build são cotidianas no processo de desenvolvimento. Em front-end não há porque ser diferente, minificar e concatenar scripts, por exemplo, são tarefas importantes que devem ser feitas em seus projetos. Assim como o Ant ou Maven, o Grunt  é uma ferramenta de automatização voltado para o front-end e também precisa do node.js para ser instalado, basta instalá-lo através do gerenciador de pacotes npm, juntamente com seu cliente de linha de comando (grunt-cli). No arquivo gruntfile.js é onde deverão estar o agendamento de tarefas a serem executadas pelo Grunt, a propósito o Grunt possuí milhares de plug-ins para suportar diversas funcionalidades, entre elas a minificação e concatenação de folhas de estilos e arquivos javascript de forma bem simples. Lembre-se, automatizar tarefas deixa seu processo mais seguro e produtivo, faça isso no front-end também.

Testar

Escrever testes automatizados é quesito obrigatório. No mundo javascript, uma das ferramentas mais populares é o Jasmine, um framework de BDD que permite a construção de testes de unidade, ele se baseia no conceito de specs, que nada mais é que um arquivo javascript onde estarão descritos os cenários de testes de cada unidade de código que deverá ser testada. Com uma série de recursos para simplificar a estrutura dos testes, o Jasmine possui também um módulo de integração com o AngularJS, para fazer injeção de dependências, mockar serviços de back-end, etc. Além de testes de unidade, os testes end-to-end também são importantes, pois testam a aplicação do ponto de vista do usuário, se todo o fluxo de tarefas está sendo executado do início ao fim. Para isso, a equipe do AngularJS desenvolveu o Protactor, uma ferramenta específica para testes end-to-end que facilita a utilização do Selenium, ferramenta de automatização de testes em navegadores.

Escrever testes garante que nossa aplicação esteja funcionando como planejado. Entretanto, quando a suíte de testes fica grande o bastante, rodar os testes passa a ser um processo custoso e demorado. Para contornar este cenário, foi desenvolvido o Karma, uma ferramenta para dar feedback constante a cada atualização de arquivos javascript do projeto. O Karma também roda sob o Node.js e pode ser instalado pelo npm. Seu principal arquivo de configuração é o karma.config.js, onde são informados os arquivos a seres monitorados, o framework de teste e o navegador para execução. Após a configuração é só dar um start no ambiente do karma e o navegador indicado será executado e exibirá o resultado dos testes, a partir disso, qualquer alteração nos arquivos javascript disparará novamente os testes. Parece mágica!

Bom, vou finalizar por aqui, mas ainda ficam de fora pontos importantes como mobile, acessibilidade e debug. Enfim, depois dessa avalanche de tecnologias e ferramentas deu pra perceber que o desenvolvimento front-end está tão divertido quanto planejar as várias camadas e padrões de uma super arquitetura enterprise, ou não…

Nota: Esta é só uma visão pessoal de um programador javeiro, entusiasta de javascript e algumas outras coisas mencionadas neste texto. Se você concorda, discorda ou acha que outras tecnologias deveriam ter sido citadas aqui, comente aí.


Comentários

8 respostas para “O que desenvolvedores back-end deveriam aprender sobre front-end”

  1. Parabéns Kaio pelo excelente post. Percebe-se que você está bem antenado com as novidades, pelo menos para mim kkk. Acredito que pode rolar vários outros posts, um para cada tecnologia mencionada, explorando mais ainda esse mundo front-end.

    Mais uma vez parabéns!

  2. Parabéns Kaio pelo excelente artigo, uma dúvida, você utiliza o firebug para o debug no Angular?

    Abraços.

  3. Valeu Marquinho, ultimamente tenho utilizado mais o DevTools do Chrome, mas curto bastante o firebug também.

  4. Avatar de Leandro Almeida
    Leandro Almeida

    Fala Kaio, parabens pelo artigo!
    O que vejo particularmente hj em dia, é que a maioria dos projetos não fazem testes automatizados de front-end (posso estar enganado). No máximo, quando há, são testes no back-end.

    Tenho algumas dúvidas:

    1. Queria saber, de acordo com tua experiencia, se adicionar esse passo no processo de desenvolvimento gera algum gargalo/atraso na entrega? Sei que os benefícios são indiscutíveis, se os testes forem bem implementados.
    2. O fato de incluir os testes de unidade em JS me obriga a mudar meus scripts atuais ou paradigma de programação (por exemplo, mudar de programação procedural (muito comum nos projetos) em JS para orientação a objetos ou algum outro) ?
    3. Em relação aos testes em si: eles são feitos para testar a execução em tempo real do script (rodando direto no navegador, tipo como Selenium), ou são testes de API ou funções javascript que você desenvolveu no projeto ? (desculpe se eu estiver falando besteira).

    Mais uma vez, parabens pelos artigos, continue escrevendo-os para a comunidade 🙂

  5. Opa Leandro, Valeu.

    Sobre a utilização de testes no front-end, geralmente quando se usa frameworks MVC client-side, como AngularJS, é comum (e recomendável) rodar testes, pois a tecnologia permite de forma fácil. Isso é possível, principalmente, porque não é necessário manipular o DOM.

    Quanto as dúvidas, a minha opinião é:

    1. Assim como escrever teste no back-end, em um primeiro momento pode-se ter a impressão que o tempo de desenvolvimento é maior, mas a médio e longo prazo esse custo se paga, devido a maior qualidade do código, diminuição de bugs, etc. Acho que os argumentos aqui são os mesmos.

    2. Esse ponto é interessante, partindo do princípio que os testes nos ajudam a buscar melhores soluções de design pro nosso código, isso é valido pra js também. Mais uma vez, quando se utiliza frameworks MVC, você tem o conceito de Controllers, Services, Factorys, e isso não se parece nem um pouco com programação procedural. Ainda se espera construir funções coesas, com responsabilidades definidas, etc. Acho a documentação do Jasmine muito boa, lá fica bem clara a utilização de testes com JS, dá uma olhadinha (http://jasmine.github.io/2.1/introduction.html).

    3. Os dois, os testes são feitos tanto para testar as funções rodando em um browser real, em tempo de execução. Quanto para testar APIs, como por exemplo, testar um request ajax em um endpoint REST. Tudo é possível.

    Não sei se respondi tudo.

    Abraço Leandro.

  6. Opa, respondeu sim! Valeu!!

  7. Muito bom artigo Kaio, parabéns!

  8. Gostei! Parabéns pelo artigo, excelente!

Deixe um comentário

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *