Do jQuery aos microfrontends: os desafios de manter uma aplicação web

188900fc4ed166ff159a9b74aa38a9bd?s=47 fernahh
July 05, 2018

Do jQuery aos microfrontends: os desafios de manter uma aplicação web

A web é a principal plataforma para desenvolvimento de software. Temos diversas ferramentas e técnicas para construir aplicações escaláveis. Mas depois de quase uma década de desenvolvimento, como manter uma aplicação sem reescrever tudo? Nessa palestra iremos ver quais as boas características que uma aplicação web deve ter. Veremos os principais desafios, erros e acertos ao desenvolver um produto usando JavaScript. Apresentaremos técnicas de como mantemos uma aplicação web com quase 10 anos e que já passou por mais de 800 mil usuários.

188900fc4ed166ff159a9b74aa38a9bd?s=128

fernahh

July 05, 2018
Tweet

Transcript

  1. 4.
  2. 6.
  3. 7.

    Hoisting em JavaScript é o que acontece quando funções e

    variáveis são elevadas ao topo de um escopo.
  4. 10.

    Plataforma de gestão empresarial A empresa foi fundada em 2012.

    O objetivo é dar tempo ao micro e pequeno empresário para focar no que interessa: seu negócio.
  5. 13.

    Camada de apresentação. • O HTML era gerado no servidor,

    prática comum para a época. • A camada de estilo era escrita com Less para facilitar a criação de temas. • O comportamento era feito com JavaScript puro e bibliotecas como a clássica jQuery.
  6. 19.

    Aprendemos que o DOM é lento, e escrever código performático

    na maioria das vezes prejudica a legibilidade.
  7. 20.

    Mesmo quando JavaScript era usado apenas para “validar formulários”, a

    chance dele se tornar um caos era muito grande.
  8. 27.
  9. 31.

    Além de comportamento, hoje o JavaScript atua na entrega de

    conteúdo, faz build e também é responsável pelo estilo.
  10. 38.

    Two-way Data Binding Além do fluxo do modelo para a

    UI, nessa abordagem a UI também faz atualizações no modelo.
  11. 40.
  12. 42.

    good parts AngularJS como framework front-end • A comunidade em

    torno do framework cresceu e se tornou a maior da época. • Rápido para prototipar ideias e desenvolver experimentos. • Prioriza a separação de camadas entre HTML e JavaScript.
  13. 43.

    bad parts AngularJS como framework front-end • Two-way binding facilmente

    se torna um rio de side effects. • Dependency Injection se tornou burocrático após ES Modules. • Problemas de performance aparecem em pouco tempo de uso.
  14. 48.

    R$ 100 Salvar Possibilidades de uso • Receber um texto

    • Receber um ícone • Disparar uma ação
  15. 49.

    R$ 100 Salvar Possibilidades de uso • Receber um texto

    • Receber um ícone • Disparar uma ação • Receber um totalizador (????) updateTotal()
  16. 52.

    “Ao abstrair e tornar mais polimórfico, você está restringindo o

    espaço de implementação, diminuindo a possibilidade de erros.” @rodrigowillrich
  17. 54.

    Testes end-to-end São difíceis de manter em grande escala, mas

    numa lib de componentes talvez faça sentido.
  18. 55.

    good parts Testes end-to-end • Faz sentido quando você quer

    testar uma biblioteca de componentes ao invés do sistema todo. • Podem pegar erros que são difíceis de testar de forma unitária.
  19. 56.

    bad parts Testes end-to-end • São difíceis de manter quando

    se tem muitas telas. • Se tornam lentos e custam caro para o processo de CI/CD. • A certeza que irá pegar todos os bugs não é garantida.
  20. 59.

    “Why does one choose to use Gmail over Yahoo, Medium

    over Blogger, if the feature are 99% the same? ... https://uxdesign.cc/ux-trends-2017-46a63399e3d2
  21. 60.

    …It’s definitely not about disrupting usability standards. It’s about that

    additional layer of sophistication (...) of tiniest details, the most subtle animations, the most elegant transitions.” https://uxdesign.cc/ux-trends-2017-46a63399e3d2
  22. 62.

    good parts Componentes Vanilla • Ter o CSS em folhas

    de estilo facilitam o uso entre tecnologias diferentes. • Apenas instanciar um objeto padroniza comportamentos.
  23. 63.

    bad parts Componentes Vanilla • Código performático != código legível.

    • Muitas libs já são escritas diretas nos frameworks. • Complexo para escrever testes unitários.
  24. 69.

    Débitos técnicos Significam o custo implícito por uma escolha mais

    “fácil e rápida”. Se a dívida não for paga, ela pode cobrar juros.
  25. 70.

    Débitos técnicos. • Ajudam a quantificar e ter uma visão

    de quanto o time está investindo em soluções paliativas. • Servem como documentação do histórico de implementações pobres.
  26. 72.

    O que ouvimos falar são as histórias que deram certo.

    Ninguém conta as cagadas que acontecem no dia-a-dia das empresas. https://engineering.contaazul.com/o-santo-graal-da-arquitetura-de-software-n%C3%A3o-exi ste-7c4cdcc75475
  27. 73.

    É preciso entender que por trás das boas histórias há

    muito trabalho e, provavelmente, alguns débitos técnicos foram comprados. https://engineering.contaazul.com/o-santo-graal-da-arquitetura-de-software-n%C3%A3o-exi ste-7c4cdcc75475
  28. 75.

    “We don’t hire people to write code. We hire them

    to solve problems.” Jem Young https://twitter.com/NetflixUIE/status/1012568486848000000
  29. 77.

    Modelo de maturidade É um modelo que ajuda a determinar

    a eficácia de um software e onde ele pode ter um desempenho melhor.
  30. 80.

    “The vital point here is that the true outcome of

    a maturity model assessment isn't what level you are but the list of things you need to work on to improve.” Martin Fowler https://www.martinfowler.com/bliki/MaturityModel.html
  31. 82.

    Projetos de Big Picture. • A cada trimestre, desenvolvedores faziam

    proposta de projetos em que eram priorizadas por eles mesmos. • Cada projeto poderia durar duas semanas, e poderia ser executado por dois desenvolvedores. • Proporcionou-nos pagar diversos débitos e desenvolver features para aumentar a produtividade da engenharia.
  32. 83.

    Time Foundation. • Responsável por desenvolver soluções para aumentar a

    produtividade e a qualidade das entregas do time de engenharia. • Executa tarefas como atualizações de bibliotecas, desenvolvimento de componentes e continuous integration.
  33. 86.

    “Isolar” o AngularJS. • Controllers, factories e filters são escritos

    apenas com JavaScript. • As dependências do Angular ficam em um arquivo de configuração de índice do módulo. • Inversão de Dependência é usado para abstrair implementações, e dessa forma não “espalhar o framework”. https://engineering.contaazul.com/angularjs-e-alguns-passos-para-atualizar-sua-stack-f6ab35 f70af9
  34. 88.

    Problemas • Muitas das soluções para resolver produtividade e qualidade

    são de longo prazo. • Tomar decisões sobre design de código e escolha de tecnologias são difíceis em “monolitos”. • Nosso estrutura organizacional não representava nossa arquitetura de software.
  35. 89.

    “An alternative route (to rewrite a system entirely) is to

    gradually create a new system around the edges of the old.” Martin Fowler https://www.martinfowler.com/bliki/StranglerApplication.html
  36. 92.

    bad parts Microfrontend • Ainda é algo novo e pouco

    explorado pelo mercado. Muito do que fizemos foi dentro de casa. • Precisamos de disciplina e muito alinhamento para evitar retrabalho dos times.
  37. 93.

    good parts Microfrontends • Provê uma maior autonomia para os

    times tomarem suas próprias escolhas. • Nos deu a possibilidade de testarmos novas tecnologias e paradigmas. • O build/deploy é, consequentemente, bem mais rápido que o monolito.