LigaMagic · CLT · 2023–2025
Circuitos LigaMagic e LigaPokémon
Fui responsável pelo front dos circuitos de torneios da LigaMagic e da LigaPokémon: +2.400 torneios, +150 lojas e +6.000 jogadores na temporada 2024.
- +2.400torneios na temporada 2024
- +150lojas
- +6.000jogadores na temporada
- 2.000+jogadores nos apps em dias de evento
O problema
A LigaMagic é o maior marketplace brasileiro de card games: Magic, Pokémon, Yu-Gi-Oh!, One Piece e outros. Os Circuitos são as ligas de torneios organizadas nas lojas de todo o país, com inscrição, rodadas e ranking.
Quando assumi o front-end, ele estava no início e mal estruturado. Já tinha usuários de verdade: na temporada 2024, os circuitos da LigaMagic e da LigaPokémon somaram mais de 2.400 torneios, em mais de 150 lojas, com mais de 6.000 jogadores. E nos dias de evento, os apps atendem mais de 2.000 jogadores durante os torneios, em eventos com mais de 12.000 pessoas.
Um front frágil nessas condições não é só dívida técnica. Quando algo quebra num dia de evento, há gente esperando na loja.
Havia ainda um segundo desafio: os circuitos derivados de cada card game tinham marcas diferentes. O produto precisava parecer um circuito de Magic num lugar e um de Pokémon em outro, sem duas bases de código.
O que eu fiz
Refatoração da base herdada
Refatorei praticamente toda a base de front que recebi, em Nuxt 3 e Vue 3 com TypeScript. A exceção foi o módulo de cadastro de lojas, onde mexi em partes: refatorei trechos do fluxo de inscrição e de pagamento das lojas, sem assumir o módulo inteiro.
Theming multi-marca
Para as marcas dos circuitos, usei Tailwind com variáveis CSS. As cores e os demais tokens de cada marca ficam em variáveis. Os componentes não conhecem a marca, só os tokens. Trocar de circuito é trocar os valores, e não o código.
Circuito LigaMagic 2024
Inscrever-se/* [data-circuito="magic"] */
--marca: oklch(0.55 0.19 28);
--marca-2: oklch(0.92 0.04 60);
--raio: 6px;
Referência técnica do front
Eu definia padrões e decisões de front e participava de UI/UX, brainstorming e refinamento com o time de produto. Era uma referência técnica do front, sem cargo formal de liderança.
Decisões e trade-offs
Refatorar quase tudo em vez de remendar. Uma base mal estruturada, usada por milhares de jogadores, pedia uma estrutura em que eu pudesse mudar sem medo. O custo é alto: refatorar uma base em uso consome tempo que não vira funcionalidade nova, e cada mudança grande pede cuidado para não quebrar o que já funcionava. Fiz porque a alternativa era empilhar mudanças sobre um terreno instável.
Variáveis CSS em vez de uma folha de estilos por marca. Com uma folha por marca, cada ajuste visual seria feito várias vezes e as marcas se afastariam com o tempo. Com variáveis, o ajuste é feito uma vez, e uma marca nova vira um conjunto de valores. O custo: o sistema de tokens precisa ser bem pensado desde o início. Se um componente embute uma cor fixa, ele quebra o tema.
Não assumir o módulo de cadastro de lojas por inteiro. Mexi nele em partes, como o fluxo de inscrição e pagamento, mas ele não foi refatorado por mim de ponta a ponta. O custo é que algumas partes do front seguiram a organização anterior, fora do padrão que defini no resto.
Resultado
O front sustentou a temporada de 2024 e os dias de evento, com os números acima. Esses números descrevem a escala do produto, e não um ganho que eu atribua só ao meu trabalho.
Não tenho métricas de antes e depois para a refatoração, como quantidade de bugs ou tempo de entrega, e não vou inventar. O que posso dizer: as marcas derivadas passaram a ser tratadas como tema, e não como cópia, e o time passou a ter padrões definidos para trabalhar.
O trabalho foi feito durante o período em que estive na LigaMagic, em regime CLT.
O que eu faria diferente
Mediria desde o início. Se eu tivesse registrado taxa de erros e tempo de entrega antes de refatorar, hoje poderia mostrar o efeito em números.
Combinaria a refatoração com testes de interface nos fluxos críticos, como inscrição e pagamento, antes de mexer neles. Refatorar sem essa rede de segurança exige mais cuidado manual do que deveria.
Documentaria o sistema de tokens do theming logo no começo. A flexibilidade das variáveis só vale se todo mundo no time souber quais tokens existem e quando usar cada um.