Continuação do roadmap de front-end, com Adriana Saty voltando ao programa para aprofundar as tecnologias que vêm depois do HTML, CSS e JavaScript básicos. A conversa passa por frameworks, formas modernas de organizar CSS, testes automatizados, TypeScript e termina numa reflexão sobre dívida técnica e responsabilidade profissional — sempre ancorada na experiência prática de Adriana em empresas grandes no Brasil e, mais recentemente, em uma empresa americana, o que dá ao episódio um contraponto interessante entre dois mercados com culturas de engenharia bem diferentes.
Desenvolvedora de software front-end há cerca de três anos à época da gravação, Adriana Saty passou por empresas como Accenture, Santander e Itaú antes de migrar para uma empresa americana, experiência que usa no episódio para comparar a maturidade de testes e processos entre os dois mercados. Também produz conteúdo sobre front-end nas redes sociais, e já havia participado da primeira parte deste roadmap.
Adriana evita declarar um vencedor entre React, Angular e Vue.js e propõe outro critério: o tipo de empresa em que cada um costuma aparecer. Segundo ela, o Angular traz uma arquitetura mais rígida e já vem com TypeScript de fábrica, o que reduz o espaço para erro em times menos experientes — mas costuma estar em empresas de cultura mais tradicional, mais sólida, e com menos espaço para inovar ou fazer diferente. React, por outro lado, dá mais liberdade, o que exige mais maturidade do time para não degenerar em código inconsistente quando cai na mão de alguém sem supervisão. Ela também nota que a fama de o Vue ter curva de aprendizado mais suave não bateu com a própria experiência: o primeiro contato dela com o framework foi num projeto híbrido, meio Angular meio Vue, e a documentação do Vue lhe pareceu mais confusa do que a do React ou do Angular, que considera mais ricas em exemplos.
"Eu acho que essa parte da curva de aprendizado vai muito da experiência que a pessoa tem." por Adriana Saty
Antes de Styled Components e CSS Modules, uma classe CSS criada para um componente podia sobrepor estilos em qualquer outra parte da aplicação — um problema clássico em bases de código React que crescem sem controle, mesmo em projetos que já adotavam metodologias como BEM ou pré-processadores como Sass para organizar as folhas de estilo. Adriana explica que essas abordagens modernas encapsulam o estilo dentro do próprio componente, eliminando esse vazamento, ao custo de exigir atenção redobrada para não duplicar CSS que deveria ser global — como uma classe utilitária de centralização de texto usada em toda a aplicação. Na visão dela, esse é justamente o tipo de decisão que exige alguém com conhecimento macro do projeto revisando cada mudança, capaz de apontar quando uma classe já existe em outro lugar antes que ela seja recriada.
"Quando você utiliza tanto o style componentes como CSS modules você consegue utilizar aquela classe só ali então você meio que encapsula aquele CSS." por Adriana Saty
Para Adriana, a tipagem estática evita que uma mudança no back-end quebre silenciosamente o front-end, porque o compilador aponta o erro antes de chegar em produção — se uma chamada de API muda de formato e o time esquece de avisar, o TypeScript acusa o problema na hora, em vez de deixá-lo estourar em runtime. O ponto de atrito é a compatibilidade: bibliotecas sem suporte a TypeScript já geraram retrabalho real em projetos que ela conduziu, exigindo que a própria equipe tipasse manualmente o pacote antes de usá-lo. Tipar corretamente também exige mais tempo no começo do desenvolvimento, e às vezes esbarra em casos que resistem à tipagem e acabam forçando o uso de any — mas, para ela, essa freada inicial se paga no médio prazo, da mesma forma que os testes automatizados.
"Pra mim o TypeScript é vida." por Adriana Saty
A experiência de Adriana em empresa americana contrasta com o que ela viveu no Brasil: por aqui, segundo ela, a cultura de testes ainda é incipiente, e mesmo quando existe boa cobertura, muitos testes validam apenas o superficial — como a cor de um botão — sem simular de fato o comportamento esperado pelo usuário. Lá fora, a cobertura de unit tests (Jest) somada a testes end-to-end (Cypress) é tão consistente que o QA deixou de ser uma posição fixa dentro de cada squad, passando a atuar de forma mais transversal, olhando o produto como um todo. Ela também nota que essa responsabilidade migrou para quem desenvolve a feature: em vez de repassar o comportamento esperado para um QA testar depois, o próprio desenvolvedor já escreve o teste end-to-end assim que termina o código, o que acelera o ciclo inteiro.
"A junção desses dois é muito bom." por Adriana Saty
Adriana traça uma linha clara entre dois cenários parecidos na superfície: um time que assume conscientemente pagar um débito técnico depois — o que é aceitável quando é um combinado, mesmo que o custo seja real — e alguém que promete resolver depois sabendo que não vai, só para entregar mais rápido agora. Na visão dela, quando um desenvolvedor não consegue dizer não a um prazo irreal, o código começa a acumular gambiarra sobre gambiarra até virar um projeto legado que ninguém quer tocar — e os melhores profissionais sempre têm a opção de evitar justamente esses projetos. O segundo caso, segundo ela, tem outro nome.
"Quando está todo mundo prometendo uma coisa mas na verdade é outra não é um débito, é sabotar." por Adriana Saty
"O problema é desenvolvedores bons não querem mexer com o código legado." por Adriana Saty