Disclaimer
Este texto foi inicialmente concebido pela IA Generativa em função da transcrição de uma live do Dev Eficiente. Se preferir acompanhar por vídeo, é só dar o play.
Introdução
No mundo de desenvolvimento de software, estudar de forma constante é essencial para se manter atualizado e evoluir profissionalmente. Mas você já percebeu como, às vezes, um caminho de estudo planejado pode nos levar a descobertas inesperadas e valiosas? Neste post, vou compartilhar uma experiência recente onde uma pesquisa sobre um problema específico me levou a um repositório repleto de oportunidades de aprendizado.
O Ponto de Partida: A Busca por um Artigo Científico
Tudo começou com um objetivo bem definido: encontrar um artigo científico sobre qualidade de código para criar um vídeo. Decidi buscar algo baseado em pesquisa acadêmica, então acessei o site da International Conference on Software Engineering (ICSE), uma das principais conferências da área.
Ao explorar a conferência de 2025, comecei pela track de Software Engineering Practice, que costuma trazer conteúdos mais aplicáveis ao dia a dia. Entre os vários artigos disponíveis (muitos sobre LLMs), dois chamaram minha atenção inicialmente:
"Automated Code Review in Practice" - que curiosamente mostrava que ferramentas de LLM para revisão de código, em vez de reduzir, aumentaram o tempo gasto nas revisões
"Anomaly Detection in Large Scale Cloud System" - sobre como detectar a chance de uma nova adição no software gerar incidentes de diferentes níveis de criticidade.
Apesar do interesse nesses tópicos, ainda não tinha encontrado algo que realmente me entusiasmasse naquele momento. Foi quando decidi fazer uma busca específica por "Microservice" e encontrei o artigo "Semantic Dependency in Microservice Architecture".
O Problema da Dependência Semântica em Microserviços
Esse artigo abordava um problema crítico enfrentado por empresas que utilizam arquitetura distribuída em larga escala. Empresas como Nubank, Mercado Livre, iFood, Quinto Andar, Uber e Netflix, que possuem centenas ou milhares de microserviços, frequentemente enfrentam não apenas o problema de código duplicado, mas também o de semânticas duplicadas.
A duplicação semântica ocorre quando serviços diferentes executam lógicas que implementam a mesma regra de negócio. Por exemplo, imagine que dentro do iFood existam várias maneiras diferentes de acessar o histórico de pedidos de um cliente. Isso acontece porque, possivelmente, diferentes equipes implementaram funções similares sem saber da existência de soluções já existentes.
Diferente da simples duplicação de código, a duplicação semântica é mais difícil de detectar e pode ser mais problemática. Quando apenas um trecho de código é duplicado para realizar operações distintas, o impacto fica limitado à manutenção. Mas quando há semânticas duplicadas, o significado das operações pode divergir com o tempo, levando a inconsistências nos fluxos de negócio.
A Descoberta Inesperada: Train Ticket
Enquanto estudava o artigo, descobri algo que não estava nos meus planos: os autores mencionavam um dataset de microserviços utilizado para validar a ferramenta que desenvolveram. Entre os projetos desse dataset, estava o "Train Ticket".
Curioso, pesquisei "Train Ticket GitHub" e encontrei um repositório descrito como "Benchmark Microservices System", contendo diversos microserviços implementados (cada um com o prefixo "TS") e utilizando várias tecnologias.
Ao explorar um desses serviços (TS Preserve Service), encontrei um projeto relativamente pequeno, mas organizado em camadas, seguindo padrões comuns de arquitetura. Foi aí que percebi o valor dessa descoberta inesperada: um repositório repleto de exemplos reais que poderiam servir como base para diversos estudos e conteúdos.
Oportunidades de Aprendizado Identificadas
Analisando apenas um dos serviços do repositório, já identifiquei várias oportunidades de estudo e criação de conteúdo:
Discutir se uma arquitetura em camadas usando polimorfismo faz sentido para um microserviço tão pequeno.
Analisar os padrões de log de erro e se estão transmitindo as informações necessárias.
Examinar o acoplamento entre a camada de serviço e o protocolo HTTP (recebendo HTTP headers como parâmetros).
Avaliar o impacto da pressão do protocolo principal no design do código.
Analisar a falta de uso de construtores em algumas classes.
Refatorar o código manualmente seguindo um guideline e guiado pelo CDD vs a mesma atividade guiando um LLM
Verificar oportunidades para criar parâmetros mais semânticos em vez de múltiplos argumentos isolados.
Discutir o uso do RestTemplate para acessar serviços externos e alternativas para tornar o código mais testável.
Avaliar o acoplamento com provedores de mensageria como RabbitMQ.
Conclusão
O que começou como um estudo planejado sobre um tema específico me levou a descobrir um repositório que não conhecia, abrindo portas para múltiplas oportunidades de aprendizado e criação de conteúdo. Essa é uma experiência comum quando nos dedicamos ao estudo: uma exploração pode gerar outras, às vezes até mais valiosas que a original.
É importante estar atento a essas oportunidades que surgem inesperadamente, mas também saber quando recortar e não deixar que elas atrapalhem o fluxo principal de estudo. O equilíbrio está em reconhecer o valor dessas descobertas e, quando apropriado, incorporá-las à jornada de aprendizado.
Jornada Dev + Eficiente
Se você gostou deste conteúdo, conheça a Jornada Dev + Eficiente, nosso treinamento focado em fazer com que você se torne uma pessoa cada vez mais capaz de entregar software que gera valor na ponta final, com máximo de qualidade e eficiência. Acesse https://deveficiente.com/oferta-20-por-cento para conhecer tudo que oferecemos.
Até a próxima!
Top comments (0)