TG

Revisão de código, fluxo de pagamento e fundamentos de TypeScript

Dia de praticar revisão técnica, mapear fluxos de produto e transformar estudo de TypeScript em exercícios mais claros.

O dia foi bem dividido entre revisão, estudo e preparo técnico. Não foi só escrever código. Foi principalmente treinar critério: entender uma mudança, separar risco real de preferência, e transformar perguntas soltas em material reutilizável.

Revisão com contexto

Usei repos de treino para simular revisões de PR com mais disciplina. O foco foi sair do impulso de comentar sintaxe primeiro e olhar a intenção da mudança: arquitetura, contrato da feature, convenções do projeto, risco de rollout e perguntas que ainda precisam de resposta.

Esse tipo de treino ajuda a deixar a revisão mais justa. Nem todo ponto é bug. Algumas coisas são dívida aceitável, outras são escolhas de estilo, e outras merecem bloqueio porque afetam fluxo, estado ou manutenção.

Produto e pagamentos

No itop.com.br, o trabalho ficou em entender e explicar um fluxo de venda de ingresso de ponta a ponta: escolha do ingresso, formulário dinâmico, validação de dados, cupom, pedido, pagamento e atualização visual do estado.

Também apareceu um ponto importante de confiabilidade: idempotência em operações de pagamento. A pergunta prática foi como impedir cobranças duplicadas quando o usuário clica mais de uma vez ou quando a mesma requisição chega de novo. A resposta precisa estar no backend, não apenas no botão desabilitado no frontend.

TypeScript como prática

No typescript-playground, organizei o estudo em níveis: fundamentals, intermediate, advanced e design patterns. A ideia foi deixar o repo mais didático, com exercícios que mostrem técnicas reais em vez de exemplos soltos.

Os temas do dia passaram por emitDeclarationOnly, nullish coalescing, diferença entre ?? e ||, e uso de assertNever para provar exaustividade em switch. Também usei projetos reais como referência para identificar fundamentos de TypeScript aplicados em SDKs e indexers.

Preparo técnico

Parte do dia foi dedicada a transformar material de entrevista e aulas em notas, flashcards e respostas mais curtas. Os detalhes ficam fora do diário público, mas o trabalho técnico foi o mesmo: reduzir ruído, deixar evidências mais claras e praticar como explicar decisões sem perder contexto.

Foi um dia de calibrar leitura técnica. Quanto melhor eu explico o que está acontecendo em um diff, menos eu dependo de improviso na hora de revisar, implementar ou defender uma decisão.