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.

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
5. <input id="autocomplete" placeholder="Busque..." /> <script src="autocomplete.js"></script> <script> autocomplete("#autocomplete", {}) </script>
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