Depois de dois anos como Senior Developer no time de Open Insurance - ajudando a desenhar a Clean Architecture em camadas, levando a cobertura de TDD de 0 até ~90% e tendo liderado a migração o app da empresa de Cordova/WebView pra React Native com 2FA e biometria - o Tech Lead anterior me recomendou pro papel. Como Tech Lead foquei no que mais doía: debuggability contra a reguladora. O breakthrough foi um redesign de logs AWS que fez cada falha rastreável até seu dono real.
Promoção
Dois anos dentro como Senior Developer no time de Open Insurance - o Tech Lead anterior pediu pra liderança me colocar no lugar dele. Ele tinha dúvidas em algumas direções; a recomendação foi espontânea e explícita. Aceitei o papel porque já tinha vivido as dores do time na pele.
O problema mais difícil: de quem é esse bug?
Open Insurance é um ecossistema regulado multi-parte de APIs (SUSEP + Opin Brasil + toda instituição participante). Quando algo falhava, três times apontavam um pro outro. A gente gastava um dia provando que uma quebra de contrato veio de outro banco. Os logs nos davam status code, não contratos.
Redesign dos logs AWS
Reestruturei a emissão no CloudWatch da plataforma inteira: todo body de request inbound, todo request/response de integração outbound, todo callback da reguladora, tudo com correlation ID que atravessa serviços. Campos sensíveis sanitizados. O time ganhou uma única busca pra reconstruir qualquer fluxo end-to-end.
Resultado
Atribuição de bug parou de ser debate - em segundos a gente conseguia mostrar se o shape da resposta recebida de um participante ou da reguladora quebrava o próprio contrato publicado. Tempo de triagem desabou; a credibilidade do time com parceiros SUSEP/Opin subiu.
- Por que logar body completo em vez de só status code?Bodies + correlation IDs, sanitizadoOpen Insurance é governado por contrato. Um 200 OK com campo errado é violação regulatória. Sem o body da resposta não dava pra provar quem quebrou o contrato - nós, a reguladora ou outro banco. Sanitização cuida da parte sensível; o resto é evidência obrigatória.
- Por que React Native pra migração do app (feita como Senior)?React NativeO app era Cordova + WebView, jogando a maior parte da lógica pro site. O time web já era React. RN reusou essa muscle de TypeScript e tooling, compartilhou padrão com o Design System que a gente acabara de construir, e evitou manter fork entre iOS e Android.
- Por que TDD como pré-requisito duro de PR?Teste obrigatório pra dar mergePlataforma regulada de previdência e Open Insurance não pode regressão. O gate força design-for-test desde o primeiro commit e remove a dívida de 'depois eu testo' que sempre acumula - principalmente quando contrato de integração muda sem avisar.
O time ganhou um debugger que finalmente refletiu a realidade regulada do Open Insurance: cada falha rastreável até seu dono real. Triagem de bug saiu de batalha de um dia pra segundos.