Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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. do jQuery aos microfrontends: os desafios de manter uma aplicação

    web.
  2. Antes de tudo, uma história real.

  3. Desenvolver componente de autocomplete Created 30 min ago

  4. None
  5. <input id="autocomplete" placeholder="Busque..." /> <script src="autocomplete.js"></script> <script> autocomplete("#autocomplete", {}) </script>

  6. None
  7. Hoisting em JavaScript é o que acontece quando funções e

    variáveis são elevadas ao topo de um escopo.
  8. @fernahh fernahh.com

  9. ContaAzul contaazul.com/vagas

  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.
  11. Nosso tamanho 350+ funcionários 4.000+ escritórios contábeis parceiros 1.000.000+ empresas

    já começaram a usar
  12. Nossas primeiras tecnologias.

  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.
  14. Nome Categoria Cadastro de Produto Salvar

  15. Nome Categoria Cadastro de Produto Salvar 1. $.keyup() 2. $.addClass()

    3. $.removeClass()
  16. Nome Categoria Cadastro de Produto Salvar 1. $.click() 2. $.get()

    3. $.appendTo()
  17. Nome Categoria Cadastro de Produto Salvar 1. $.click() 2. $.post()

    3. $(location).attr()
  18. Por vários anos, o paradigma orientado a eventos reinou sobre

    o desenvolvimento web.
  19. Aprendemos que o DOM é lento, e escrever código performático

    na maioria das vezes prejudica a legibilidade.
  20. Mesmo quando JavaScript era usado apenas para “validar formulários”, a

    chance dele se tornar um caos era muito grande.
  21. Enquanto isso o mercado estava cada vez mais desenvolvendo aplicações

    com tecnologias web.
  22. Ter apenas um software “na nuvem” já não era mais

    um diferencial.
  23. Requisitos universais de uma aplicação web.

  24. Atrativa Simples de usar Acessível Rápida

  25. Atrativa Simples de usar Acessível Rápida Design Usabilidade Acessibilidade Performance

  26. Reescrever aplicações quase nunca é uma boa ideia.

  27. Especificação Ao longo do tempo muitas melhorias e correções são

    desenvolvidas, e nunca são documentadas.
  28. Custo Uma aplicação de tamanho médio, vai levar no mínimo

    ~6 meses para ficar pronta.
  29. http://www.ben-morris.com/why-refactoring-code-is-almost-always-better-than-rewriting-it/

  30. O advento das ferramentas JavaScript.

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

    conteúdo, faz build e também é responsável pelo estilo.
  32. JavaScript é, indiscutivelmente, a linguagem mais importante da década.

  33. JavaScript é, indiscutivelmente, a linguagem mais importante da década.

  34. Backbone Angular Ember React Vue

  35. Data Binding e MV* Frameworks foram boas ideias...

  36. Data Binding Permite que possamos conectar mudanças de um modelo

    para a UI.
  37. API Model Template Merge View JSON JavaScript Linguagem de template

    HTML
  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.
  39. API Model View JSON JavaScript HTML Template Linguagem de template

    Compile
  40. API Model View JSON JavaScript HTML Template Linguagem de template

    Compile “seria o fim dos callbacks?”
  41. AngularJS como framework front-end

  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.
  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.
  44. Jornada em busca de produtividade.

  45. Paradigmas baseados em componentes ganharam mercado.

  46. Abstração

  47. Salvar Possibilidades de uso • Receber um texto • Receber

    um ícone • Disparar uma ação
  48. R$ 100 Salvar Possibilidades de uso • Receber um texto

    • Receber um ícone • Disparar uma ação
  49. R$ 100 Salvar Possibilidades de uso • Receber um texto

    • Receber um ícone • Disparar uma ação • Receber um totalizador (????) updateTotal()
  50. Salvar <ca-button data-text="Salvar" data-action="save()"/>

  51. Salvar <ca-totals data-value="total"/> Total: R$ 100 <ca-button data-text="Salvar" data-action="save()"/>

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

    espaço de implementação, diminuindo a possibilidade de erros.” @rodrigowillrich
  53. Facilidade para testar

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

    numa lib de componentes talvez faça sentido.
  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.
  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.
  57. Reuso de código

  58. Possibilidade de pensar no WOW!

  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
  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
  61. Criamos uma biblioteca de componentes “vanilla”

  62. good parts Componentes Vanilla • Ter o CSS em folhas

    de estilo facilitam o uso entre tecnologias diferentes. • Apenas instanciar um objeto padroniza comportamentos.
  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.
  64. O que fazer com o código legado?

  65. Como sobreviver sem reescrever tudo.

  66. Dor Recurso Soluções Continuidade

  67. Dor Recurso Soluções Continuidade

  68. Antes de tudo, é preciso saber onde estão as dores

    do time.
  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.
  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.
  71. O Santo Graal da arquitetura de software não existe.

  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
  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
  74. Nerd adora falar mal de tecnologia. https://engineering.contaazul.com/o-santo-graal-da-arquitetura-de-software-n%C3%A3o-exi ste-7c4cdcc75475

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

    to solve problems.” Jem Young https://twitter.com/NetflixUIE/status/1012568486848000000
  76. Dor Recurso Soluções Continuidade

  77. Modelo de maturidade É um modelo que ajuda a determinar

    a eficácia de um software e onde ele pode ter um desempenho melhor.
  78. https://www.martinfowler.com/bliki/MaturityModel.html

  79. https://info.thoughtworks.com/rs/thoughtworks2/images/agile_maturity_model.pdf

  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
  81. Dor Recurso Soluções Continuidade

  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.
  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.
  84. Dor Recurso Soluções Continuidade

  85. Vale a pena desenvolver produtos com AngularJS?

  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
  87. Microfrontends

  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.
  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
  90. Mount Rota indica um módulo Request do módulo

  91. https://engineering.contaazul.com/evolving-an-angularjs-application-using-microfrontends- 2bbcac9c023a

  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.
  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.
  94. Nenhuma dessas soluções funcionam sem boas pessoas.

  95. obrigado! @fernahh engineering.contaazul.com