Skip to content

Instantly share code, notes, and snippets.

@jaydson
Last active July 23, 2017 16:29
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save jaydson/5c3977d129454493bb7b to your computer and use it in GitHub Desktop.
Save jaydson/5c3977d129454493bb7b to your computer and use it in GitHub Desktop.
Processo de desenvolvimento front-end

No Terra o nosso processo de desenvolvimento front-end evoluiu muito nos últimos anos.
Relatei o histórico dessa evolução e como saimos de um processo totalmente falho para um processo eficaz e automatizado na palestra "Processo de Desenvolvimento front-end - Do caos ao Sublime", também disponível em vídeo.
Nosso processo antigo baseava-se basicamente em uma coisa: fazer commit no SVN.
Em uma imagem:
Go-Horse detected

Esse processo testless, horseness, etc, provavelmente foi aplicado em muitas empresas no passado (e ainda é!?!?!?!), e mudar a cultura é algo difícil.
Isso tudo foi na era pré-jQuery e eu ainda nem fazia parte da empresa, mas quando cheguei, esse era o cenário.

Acredito que a base para se ter um produto de qualidade é garantir que o código também tenha qualidade.
Um ambiente de desenvolvimento com tecnologia de ponta e processos bem definidos é uma das ferramentas que vai nos permitir fazer código consistente, consequentemente gerando produtos melhores.

Testar front-end é difícil

Front-end é diferente. Deal with it.
Óbvio que muitos dos conceitos existentes em outras linguagens e plataformas são aplicáveis nesse mundo, mas não tudo.
Para empresas em que a realidade não é o desenvolvedor full-stack isso fica muito claro. Basta falar com um desenvolvedor com brackground back-end para entender que pouca coisa pode ser reutilizada na camada do browser.
Fazer qualquer tipo de teste no ambiente front-end não é uma tarefa fácil.
A velha história: browsers, resolução de tela, sistema operacional, devices e plataformas diferentes são algumas das variáveis que temos nesse mundo complexo.
A verdade é que agora estamos em um cenário totalmente diferente. Dizer que "é difícil" não é mais desculpa, e difícil não é impossível.
Com o avanço da tecnologia na área de front-end e a quantidade de ferramentas disponíveis que temos atualmente, testar bem e de forma automatizada o seu produto, ter processos coerentes, seguir e aplicar conceitos sólidos de mercado, etc, é o mínimo.

Onde estamos no Terra

Estamos no ponto que ainda considero básico.

  • Todas aplicações são (ou devem ser) baseados em um Framework interno
  • Todas aplicações devem possuir testes unitários
  • Os testes unitários rodam no PhantomJS e no browser
  • Todas aplicações são iniciadas com um scaffold básico que garante consistência
  • Todas aplicações devem ser documentadas
  • O build de todas aplicações são baseadas no Grunt
  • O Grunt garante que todas aplicações possuam tasks básicas de validação e de build
  • Cada aplicação é um projeto isolado no Github (usamos a solução enterprise)
  • O deploy é feito de forma automática pelo noss CI server (Jenkins)
  • O CI server obrigatóriamente roda as tasks de build e validação

Pontos falhos que devemos melhorar:

  • O desenvolvedor pode desabilitar os testes antes de fazer deploy
  • Grande parte dos testes da aplicação precisam de mão humana
  • Não existe teste comportamental nos projetos (BDD)
  • Não existe teste automatizado para múltiplas plataformas
  • Não existe teste automatizado para múltiplos browsers
  • Não existe teste automatizado para múltiplos dispositivos
  • Não existe um dashboard para acompanhar o status de cada aplicação

Como resolver os pontos falhos

"O desenvolvedor pode desabilitar os testes antes de fazer deploy"

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment