A nova web demanda novas práticas de desenvolvimento
•Descargar como PPTX, PDF•
4 recomendaciones•2,260 vistas
Palestra ministrada no Agile Trends
Recomendados
Más contenido relacionado
La actualidad más candente
La actualidad más candente (20)
Destacado
Destacado (20)
Más de Giovanni Bassi
Más de Giovanni Bassi (20)
A nova web demanda novas práticas de desenvolvimento
- 1. A nova web demanda novas práticas de desenvolvimento @GiovanniBassi
- 5. ...
- 6. ...
- 19. Testes
Notas del editor
- Desenvolver para a web há muitos anos significava usar Perl, Php, Java, C#, Ruby ou alguma outra linguagem que rodasse no servidor. Javascript ficava pra alguma coisa mais interativa, e só. Mas de uns anos pra cá o Javascript está retomando o controle da web: as Single Page Applications (SPAs) estão cada vez mais presentes, e até um servidor baseado em Javascript está rodando em mais e mais lugares – e se dizendo mais eficiente que todos os outros. Com essa mudança acontecendo algumas práticas precisam ser repensadas e outras completamente adaptadas. Novas maneiras de alcançar o mesmo objetivo estão surgindo. Nessa sessão vamos ver o que mudou e o que pode ser melhor quando você desenvolve com esse novo paradigma em mente.
- 1. Start bymakingyouraudiencecare, using a relatableexampleoranintriguingidea.Alguns de nós desenvolvem pra web desde que ela ficou disponível, ou seja, cerca de 20 anos.No começo desenvolver pra web significava somente fazer um HTML estático. A linguagem era HTML.Depois passou a ser usar CGI com qualquer linguagem que conseguisse responder na linha de comando.Aí vieram as linguagens de Script. ASP, PHP, entre outras. E elas evoluíram pra Java, C#, Ruby, Python, etc.Com certeza entre nós temos desenvolvedores de Java, Ruby, Python, PHP, Perl. Alguns de nós desenvolvem pra web desde que ela ficou disponível, ou seja, cerca de 20 anos, e começaram com HTML e CGI.
- Só que isso está mudando. Desenvolver pra web cada vez mais significa escrever uma única linguagem: JavaScript. Ou qualquer coisa que compile pra JavaScript, tipo TypeScript ou CoffeeScript. O desenvolvimento nao está mais só no backend, estamos fazendo aplicações que estão quase todas no front-end, e o backend responde JSON. Paramos de entregar dinamicamente o HTML e passamos a entregar JSON. E o Xml, que dá nome ao Ajax está morrendo.
- Estamos cada vez mais trabalhando com o conceito de SPAs. O usuário espera uma SPA, ele gosta da responsividade e da velocidade. Mesmo que sua app nao seja uma SPA, ela vai ter partes que serao, ou serao algo muito parecido.
- 2. Explainyourideaclearlyandwithconviction.E com toda a app no front end as regras mudaram. Uma única linguagem nos une, independemente se você coda no Windows, Mac, ou Linux.O problema é que muda tudo. As ferramentas de desenvolvimento mudam. A gestao do código fonte é diferente. As pessoas precisam se especializar mais. O código precisa ser mais organizado. Escrever testes é diferente. SEO muda completamente. O processo de build muda.Deploy é completamente diferente.
- 3. Describeyourevidenceandhowandwhyyourideacouldbeimplemented.Ferramentas:Nao necessariamente a melhor IDE pra desenvolver Java ou C# é também a melhor pra desenvolver JavaScript. As ferramentas de testes, build e deploy também mudam.Codamos na nuvem com Nitrous.io, Cloud9, ou parecidos, e no desktop com Sublime, VIM, Webstorm, etc. Linguagens dinâmicas como o JavaScript geralmente vivem muito bem sem IDEs. Temos ainda que minificar o JavaScript. As ferramentas de testes e build também mudam, mas já falamos delas.
- SourceControl: A gestao do código fonte é completamente diferente. Você nao coloca dlls, JARs ou GEMs no seu sourcecontrol, porque colocaria o jquery.js, ou backbone.js? Temos tentado usar algumas ferramentas que já sao usadas no backend pra resolver esse problema. Talvez você encontre uma gem ou um nuget de jQuery. Mas isso nao faz sentido, essas ferramentas nao foram feitas pra isso.
- Isso já foi resolvido e se chama Bower. O Bower permite gerenciar as dependências de front-end, colocar dependências entre elas, e já está ligado diretamente no Github, ou seja, está sempre atualizado. As principais bibliotecas já estao lá. E o Bower é um componente do Node.
- Especializaçao: Talvez nao seja possível manter uma pessoa muito especializada em front-end e back-end. Um desenvolvedor iniciante vai ter que escolher.
- Organizaçao do código: Um projeto pequeno consegue passar batido com algumas tags script numa página html. Um projeto maior vai precisar gerenciar dependência entre esses arquivos, otimizar sua carga, etc. O RequireJS utiliza o padrao AMD onde você consegue dizer arquivo deve ser carregado, na ordem correta, e sem poluir o objeto global.
- Testes: Uma aplicaçao com grande dependência de JS precisa de testes de unidade. Temos inúmeras bibliotecas que podem ser usadas (Jasmine, QUnit, Mocha, Chai, Sinon, etc). O processo de testes tem que ser fácil. Algumas IDEs já suportam rodar testes de unidade diretamente, como o Visual Studio que roda QUnit e Jasmine.
- Com o NodeJS podemos simular o DOM na memória e rodar testes sem precisar de um headless browser.
- SEO: Uma SPA nao ter seu conteúdo detectado pelo mecanismos de buscas. Você vai ter que servir html estático quando um crawler se identificar. O #! é o caminho pra isso, junto com PhantomJS.
- Build: O build de uma aplicaçaobackend vai às vezes gerar um binário e rodar os testes. Mas nao vai tratar o resultado do front-end. Precisamos compilar o front-end se for escrito em CoffeeScript ou TypeScript, e rodar os testes de unidade com JS.
- Deploy: O deploy de uma aplicaçao dependente de JS pode ser feito em dois estágios, um para o backend, outro para o front-end. Você vai: - Buildar e testar o JS. - Minificar o JS. - Otimizar o RequireJS. Após o build concluido você vai ter um arquivo JS de base e um JS para cada SPA da sua app. Esses arquivos nao precisam ser deployados junto com sua aplicaçao de backend. É muito provável que eles possam rodar a partir de um servidor web mais simples ou até de um CDN. E o ideal é que estejam em outro domínio pra evitar o tráfego indevido de cookies.
- 4. Endbyaddressinghowyourideacouldaffectyouraudienceiftheyweretoaccept it.NodeJS: O NodeJS é a resposta pra boa parte dos problemas. A comunidade de JS está se agregando a sua volta. Mesmo que você nao vá rodar JS no server, o Node vai ser uma excelente ferramenta para te auxiliar no processo de desenvolvimento.Grunt pode te ajudar a otimizar tarefas de gestao do JS, como build, testes e deploy.Bower vai gerenciar suas dependências. Uma simulaçao do DOM vai te ajudar a rodar testes.
- JS é uma linguagem de verdade. Trate ela como uma.Adotando essas práticas você vai testar melhor. Vai escrever JavaScript mais organizado. Vai fazer deploy de maneira mais segura, com um overhead menor e em menos tempo.Você ainda vai desenvolver JS como se fosse 1995?