Na minha leitura, o problema não é a falta de ferramenta, e sim o hábito de medir adoção pelo que é fácil de mostrar, não pelo que muda de fato. É simples contar licenças, compartilhar prompts e apontar um caso em que a IA produziu um resumo melhor do que a pessoa faria em cinco minutos. O difícil é perceber se isso alterou a forma como o time decide, revisa e coordena o trabalho. E é justamente nessa diferença que a frustração aparece.

IA não falha por falta de capacidade

Um dos erros mais comuns nessa adoção é tratar IA como um atalho de produtividade individual. Ela vira a ferramenta para escrever mais rápido, resumir uma thread longa, gerar um primeiro rascunho de código ou responder um e-mail sem começar do zero. E vale dizer com honestidade: isso ajuda em muitos contextos. O problema começa quando esse ganho localizado é confundido com melhoria real do sistema. Uma pessoa pode produzir um artefato inicial com menos atrito e, ainda assim, o restante do fluxo continuar exigindo o mesmo volume de interpretação, alinhamento, revisão e reconstrução de contexto de antes.

Eu lembro de um PR pequeno que recebeu bastante ajuda da IA na redação do resumo. O texto de abertura ficou melhor, a descrição dos passos ficou mais limpa e até a justificativa da mudança saiu mais organizada. Mesmo assim, o revisor ainda precisou abrir o ticket original, entender dependências que não estavam no PR, checar o impacto na API e voltar duas vezes para pedir esclarecimento sobre uma decisão que o autor tinha tomado no código, mas não no texto. O artefato ficou mais bonito. O fluxo não ficou mais leve.

É por isso que não é raro ver um time ganhar velocidade nas bordas e continuar travado no centro do problema. O PR ainda chega sem contexto suficiente para revisão, a tarefa continua mal definida, o backlog segue ambíguo e a decisão importante ainda depende de alguém parar o que está fazendo, reler histórico disperso, remontar cenário e só então julgar o que deve acontecer. Na minha leitura, a IA não está falhando nesse cenário; ela está apenas adicionando potência a uma operação desalinhada. O resultado parece paradoxal só à primeira vista: algumas partes do trabalho aceleram, mas o caos geral aumenta porque o sistema continua cobrando das pessoas quase o mesmo esforço cognitivo de antes.

O gargalo quase nunca está na tarefa isolada

Boa parte das operações continua apoiada em uma premissa muito antiga: uma pessoa recebe contexto cru, entende a situação, organiza mentalmente o problema, decide o que fazer e executa. Esse padrão aparece em quase todo lugar. Alguém abre um ticket e outra pessoa precisa interpretar o pedido. Alguém sobe um PR e o revisor precisa reconstruir o contexto antes de avaliar a mudança. Alguém levanta uma dúvida e o time para para explicar o que já estava espalhado entre mensagens, documentos, conversas antigas e decisões pouco explicitadas.

Esse modelo funciona enquanto o volume, a ambiguidade e a complexidade cabem dentro do custo cognitivo humano. Quando deixam de caber, ele começa a cobrar caro. O problema, então, já não está apenas na execução da tarefa isolada, mas no trabalho invisível necessário para torná-la decidível. É esse trabalho de interpretação, preparação e coordenação que costuma consumir mais energia do que os times admitem no planejamento.

O ponto que eu considero mais relevante aqui é que IA não altera esse desenho por conta própria. Se ela é adicionada apenas como uma camada a mais sobre o processo existente, tende a virar um assistente sofisticado para o humano continuar carregando o sistema nas costas, talvez com menos atrito em alguns trechos, mas ainda dentro da mesma lógica operacional. É também por isso que tanta adoção parece promissora na demo e decepcionante na rotina. A demo comprime contexto e otimiza um caso isolado para impressionar rápido. A rotina cobra outra coisa: continuidade, handoff, critério de aceite, memória operacional e revisão consistente.

O ganho real aparece antes da execução final

Quando IA começa a fazer diferença de verdade, normalmente não é porque substituiu uma decisão importante, mas porque reduziu o trabalho invisível que acontece antes dela. Esse me parece o ponto mais subestimado da discussão. O principal ganho raramente está em "executar por você" a parte final da tarefa; ele aparece quando a ferramenta prepara melhor o terreno para que a decisão humana aconteça com menos atrito, menos latência e menos desperdício de atenção.

Na prática, isso muda bastante coisa. Um ticket pode chegar já agrupado com demandas relacionadas, riscos percebidos e perguntas em aberto. Um PR pode vir acompanhado de um resumo útil, impacto provável e pontos que merecem atenção. Uma discussão pode começar com contexto consolidado, em vez de obrigar todo mundo a remontar a história manualmente. O efeito disso não é apenas velocidade. O efeito mais importante é que o trabalho deixa de começar do zero toda vez, e isso altera profundamente a experiência operacional do time.

O que eu vejo como mais valioso nesse movimento não é a estética da eficiência, e sim a redução do atrito que normalmente aparece antes da decisão. Em vez de gastar energia para descobrir o que está acontecendo, o time começa mais perto do ponto em que realmente precisa julgar o que fazer. Isso parece um detalhe, mas, na prática, é onde se perde boa parte do tempo em times técnicos.

Esse deslocamento importa porque, em muitos ambientes, o maior custo não está na execução pura, mas na coordenação. Está em preparar contexto, sincronizar entendimento, responder dúvidas recorrentes e depender sempre das mesmas pessoas para explicar, organizar e destravar o que os outros precisam fazer. Quando IA entra nessa camada do problema, o impacto tende a ser mais estrutural, porque ela não está só empurrando uma tarefa mais depressa; está reduzindo o atrito necessário para que o trabalho faça sentido antes mesmo de ser executado.

O erro é pensar em produtividade sem pensar em operação

Se a pergunta for apenas "como usar IA para o time produzir mais", a conversa já começa curta demais. Produzir mais, por si só, não é um objetivo útil. Produzir mais código ruim, mais texto sem contexto ou mais decisões mal preparadas só aumenta o volume de revisão, retrabalho e desalinhamento. A questão relevante não é volume bruto de saída, mas a qualidade do sistema que transforma saída em resultado.

A pergunta mais útil, então, é outra: em que parte do fluxo vale usar IA para reduzir custo de preparação, triagem e coordenação sem aumentar demais o custo de supervisão? Essa formulação muda bastante o enquadramento do problema, porque obriga o time a olhar para o processo como sistema, e não apenas para a tarefa como uma unidade isolada de produção. Obriga também a distinguir com mais clareza o que pode ser processado do que ainda exige julgamento, contexto e responsabilidade humana.

Na minha experiência, quando essa pergunta entra na conversa cedo, o debate fica menos abstrato e mais honesto. O time para de discutir IA como promessa genérica e passa a olhar para a operação real, com suas filas, suas dependências e seus pontos de fricção. E é aí que fica mais evidente que boa parte do ganho vem menos da automação da execução final e mais da automação do caminho até ela. No fim, produtividade real quase nunca nasce de uma ferramenta fazendo tudo sozinha. Ela nasce de um desenho melhor de responsabilidades, em que cada parte do sistema recebe o tipo de trabalho para o qual está mais bem equipada.

O que muda quando o fluxo é redesenhado

O padrão que hoje me parece mais útil é relativamente simples de formular: IA prepara, organiza, resume, classifica e antecipa; humano julga, decide e assume consequência. O valor dessa divisão não está em prometer autonomia total, mas em reposicionar o esforço humano no ponto em que ele realmente agrega valor. Supervisão continua existindo, contexto continua importando e a responsabilidade final não desaparece. O que muda é o tipo de trabalho manual que deixa de consumir tanto tempo.

Em vez de gastar energia montando cenário do zero, a pessoa entra mais perto do momento em que o trabalho realmente ganha valor. Em vez de usar repertório técnico para recuperar histórico disperso, ela usa esse repertório para comparar opções, avaliar risco, perceber consequência e decidir melhor. Esse tipo de redesenho costuma gerar benefícios que aparecem pouco em benchmarks simplificados, mas muito no cotidiano do time: menos fila, menos dependência de contexto oral, menos gargalo em pessoas-chave e menos tempo desperdiçado em trabalho de coordenação que ninguém planeja, mas todo mundo paga.

O efeito que mais me interessa aqui é menos vistoso do que a promessa de autonomia irrestrita, mas mais confiável no dia a dia. Quando a IA assume partes da preparação, do resumo, da triagem e da primeira estrutura, o time deixa de operar só como executor e passa a atuar mais como curador do sistema. Isso melhora a qualidade da decisão sem fingir que a necessidade de julgamento desapareceu, que é exatamente o tipo de promessa que costuma envelhecer mal quando sai da demo e entra na rotina.

Conclusao

No fim, o mito da eficácia instantânea nasce menos da ideia de que IA não funciona e mais da expectativa de que ela deveria gerar ganho real sem exigir mudança de operação. Quando a ferramenta é encaixada em um fluxo ruim, o máximo que ela costuma entregar é velocidade local convivendo com os mesmos gargalos de antes. O trabalho parece mais rápido em alguns pontos, mas continua caro, lento e desgastante onde realmente importa.

Quando o fluxo é redesenhado para que contexto, triagem e preparação deixem de depender tanto de trabalho manual, a história começa a mudar. É nesse momento que a IA deixa de ser apenas um acelerador de tarefas isoladas e passa a influenciar a qualidade da decisão e o ritmo do sistema como um todo. A pergunta prática que eu deixaria, então, é simples: qual parte do seu fluxo ainda está exigindo que pessoas reconstruam contexto à mão, e o que precisa mudar para que a IA pare de ser só um turbo em cima do caos?

Construir agentes autônomos – sistemas de IA capazes de tomar decisões e realizar ações de forma independente – tornou-se mais fácil com a evolução dos LLMs (Modelos de Linguagem de Grande Porte). No ecossistema Python, surgiu recentemente o Strands Agents, um framework open source desenvolvido pela AWS, projetado para simplificar a criação de agentes de IA. O Strands adota uma abordagem orientada por modelos (model-driven approach), aproveitando ao máximo as capacidades de raciocínio dos LLMs modernos para planejar passos, utilizar ferramentas e refletir sobre objetivos, sem que o desenvolvedor precise codificar fluxos complexos de forma explícita . Em poucas linhas de código, podemos definir um agente especificando apenas três elementos fundamentais – um modelo de linguagem, um conjunto de ferramentas e um prompt –, e o Strands se encarrega de orquestrar todo o resto . Diferentemente de frameworks anteriores que exigiam definir workflows complicados, o Strands foi concebido para reduzir a complexidade de orquestração, confiando nas capacidades nativas dos modelos atuais de seguir instruções estruturadas e chamar ferramentas externas .

Neste post, exploraremos os conceitos centrais e a arquitetura interna do Strands Agents de forma didática e técnica, porém acessível mesmo para quem não é especialista em agentes de IA. Abordaremos os princípios de design por trás do framework, seus componentes internos e como ele se posiciona em relação a outras soluções no ecossistema Python. Também veremos exemplos de fluxos de execução típicos de um agente no Strands e ilustrações da arquitetura para esclarecer seu funcionamento.

Conceitos Básicos: Modelo, Ferramentas e Prompt

No coração do Strands está uma definição simples de agente autônomo: um agente é a combinação de um modelo de linguagem, um conjunto de ferramentas e um prompt . Esses três componentes fundamentais formam a base a partir da qual o agente irá operar:

1. Modelo (LLM) – É o cérebro do agente, responsável por raciocinar e gerar ações. O Strands é agnóstico em relação a provedores de modelo: é possível conectar qualquer LLM moderno que suporte uso de ferramentas e streaming, incluindo modelos do Amazon Bedrock, OpenAI, Anthropic (Claude), modelos locais via Ollama ou Llama API, entre outros . A arquitetura de provedores de modelo é extensível, permitindo adicionar facilmente um provedor customizado se necessário. Em resumo, você pode aproveitar o modelo de IA de sua preferência ou necessidade, já que o Strands abstrai as diferenças entre APIs de modelos diferentes.

2. Ferramentas (Tools) – São as interfaces que permitem ao agente interagir com o mundo externo além do modelo. Quando o LLM identifica que precisa realizar uma ação que vai além de sua base de conhecimento (por exemplo, ler um arquivo, fazer uma requisição HTTP, consultar um banco de dados ou executar um cálculo), ele pode invocar uma ferramenta. O Strands inclui suporte nativo a dezenas de ferramentas prontas (built-in), como leitura/gravação de arquivos, busca em documentos, chamadas de API (inclusive integrações prontas com serviços AWS) . Além disso, qualquer função Python pode se tornar uma ferramenta com um simples decorator @tool . O Strands também suporta o protocolo MCP (Model Context Protocol), um padrão aberto que permite usar milhares de ferramentas disponibilizadas como microsserviços externos . Cada ferramenta possui um schema de entrada/saída bem definido – isso possibilita ao framework validar as chamadas e enviar os resultados de volta ao modelo de forma estruturada e segura .

3. Prompt – É a instrução em linguagem natural que define a tarefa ou o papel do agente. Pode incluir um prompt do usuário (a tarefa específica a realizar, pergunta a responder, etc.) e também um prompt de sistema que configura o comportamento desejado do agente (regras, estilo de resposta, objetivos gerais). Essencialmente, o prompt estabelece o que o agente deve fazer ou qual problema deve resolver. No Strands, define-se o prompt de forma declarativa (uma string para o sistema e/ou usuário) e o restante – como garantir que o modelo siga instruções ou retorne no formato esperado – é gerenciado pelo framework. Em agentes complexos, o prompt pode orientar o modelo a planejar passos, usar ferramentas de forma iterativa e até respeitar políticas de segurança (via guardrails, que abordaremos mais adiante).

Ao criar um agente com o Strands, o desenvolvedor instancia um objeto Agent fornecendo esses três componentes. Por exemplo, podemos definir um agente com uma lista de ferramentas e um prompt, e opcionalmente escolher um modelo (caso contrário, um modelo padrão do Bedrock pode ser usado, se disponível) . Com uma configuração mínima, o agente já está pronto para ser executado localmente ou em produção.

O Agent Loop: Raciocínio e Ação em Ciclo

Um diferencial central do Strands está na implementação do chamado agentic loop, ou loop do agente – o mecanismo cíclico que permite ao agente alternar entre pensar (reasoning) e agir (acting) até chegar a uma solução. Em termos simples, “um modelo de linguagem pode responder a perguntas. Um agente pode fazer coisas” – e é o loop de agente que viabiliza essa diferença .

Como funciona? O loop do agente executa as seguintes etapas repetidamente: o Strands invoca o modelo com o prompt e o contexto atual; o modelo analisa o problema e decide se precisa usar alguma ferramenta; se sim, o framework executa a ferramenta solicitada e retorna o resultado ao modelo, acrescentando essa informação ao contexto; o modelo então reconsidera a situação com o novo dado e pode decidir por outra ação ou por encerrar o ciclo com uma resposta final . Esse ciclo de pensar -> agir -> pensar… se repete quantas vezes forem necessárias até o agente concluir a tarefa ou atingir algum critério de parada.

Fluxo simplificado do loop de um agente Strands: o modelo (LLM) alterna entre fases de raciocínio e execução de ferramentas até produzir uma resposta final. Cada iteração adiciona ao histórico de conversação, enriquecendo o contexto para as próximas decisões.

No diagrama acima (adaptado da documentação oficial), vemos o fluxo típico de execução: o agente recebe uma entrada (o prompt do usuário, possivelmente acompanhado de contexto adicional ou memória pregressa) e inicia o Loop. Dentro desse loop, o modelo LLM gera um pensamento ou intenção com base no contexto; em seguida, há uma etapa de escolha de ferramenta, em que o modelo indica querer usar uma ferramenta específica; a ferramenta é então executada pelo framework, e o resultado retorna para a entrada do modelo, fechando o ciclo. O loop continua até que o modelo decida que já possui informação suficiente para responder e produz a resposta final .

O poder desse padrão está na acumulação de contexto: a cada iteração, o histórico de conversação do agente é enriquecido com novas mensagens – incluindo as ações tomadas e os resultados obtidos – o que permite ao modelo lidar com tarefas de múltiplas etapas de forma coerente . Por exemplo, considere uma tarefa de análise de vulnerabilidades em um repositório de código. O agente pode começar pedindo uma listagem de arquivos (ferramenta de diretório), depois ler certos arquivos fonte (ferramenta de leitura), identificar padrões suspeitos e fazer buscas específicas no código (ferramenta de busca em texto), acumulando achados ao longo do caminho. Em cada passo, o modelo vê não apenas o pedido original, mas também todas as ações e resultados anteriores, permitindo um raciocínio cada vez mais informado até chegar a uma conclusão final .

Alguns detalhes importantes desse loop de agente no Strands:

• Mensagens e Histórico: O Strands estrutura a comunicação em mensagens do usuário e mensagens do assistente (agente). Mensagens de usuário incluem tanto consultas do usuário quanto resultados de ferramentas (que são inseridos como se fossem mensagens de usuário para que o modelo as veja), enquanto mensagens do assistente incluem as respostas do LLM e também instruções de uso de ferramenta quando o modelo opta por agir . Toda iteração adiciona mensagens ao histórico, funcionando como a memória de curto prazo do agente. O framework oferece gerenciadores de conversação (Conversation Managers) para evitar que esse histórico exceda os limites de contexto do modelo – por exemplo, estratégias de janela deslizante ou sumarização automática dos trechos mais antigos, mantendo apenas os pontos relevantes .

• Execução de Ferramentas Segura: Quando o modelo decide usar uma ferramenta, o Strands cuida de todo o processo de validação, execução e tratamento de erros. Ele verifica se os parâmetros fornecidos pelo modelo batem com o esquema esperado da ferramenta, executa a ação (por exemplo, chama a função Python ou serviço correspondente) e encapsula o resultado em uma mensagem de retorno para o modelo . Se ocorrer um erro na ferramenta (ex: exceção, falha de rede), isso não encerra o loop imediatamente; em vez disso, o erro é capturado e devolvido ao modelo como um resultado de ferramenta indicando falha, permitindo que o agente tente se recuperar ou tome outra ação ao invés de simplesmente abortar . Esse mecanismo torna o agente mais robusto, já que o LLM pode aprender com falhas de ferramenta e decidir um plano B (por exemplo, tentar uma ferramenta alternativa ou ajustar a consulta).

• Critérios de Parada: Cada chamada ao modelo retorna junto com um código de parada (stop reason) indicando o porquê daquela iteração ter terminado. Os cenários incluem: turno concluído (o modelo finalizou sua resposta sem solicitar novas ações, indicando término bem-sucedido do loop), uso de ferramenta (o modelo pediu uma ou mais ferramentas – o loop continuará após executá-las), limite de tokens atingido (o modelo bateu no teto de tokens e não pôde continuar – caso de erro irrecuperável dentro daquele ciclo), sequência de parada configurada encontrada (um sinal predefinido para encerrar a resposta, tratado como término normal), ou intervenção de segurança (conteúdo bloqueado por filtros ou guardrails) . O Strands trata gracefully os casos de término por segurança, garantindo que o loop pare e retorne controle à aplicação conforme a política definida.

• Extensibilidade via Hooks: O loop em si é genérico, mas o Strands emite eventos de ciclo de vida em pontos-chave – antes/depois de cada iteração, antes/depois de cada chamada de modelo, antes/depois de cada execução de ferramenta, etc. Através de hooks, podemos observar ou até modificar o comportamento do agente nesses pontos sem precisar alterar o núcleo do loop . Isso é útil para telemetria, logging, métricas e customizações. Por exemplo, poderíamos logar cada ferramenta usada e seu resultado, ou medir o tempo de cada iteração, ou inserir lógica adicional antes de certas ferramentas serem executadas. Esses mecanismos de extensão refletem um princípio de design importante: manter o núcleo simples, mas permitir integrações e ajustes customizados quando necessário (ver seção de Observabilidade).

Em resumo, o agent loop do Strands encapsula o padrão de raciocinar e agir iterativamente (ReAct loop ) de forma confiável e transparente para o desenvolvedor. Graças a melhorias recentes nos LLMs – que hoje já entendem nativamente instruções de uso de ferramentas e podem gerar formatos estruturados como JSON – o Strands evita orquestrações manuais excessivamente complexas. O modelo de IA está no volante do agente, enquanto o framework fornece os pedais e câmbio automáticos para que o trajeto ocorra sem sobressaltos.

Estado, Memória e Gerência de Sessão

Agentes autônomos efetivos precisam gerenciar o contexto ao longo da interação, e o Strands provê componentes para isso através de estado do agente e gerência de sessão. Embora o loop descrito acima seja muitas vezes transiente (processa uma única tarefa até conclusão), em aplicações reais é comum querermos persistir informações de uma execução para outra, ou manter um histórico consolidado de várias conversas.

• Estado do Agente: Em Strands, o estado refere-se aos dados mantidos entre iterações do loop e inclui coisas como o histórico de mensagens, variáveis internas ou qualquer artefato gerado que deva ser carregado adiante . O estado é encapsulado em objetos de classe State ou similares, permitindo salvar e restaurar se necessário. Por exemplo, se um agente é interrompido ou se precisamos mover a execução dele para outro ambiente, podemos serializar seu estado (histórico, memória de ferramenta, etc.) e depois reconstruí-lo, continuando de onde parou.

• Gerenciadores de Conversa (Conversation Managers): Conforme mencionado, o Strands oferece diferentes estratégias para limitar o tamanho do histórico de mensagens dentro da janela de contexto do modelo. Dependendo do modelo escolhido, o contexto completo (instruções + histórico) só pode ter um número limitado de tokens. O Strands implementa gestores como janela deslizante (mantém apenas as N mensagens mais recentes ou até X tokens) , resumo dinâmico (condensa partes antigas em um sumário para liberar espaço) ou até abordagens híbridas. O desenvolvedor pode escolher um gerenciador adequado ou implementar um próprio, conforme a natureza da aplicação (p. ex., para um agente conversacional que deve lembrar de todo o histórico do dia, pode-se usar sumarização, enquanto para um agente de tarefa única talvez não precise mais que uma janela curta).

• Sessões e Memória Persistente: O Strands foi pensado para uso production-ready, e isso implica suportar múltiplas sessões de agentes e armazenamento de memória persistente. Ele fornece abstrações de Session Manager – por exemplo, existem implementações prontas que utilizam arquivos locais, Amazon S3 ou Redis para armazenar o histórico e estado de cada sessão . Assim, um agente implantado em produção pode manter contexto de usuário entre diferentes execuções ou requisições, possibilitando continuidade (um caso de uso comum é um agente em um chatbot que “lembra” conversas anteriores do mesmo usuário). Essa organização interna de sessão também facilita escalabilidade: várias instâncias do agente podem compartilhar um repositório de sessão comum, garantindo consistência do estado mesmo se o agente for executado distribuídamente (ex: em múltiplas Lambdas ou pods Kubernetes).

Em suma, o Strands separa bem a lógica de raciocínio (loop de agente) da lógica de memória e persistência, oferecendo componentes plugáveis para gerenciar o estado conversacional. Isso reflete um princípio de projeto importante: flexibilidade na gerência de dados, permitindo adequar o framework a diferentes requisitos de aplicação (desde protótipos locais até sistemas distribuídos com milhares de usuários).

Ferramentas: Conectando o Agente ao Mundo Externo

Um dos aspectos mais práticos (e poderosos) de agentes de IA é a capacidade de usar ferramentas para realizar ações. No Strands, o design das ferramentas merece destaque pelos seguintes motivos:

Abordagem Declarativa e Orientada a Schema: Cada ferramenta em Strands é definida por:

• um nome e descrição (que serão usados para apresentar a ferramenta ao LLM no prompt),

• uma assinatura de função ou esquema de parâmetros de entrada e saída,

• uma implementação de função (no caso de ferramentas locais em Python) ou um endpoint/protocolo (no caso de ferramentas remotas via MCP).

Essa definição clara permite que o Strands automaticamente documente as ferramentas para o modelo e valide as chamadas. Quando um agente inicia, o framework concatena as descrições das ferramentas disponíveis em um formato que o modelo consiga entender (por exemplo, usando formato function calling do OpenAI ou instruções textuais estruturadas) . Assim, o LLM sabe quais ações estão ao seu dispor e como utilizá-las. Ao receber uma saída do modelo indicando intenção de ferramenta, o Strands analisa (tipicamente em JSON) qual ferramenta foi escolhida e com quais argumentos, confere se bate com o esquema declarado e só então executa a chamada . Essa intermediação é crucial para manter segurança e consistência, evitando que uma resposta malformada do modelo que pareça uma chamada de ferramenta quebre o fluxo.

Decorators e Ferramentas Personalizadas: Transformar funções Python em ferramentas é trivial com o decorador @tool fornecido pelo SDK . Por exemplo, suponha que temos uma função Python def traduzir(texto: str, idioma: str) -> str para traduzir texto usando alguma API; ao marcar com @tool, podemos adicionar essa função à lista de ferramentas do agente. O Strands inspeciona a assinatura (parâmetros texto e idioma e retorno str) e monta automaticamente o esquema e a documentação para o modelo. Isso incentiva um design limpo: a lógica de cada ação fica isolada em funções reutilizáveis, enquanto o agente LLM apenas orquestra quais ações chamar e em que sequência.

MCP e Ferramentas Distribuídas: O Model Context Protocol (MCP) merece menção especial. É um protocolo aberto que padroniza como servers de ferramentas podem registrar quais ações oferecem e como um agente pode consultá-los. O Strands integra-se profundamente a esse padrão, o que significa que seu agente pode facilmente consumir ferramentas servidas externamente (por exemplo, uma API REST que cumpre o protocolo MCP pode ser chamada como ferramenta). A AWS e a comunidade disponibilizam “servidores MCP” para diversas utilidades – um dos exemplos citados é um servidor com mais de 6.000 ferramentas internas na Amazon, que um agente pode consultar semanticamente para descobrir qual ferramenta é relevante para sua tarefa . Evidentemente, um LLM não consegue avaliar diretamente uma lista de 6 mil opções, então a estratégia usada é ter uma ferramenta retrieval que busca no conhecimento base a descrição de ferramentas relevantes e apresenta apenas um subconjunto manejável para o modelo . Este é um padrão habilitado pelo Strands: ferramentas para encontrar ferramentas, demonstrando a flexibilidade do conceito.

Execução Paralela e Sequencial: O Strands permite que um modelo peça uma ou várias ferramentas de uma vez numa mesma iteração . Se o modelo suportar retornar múltiplas chamadas (por exemplo, planejar “faça X e Y” juntas), o framework pode lidar com isso. Existe inclusive uma abstração de Executors para controlar se as ferramentas devem rodar sequencialmente ou em paralelo . Por padrão, as ferramentas requisitadas em um mesmo passo são executadas sequencialmente na ordem retornada pelo modelo (pois às vezes a saída de uma ferramenta pode ser insumo para a próxima). Porém, em casos onde as ações são independentes, um executor concorrente pode acelerar o processo executando múltiplas ferramentas simultaneamente, agregando os resultados ao final para devolver ao modelo. Essa capacidade é valiosa em cenários de agentes que precisam realizar várias consultas externas ao mesmo tempo (por exemplo, coletar dados de diferentes fontes em paralelo).

Falhas e Segurança: Conforme mencionado, se uma ferramenta falha, o Strands captura a exceção e a devolve como resultado de erro para o modelo . Além disso, o Strands permite configurar limites de tempo (timeouts) para ferramentas ou outras salvaguardas, para evitar que uma ação demorada trave o agente indefinidamente. Em ambientes de produção, é possível isolar a execução de ferramentas em sandboxes ou serviços separados (ver próxima seção de Arquiteturas de Produção) para aumentar a segurança – por exemplo, rodar código potencialmente perigoso (como uma ferramenta que executa comandos do sistema) em um ambiente controlado.

Resumindo, o subsistema de ferramentas do Strands é projetado com modularidade e robustez em mente. As ferramentas são cidadãs de primeira classe no design do agente – são fáceis de adicionar, têm contratos claros e o agente consegue decidir de forma autônoma quando e como usá-las. Esse design reflete um princípio fundamental: capacitar o modelo a agir, fornecendo-lhe os meios (ferramentas) e cuidando dos detalhes para que cada ação seja realizada com segurança e retorno adequado de informações .

Padrões Multiagente e Colaboração de Agentes

Embora muitos casos de uso possam ser atendidos com um único agente equipado com ferramentas, o Strands foi concebido desde o início para suportar também sistemas com múltiplos agentes cooperando. A própria AWS e comunidade têm explorado “multi-agent systems” para tarefas complexas, e o Strands oferece primitivas simples para composições como Agents-as-Tools, Swarms e Graphs . Vamos entender o que significam esses padrões e como o framework os implementa:

• Agent-as-Tool (Agentes como Ferramentas): É o padrão análogo ao modelo orquestrador e especialistas. Um agente pode ser encapsulado como uma ferramenta e disponibilizado para outro agente utilizá-lo quando necessário . Por exemplo, podemos ter um agente “pesquisador” configurado com habilidades de buscar dados e outro agente “matemático” capaz de fazer cálculos; então um agente principal “orquestrador” pode chamar o pesquisador ou matemático como se fossem ferramentas, delegando sub-tarefas a eles . Internamente, o Strands torna isso fácil: basta instanciar o agente especializado e decorá-lo como @tool (ou usar a classe utilitária de Agents-as-Tools). Quando o orquestrador invoca essa ferramenta, o framework dispara o loop do agente especializado em background e captura seu resultado . O resultado retorna então ao orquestrador como se fosse a saída de uma ferramenta comum. Esse padrão cria uma hierarquia clara e é útil para dividir responsabilidades por domínio (um agente para cada expertise).

• Swarm (Enxame de Agentes): No padrão swarm, não há um orquestrador central – diversos agentes operam em paralelo e comunicam-se entre si diretamente, formando uma rede cooperativa . Isso é útil para exploração de ideias, brainstorming ou problemas em que múltiplos pontos de vista e colaboração peer-to-peer podem levar a uma solução melhor . Por exemplo, você pode ter três agentes “iguais” discutindo entre si para chegar a um consenso: cada um lê as mensagens dos outros e contribui com sua parcela. O Strands suporta esse esquema através de ferramentas de comunicação e estrutura de graph (grafo) de agentes. Existe uma ferramenta agent_graph que facilita configurar uma topologia de rede entre agentes (por exemplo, todos conectados a todos, ou um determinado padrão de mensagens) . Os agentes em um swarm podem rodar cada um em sua thread ou processo separado, e o Strands cuida de encaminhar as mensagens conforme a topologia definida . Cabe ao desenvolvedor definir a política de interação: pode ser colaborativa (agentes constroem juntos a resposta, compartilhando achados) ou competitiva (agentes tentam soluções independentes e comparam resultados, até mesmo criticando uns aos outros) – o framework é flexível para implementar qualquer lógica de coordenação desejada, já que expõe hooks e a estrutura de comunicação, mas não engessa o conteúdo das mensagens.

• Graph e Workflow (Fluxos Orquestrados): Além dos swarms mais livres, o Strands facilita compor agentes em estruturas de grafo ou fluxo determinístico. No caso de um workflow, imagina-se uma sequência pré-definida de etapas, onde cada etapa é desempenhada por um agente diferente ou pelo mesmo agente com papéis distintos. Por exemplo, um fluxo de atendimento ao cliente poderia ter um agente que primeiro coleta informações, depois passa para outro agente que faz análise, e por fim outro que gera um relatório. Já um graph mais genérico permite ramificações e junções – similar a um fluxo, mas não precisa ser linear. O Strands fornece utilitários para montar esses gráficos: você pode declarar que a saída do Agente A vai para o B e C, depois suas saídas convergem para D, etc. As primitivas internas para isso incluem o uso do agent_graph mencionado e possivelmente uma classe de Workflow ou GraphTool que o SDK disponibiliza . Inclusive, a documentação do Strands traz exemplos de Cyclic Graph e Agents Workflow mostrando como implementar tais padrões (ex.: um grafo cíclico onde agentes podem retroalimentar informações até convergência) .

• Agent2Agent (A2A) Protocol: Para cenários em que agentes rodam não apenas em processos distintos mas potencialmente em máquinas diferentes ou linguagens diferentes, o Strands adotou o protocolo A2A (Agent-to-Agent). O A2A é um padrão aberto que define como agentes de IA podem descobrir uns aos outros, trocar mensagens e colaborar via rede . No Strands, é possível levantar um servidor A2A (baseado em FastAPI/Starlette) que expõe um agente na rede como serviço, e outros agentes podem usar um cliente A2A para se conectar a ele . Em essência, isso generaliza o Agents-as-Tools para o contexto distribuído: em vez de importar um agente Python local como ferramenta, você pode tratar um agente remoto como ferramenta via A2A. O Strands já traz implementações e exemplos de servidor e cliente A2A, tornando relativamente simples criar microserviços de agentes que falam entre si. Esse recurso foi anunciado como novidade em evolução na época do lançamento , reforçando o compromisso do Strands com padrões abertos e interoperabilidade.

Naturalmente, a escolha de usar múltiplos agentes traz complexidade adicional, mas o Strands se esforça para fornecer “primitivas simples para multi-agente” . O desenvolvedor não precisa construir do zero protocolos de comunicação ou gerenciar threads manualmente – o framework provê os blocos básicos, mantendo a filosofia “just-enough orchestration” (orquestração na medida certa) . Isso posiciona o Strands como um dos primeiros frameworks a dar suporte integrado e estruturado para sistemas multiagente no ecossistema Python, indo além do modelo tradicional de agente único isolado.

Arquitetura Interna e Princípios de Design

Tendo passado pelos conceitos e padrões que o Strands habilita, vamos olhar “por baixo do capô” para entender a arquitetura interna e as decisões de projeto que tornam tudo isso possível. Como um framework pensado para produção, vários princípios nortearam seu design:

1. Minimalismo Orquestrador: O Strands foi concebido de forma leve (lightweight) – ele atua principalmente como um orquestrador entre o LLM e as ferramentas, introduzindo o mínimo de camadas necessário . Isso contrasta com frameworks mais antigos que impunham arquiteturas elaboradas e workflows fixos. No Strands, se você inspecionar o código (disponível no GitHub), verá que a classe central Agent engloba um loop genérico e utiliza componentes plugáveis para decisões especializadas (como escolha de ferramenta, gestão de memória, etc.). Ao aproveitar que os LLMs modernos já conseguem “planejar, encadear pensamentos e usar ferramentas” nativamente , o core do Strands permanece enxuto – ele não tenta adivinhar a estratégia do agente, apenas facilita o modelo a executar sua estratégia. Essa filosofia se traduz em menos overhead e mais flexibilidade para o desenvolvedor moldar o agente conforme a necessidade.

2. Componentização e Extensibilidade: A estrutura interna do Strands é altamente modular. Há componentes dedicados para:

• Loop/Event Loop: Gerencia chamadas ao modelo e coordena ferramentas (núcleo da classe Agent e EventLoop) .

• Conversação/Memória: Classes para ConversationManager, que implementam políticas de janela de contexto (SlidingWindow, Summarizing, etc.) , e SessionManagers para persistência (FileSession, S3Session, etc.) .

• Modelo/Providers: Abstrações para diferentes LLMs (classes OpenAI, Bedrock, Anthropic, etc., todas derivando de uma interface comum) .

• Ferramentas/Tools: Mecanismos para registrar e descobrir ferramentas (ToolRegistry), decoradores e schemas (tools.Decorator e Tool base) , executores concorrentes vs sequenciais , além de protocolos como MCP.

• Multiagente: Classes para Swarm, Graph e Workflow, bem como servidor e cliente A2A (por exemplo, AgentGraph, Swarm, A2AServer, etc.) .

• Observabilidade: Integracão com OpenTelemetry (módulo Telemetry com Tracer, Metrics etc.) .

• Segurança: Suporte a guardrails, filtragem de conteúdo e redação de PII (módulos em Safety & Security).

Cada parte acima é projetada para ser substituível ou configurável. Por exemplo, se quisermos usar um método customizado de resumir conversas, podemos criar nossa própria classe herdando de ConversationManager. Ou se quisermos conectar um modelo incomum, implementamos a interface de Model para ele. Essa arquitetura baseada em interfaces e classes de base é típica de frameworks Python bem desenhados, permitindo que o Strands atenda a casos de uso variados sem forçar um one-size-fits-all. Em resumo, a organização interna se parece a uma caixa de ferramentas bem compartimentada, onde o Agent junta as peças, mas cada peça pode ser examinada e trocada.

3. Integração Nativa com AWS (mas não limitada a ela): Por ser criado pela AWS, não surpreende que o Strands tenha integração suave com serviços AWS – por exemplo, Amazon Bedrock (serviço que hospeda modelos como Claude, Titan etc.) pode ser usado como provedor de modelos facilmente , e o AgentCore do Bedrock (um runtime gerenciado para agentes) é suportado nativamente para implantação. Há ferramentas pré-construídas para interagir com serviços AWS (como Amazon S3, DynamoDB, AWS Lambda, etc.) , facilitando criar agentes que automatizam tarefas na nuvem. Além disso, o projeto fornece blueprints de implantação em AWS (ex.: modelos de Lambda, Fargate, EKS, EC2 para rodar agentes) . Entretanto, é importante notar: o Strands é 100% open source (Apache 2.0) e multi-plataforma. Você pode executá-lo localmente ou em qualquer infraestrutura, e usar modelos de outros fornecedores (OpenAI, Cohere, ou modelos open-source locais) sem nenhum impedimento . Essa posição é estratégica: a AWS o propõe como um padrão aberto para agentes de IA, com suporte da comunidade (Meta, Anthropic, Accenture e outros já contribuíram com integrações ). Ou seja, é um projeto de comunidade, não um serviço proprietário – mas claramente é também parte da visão da AWS de promover Agentic AI de forma enterprise.

4. Observabilidade e Produtização: Um dos lemas do Strands é ser “pronto para produção” (production-ready). Isso se reflete em recursos robustos de observabilidade, como integração com OpenTelemetry (OTEL) para métricas, logs e tracing . Cada agente pode emitir métricas personalizadas (quantidade de iterações, ferramentas usadas, tempo de resposta, etc.) e rastrear as chamadas através de componentes distribuídos com traces correlacionados . Por exemplo, se um agente orquestrador aciona dois agentes especialistas em microserviços distintos, o Strands pode propagar um ID de trace para cada requisição, possibilitando visualizar numa ferramenta de monitoring todo o percurso daquela tarefa entre os serviços – algo essencial para depurar e otimizar sistemas complexos. Além disso, o Strands traz um SDK de avaliações (Strands Evals) com utilitários para avaliar desempenho de agentes (métricas como sucesso de objetivo, precisão de seleção de ferramenta, etc., listadas em sua documentação) . Isso demonstra a preocupação em não apenas construir agentes, mas também medir e melhorar eles continuamente em produção. Em termos de design, poucas soluções de agentes até então incorporavam observability de forma tão direta – aqui é um componente de primeira classe.

5. Segurança e Governança: Por fim, mas crucial, estão os recursos de segurança integrados. O Strands suporta plug-ins de conteúdo seguro e compliance, incluindo:

• Filtros de conteúdo indesejado ou sensível: Utilizando possivelmente modelos de detecção ou serviços externos, o agente pode bloquear ou alterar respostas que contenham informações proibidas (ex.: linguagem tóxica, vazamento de dados confidenciais).

• Guardrails (trilhos de segurança): Integra-se com Bedrock Guardrails ou políticas definidas para intervir se o agente estiver saindo do escopo ou violando alguma regra . Por exemplo, se o modelo tentar gerar código malicioso ou revelar segredos, um guardrail pode interromper a geração.

• Mascaramento de PII: Ferramentas automáticas para identificar e remover informações pessoais identificáveis de entradas/saídas, protegendo privacidade (na documentação há referência a PII Redaction).

• Autenticação de Ferramentas: Em cenários empresariais, ferramentas que acessam sistemas sensíveis (como bancos de dados internos) podem exigir credenciais; o Strands incentiva boas práticas de gerenciar chaves de API, tokens (como no exemplo do GitHub token para a ferramenta de verificação de domínio ), e permite integrar com sistemas de segredos da AWS (Secrets Manager, etc.).

Esses aspectos fazem parte do ethos de “enterprise-ready”, mencionado nos materiais do Strands: agentes autônomos porém “seguros por design” . Em outras palavras, não basta que o agente funcione; ele deve funcionar de forma governável, rastreável e segura para atender aos requisitos de aplicações reais nas empresas.

Posicionamento no Ecossistema Python

O surgimento do Strands Agents ocorre num momento de efervescência em torno de agentes de IA e ferramentas como o LangChain, GPT-Engineers, AutoGPT e outros experimentos. Cada uma dessas soluções ataca o problema à sua maneira, e é importante entender onde o Strands se encaixa nesse panorama:

• Comparado ao LangChain e similares: LangChain ganhou popularidade ao oferecer uma forma de encadear prompts e integrar ferramentas em aplicações de LLM, incluindo agentes baseados no padrão ReAct. No entanto, LangChain é bastante genérico e muitas vezes demanda que o desenvolvedor configure explicitamente cadeias de chamadas, parse de saída do modelo, etc. O Strands, por sua vez, assume uma filosofia quase oposta: em vez de o desenvolvedor orquestrar a lógica passo a passo, o modelo de IA é que orquestra, e o framework apenas dá o suporte (memória, ferramentas, execução) para que isso ocorra de modo confiável . Isso simplifica o desenvolvimento – como diz a apresentação, “basta definir um prompt e uma lista de ferramentas” que o Strands cuida do resto – mas ao mesmo tempo exige modelos capazes nessa função. Assim, podemos ver o Strands mais como um nível de abstração acima: ele se apoia em melhorias dos LLMs (ex.: capacidade de function calling) para evitar escrever código de parsing, loops manualmente. Em termos de código Python, Strands tende a ser mais declarativo e menos imperativo que LangChain.

• Integração com o ecossistema AWS e open-source: Um ponto de destaque é que o Strands vem respaldado pela AWS, o que o torna atraente para desenvolvedores já atuando nesse ecossistema. Por exemplo, se você quer levar seu protótipo de agente para produção na AWS, o Strands já provê modelos de implantação (Lambda, contêineres) e compatibilidade com serviços gerenciados (Bedrock, etc.) . Nenhum outro framework de agentes no Python até o momento oferece essa “mão na roda” tão pronta para deploy. Ao mesmo tempo, por ser open-source e ter um GitHub ativo, ele busca envolver a comunidade de forma mais aberta do que soluções puramente proprietárias. Empresas e indivíduos podem contribuir com pull requests, adicionar conectores para novos LLMs ou criar pacotes de ferramentas comunitárias (e isso já está acontecendo, vide contribuições da Anthropic, Meta, etc. para suporte às APIs deles ). Em suma, o Strands tenta unir o melhor dos dois mundos: robustez de empresa grande + abertura da comunidade.

• Casos de Uso Alvo: Pelo posicionamento do projeto, fica claro que o Strands mira tanto assistentes conversacionais complexos (por exemplo, um ajudante de desenvolvedor como o Amazon Q que motivou sua criação ) quanto agentes de automação de tarefas em TI e negócios (como analisar logs, gerenciar infraestrutura – há menções de uso no AWS Glue, VPC Reachability Analyzer ). Ou seja, muito além de responder perguntas, a ideia é habilitar agentes que realmente executem fluxos de trabalho e economizem tempo humano em operações. Isso o distingue de bibliotecas focadas apenas em chatbots simples. Dentro do ecossistema Python, o Strands também dialoga com projetos de Autonomous AI Agents que surgiram pós-GPT-4 (Auto-GPT, BabyAGI etc.), mas esses projetos eram mais demonstrações pontuais. O Strands busca ser uma base consolidada e de longo prazo para desenvolver tais agentes com qualidade de software industrial.

Em resumo, o Strands Agents se posiciona como o framework de referência da AWS para agentes LLM – leve, flexível, integrável e pensado para escalar. Ele não invalida o uso de outras bibliotecas (inclusive pode ser usado em conjunto, por exemplo, utilizando LangChain para gerenciar documentos mas Strands para orquestrar agentes, se alguém quiser), mas certamente traz uma proposta de design mais coesa para agentes autônomos em Python. Para quem já está no ecossistema Python de IA, vale a pena acompanhar e experimentar o Strands, pois ele representa uma evolução das lições aprendidas ao longo de 2023 na construção de agentes – incorporando essas lições em um pacote bem arquitetado.

Conclusão

O Strands Agents exemplifica como projetos de código aberto podem elevar o nível de abstração no desenvolvimento de sistemas de IA. Ao invés de reinvertermos a roda a cada novo agente, ele fornece um framework sólido que cuida da base: um loop de agente confiável, integração transparente com modelos e ferramentas, memória gerenciada, padrões multiagente e toda infraestrutura de observabilidade e segurança necessária para implantar agentes no mundo real. A metáfora no nome “Strands” (fios/fitas) remete às duas peças-chave que ele conecta – modelo e ferramentas – como as duas fitas do DNA . E de fato, o DNA deste framework é permitir que modelos de linguagem façam mais do que conversar: que possam agir.

Para a comunidade Python, especialmente desenvolvedores interessados em Agentic AI, o Strands chega para ocupar um espaço importante. Com ele, pode-se ir do protótipo à produção em questão de dias ou semanas, ao invés de meses , graças às decisões de projeto que simplificam a vida do desenvolvedor (aproveitando o que os modelos já conseguem fazer) e ao mesmo tempo fornecem os ganchos necessários para casos avançados.

Estou criando alguns agentes usando o framework e em breve posto mais sobre a minha experiência e meus aprendizados.

Na maior parte das vezes, a resposta vem acompanhada de um diagrama conhecido: dois bancos, uma seta indo para a direita, outra voltando, talvez uma réplica de leitura, talvez uma fila no meio. Em algum momento alguém menciona performance, escalabilidade ou “preparar o sistema para o futuro”.

O problema é simples: isso não é CQRS.

Isso é infraestrutura. E quando infraestrutura vira argumento arquitetural, o sistema começa a tomar decisões erradas com muita convicção.

CQRS não nasceu para escalar banco. Nasceu para organizar pensamento, reduzir ambiguidade e forçar clareza onde normalmente existe acoplamento disfarçado.

O erro coletivo

O erro mais comum — e mais caro — é achar que CQRS é sobre separar tabelas, schemas ou instâncias de banco. Essa separação pode acontecer, mas ela nunca deveria ser o ponto de partida.

Quando a discussão começa pelo banco, ela já começou tarde demais.

CQRS não separa dados.
CQRS separa responsabilidades semânticas.

Ele parte de uma pergunta simples, mas profundamente incômoda:
escrever e ler são realmente o mesmo problema?

Em sistemas pequenos, geralmente são. Em sistemas que cresceram, raramente continuam sendo. A partir do momento em que leitura e escrita têm ritmos diferentes, expectativas diferentes e consumidores diferentes, tratá-las como a mesma coisa vira uma forma silenciosa de dívida técnica.

O que CQRS realmente separa

CQRS significa Command Query Responsibility Segregation. O nome é direto, mas frequentemente ignorado em favor de implementações “criativas”.

• Commands existem para mudar estado

• Queries existem para responder perguntas

Até aqui, nada revolucionário. O detalhe está no que isso implica.

Um Command não retorna dados relevantes. Ele retorna sucesso ou falha. Ele representa uma intenção explícita de mudança e carrega consigo regras, validações e invariantes. Uma Query, por outro lado, observa o estado atual e responde algo útil para quem perguntou.

Essa separação não é técnica. É conceitual.

Ela pode existir:

• no mesmo processo

• na mesma aplicação

• no mesmo banco

CQRS não exige microservices, event sourcing ou mensageria. Ele exige algo mais difícil: disciplina conceitual. Se você começou separando infraestrutura, provavelmente terminou sem separar responsabilidades.

Escrita como contrato

Aqui está o ponto que costuma separar times maduros de times apenas ocupados.

Um Command não é um DTO que salva algo no banco.
Um Command é um contrato.

Quando um sistema aceita um Command, ele está afirmando algo muito específico:

“Se essas condições forem verdadeiras, eu prometo que este estado será alterado.”

Isso implica validação explícita, regras claras e invariantes protegidas. Commands carregam intenção, não estrutura. Eles dizem o que o sistema aceita fazer, não como os dados serão persistidos.

Quando Commands viram apenas métodos com nomes bonitos, o domínio evapora. O sistema passa a aceitar qualquer coisa, em qualquer ordem, desde que o banco permita. Nesse ponto, não existe CQRS. Existe CRUD com uma camada extra de abstração — e nenhuma delas ajuda de verdade.

Contrato mal definido é bug futuro garantido.

Leitura como produto

Do outro lado estão as Queries. E aqui acontece o segundo grande mal-entendido.

Queries não são espelhos do domínio.
Elas não existem para serem elegantes.
Elas existem para serem úteis.

Leitura é produto. Produto muda.

Uma tela nova surge, uma decisão de negócio muda, um relatório precisa de outro formato — a leitura muda junto. E isso não é um problema. É o comportamento esperado.

Queries são:

• descartáveis

• moldáveis

• orientadas a uso

Elas respondem perguntas específicas para consumidores específicos. Forçar leitura a respeitar o mesmo modelo da escrita é um erro clássico. É como exigir que um relatório financeiro use exatamente as mesmas abstrações internas do sistema contábil. Não é pureza arquitetural. É desperdício.

Contrato é coisa de escrita.
Leitura é adaptação.

O custo real do CQRS

CQRS não simplifica sistemas. Ele redistribui complexidade. Você troca complexidade acidental no banco por complexidade intencional no design

Essa troca custa caro.

Custa mais código, mais decisões explícitas, mais alinhamento entre pessoas. Custa conversas difíceis sobre responsabilidade, ownership e evolução. CQRS exige que o time saiba responder perguntas como: “onde essa regra vive?” e “quem é dono dessa decisão?”.

Esse custo não é um defeito. É o preço da clareza. CQRS não é um padrão para times que ainda precisam discutir onde fica a regra de negócio.

Quando CQRS faz sentido

CQRS faz sentido quando leitura e escrita evoluem em ritmos diferentes. Quando regras de negócio são críticas. Quando você precisa proteger invariantes e, ao mesmo tempo, entregar leitura rápida, flexível e orientada ao usuário.

Ele não faz sentido em CRUD simples, times pequenos ou domínios mal compreendidos. Nesses cenários, CQRS vira teatro arquitetural. E teatro não escala.

Não usar CQRS também é uma decisão arquitetural madura. A ausência consciente de um padrão costuma ser mais saudável do que sua adoção automática.

Anti-padrões comuns

Alguns sinais claros de que você não está usando CQRS, mesmo achando que está:

• “Separei dois bancos, logo uso CQRS”

• Commands que retornam DTOs gigantes

• Queries que precisam conhecer regras de negócio

• Read models sem dono claro

• Times que não sabem onde uma regra deveria viver

CQRS não falha sozinho. Ele falha quando é adotado sem entendimento, apenas como resposta genérica para problemas mal formulados.

Fechando a conta

CQRS não é hype. Também não é bala de prata. É uma escolha arquitetural difícil, que exige clareza conceitual e responsabilidade organizacional.

Se parece simples, você provavelmente está ignorando o custo.
Se virou só uma separação de banco, você perdeu o ponto.

CQRS não é sobre tabelas.
É sobre intenção, contrato e leitura como produto.

E isso, goste ou não, exige maturidade.

Se CQRS parece fácil, você não está fazendo CQRS.

Com o tempo, a situação muda. A base de código cresce, mais pessoas entram no repositório, o produto passa a ter dependências externas, integrações, requisitos não-funcionais mais rígidos. Aquele fluxo “meio improvisado” começa a mostrar rachaduras. O que antes era apenas um incômodo vira um obstáculo: pull requests enormes que ninguém quer revisar, features que “estão prontas” mas não chegam à produção, dificuldade em descobrir quando um bug foi introduzido, histórico de commits praticamente inútil para entender o que aconteceu.

É tentador culpar o Git, como se o problema estivesse na ferramenta. Mas, na maioria das vezes, o que está em jogo é o desenho do fluxo de trabalho por cima dela: como branches são criadas, como são integradas, como o time estrutura releases e como registra a história das mudanças.

Neste texto, vou tratar desse fluxo a partir de três elementos: o papel de estratégias de branching como GitFlow e trunk-based development, as diferenças de mentalidade entre essas abordagens e a forma como convenções de commit, em especial os Conventional Commits, ajudam a transformar o histórico em um recurso útil. A intenção não é defender um modelo “correto”, mas oferecer um vocabulário e alguns critérios para você olhar para o seu contexto e decidir conscientemente como quer trabalhar.

Ajustando o vocabulário

Antes de comparar estilos, é útil garantir que estamos usando as mesmas palavras para as mesmas coisas.

Uma branch é, essencialmente, uma linha alternativa de desenvolvimento. Em vez de todos trabalharem diretamente sobre a mesma linha do tempo, criamos “ramificações” para isolar mudanças. Isso permite explorar uma funcionalidade, refatorar um módulo ou testar uma abordagem sem interferir imediatamente na linha principal.

Quase sempre existe uma branch que tratamos como “tronco”: main, master ou trunk. A intenção é que essa branch represente um estado do código que, em teoria, poderia ir para produção. Não significa que todo commit deva ser implantado imediatamente, mas que a branch principal não deveria estar sistematicamente quebrada.

Integração contínua entra justamente nesse ponto. Ao integrar mudanças com frequência na branch principal e validar automaticamente o resultado, reduzimos o intervalo entre introduzir uma alteração e descobrir que ela causou um problema. Quanto menor esse intervalo, menor a área de busca quando algo dá errado.

Um segundo conceito importante é o de janelas de release. Alguns produtos podem ir para produção várias vezes ao dia; outros só podem ser atualizados em momentos específicos, ou precisam passar por etapas de homologação formais. O modelo de branching precisa respeitar essa realidade: é difícil falar seriamente em trunk-based development se o produto só pode ser atualizado uma vez por trimestre.

Por fim, há as feature flags. A ideia é simples: separar a presença do código da ativação do comportamento. O código de uma nova funcionalidade pode ser integrado gradualmente, mas o comportamento só é exposto quando uma flag é ligada. Em termos de código, algo como:

if (isFeatureEnabled("nova-tela-cadastro")) {
  // comportamento novo
} else {
  // comportamento antigo
}

Esse recurso é particularmente útil em estratégias que privilegiam integração frequente, porque permite levar código incompleto para a branch principal sem expô-lo para todos os usuários.

Com esses conceitos em mente, podemos olhar para GitFlow e trunk-based sem confundir os papéis que cada um desempenha.

GitFlow: releases como eixo de organização

GitFlow surgiu como uma proposta de dar mais estrutura ao uso de branches em equipes que precisavam lidar com releases bem definidas. Ele parte da ideia de que desenvolvimento contínuo e estabilização de uma release são atividades diferentes e, portanto, merecem linhas distintas na história do repositório.

Numa configuração típica, temos uma branch principal (main) representando o que está, ou pode estar, em produção; uma branch de desenvolvimento (develop), que acumula as mudanças da próxima versão; branches de funcionalidade (feature/...), que nascem de develop; branches de release (release/...), que surgem quando o time decide empacotar um conjunto de mudanças; e branches de hotfix (hotfix/...), usadas para corrigir problemas em produção.

É possível visualizar essa estrutura como um fluxo em camadas:

No dia a dia, o fluxo costuma se parecer com isto. Você começa uma nova funcionalidade criando feature/cadastro-cliente-pj a partir de develop. Trabalha nessa branch até que a funcionalidade faça sentido de ponta a ponta; em seguida, abre um pull request de feature/cadastro-cliente-pj para develop. Depois da revisão e dos testes, essa mudança passa a compor a próxima versão.

Com o passar do tempo, develop acumula diversas funcionalidades. Em algum momento o time decide que o conjunto atual está “suficiente” para ser lançado. Nesse ponto, cria-se algo como release/1.3.0 a partir de develop. Essa branch de release congela o conjunto de mudanças e muda o foco: de novos recursos para correções, ajustes finos e estabilização. Quando a release está estável, ela é mergeada em main e marcada com uma tag (por exemplo v1.3.0). Em seguida, a mesma release é mergeada de volta em develop, para que correções feitas durante a estabilização não se percam.

Problemas críticos em produção costumam seguir um caminho paralelo. Em vez de esperar pela próxima release planejada, o time cria, a partir de main, uma branch de hotfix, por exemplo hotfix/1.3.1, faz a correção, mergeia de volta em main com uma nova tag e traz essa correção para develop.

Quando esse fluxo funciona bem, ele oferece uma estrutura clara. É possível responder com precisão à pergunta “o que entrou na versão 1.3.0?”, localizar correções feitas em hotfix e manter uma separação razoável entre código em desenvolvimento e código em estabilização.

Não é por acaso que GitFlow ganhou adoção em contextos com forte preocupação com controle de versão: sistemas regulados, produtos que passam por homologações demoradas, equipes que precisam sincronizar lançamentos com outras áreas da empresa. Quando se fala em “versões” de forma explícita para o negócio, GitFlow fornece um vocabulário natural.

O problema aparece quando ampliamos a estrutura, mas não a disciplina. Nada no modelo impede branches de feature de viverem semanas, pull requests de crescerem até se tornarem praticamente irrecensáveis ou releases de ficarem indefinidamente em modo de estabilização. Em muitos times, GitFlow acaba reforçando o acúmulo: código “pronto” que demora para ser lançado, correções que precisam ser aplicadas em múltiplas branches, divergências constantes entre main e develop.

Quando isso acontece, a estrutura passa a trabalhar contra o fluxo. Manter o modelo começa a exigir esforço mental considerável: é preciso lembrar em qual branch uma correção deve entrar primeiro, qual conjunto de mudanças está sendo estabilizado e como reconciliar branches que se distanciaram demais. O próprio modelo, que deveria trazer clareza, se torna fonte de confusão.

Por isso, ao adotar algo inspirado em GitFlow, vale a pena pensar numa versão mais contida. Branches de feature precisam ter vida curta; branches de release não podem se transformar em projetos paralelos; hotfix deve ser exceção, não regra. O modelo continua o mesmo, mas a forma de usá-lo muda de maneira significativa.

Trunk-based development: mudanças pequenas, integração frequente

Trunk-based development parte de uma observação simples: quanto mais tempo uma branch vive afastada do tronco, mais cara será a integração quando ela finalmente voltar. A estratégia, então, é reduzir ao mínimo essa distância. Em vez de longos períodos em branches paralelas, o foco passa a ser integrar mudanças pequenas com frequência na branch principal.

Na maioria dos casos, essa branch principal é main. O desenvolvimento ainda faz uso de branches de trabalho, mas elas são efêmeras: nascem, carregam uma mudança pequena, passam por revisão, são integradas e morrem. O resultado é um fluxo bem mais próximo do tronco do que no GitFlow tradicional.

Um diagrama simplificado ajuda a visualizar:

Voltando ao exemplo da validação de CPF, num fluxo trunk-based você provavelmente começaria atualizando main, criaria uma branch como pedro/ajuste-validacao-cpf, faria a alteração, escreveria ou ajustaria os testes e abriria um pull request pequeno para main. Depois da revisão e da pipeline, a branch seria integrada e descartada. Se a alteração faz parte de uma funcionalidade maior que ainda não pode aparecer para todos, a ativação fica a cargo de uma feature flag, não de uma branch de longa duração.

Esse modelo exige que algumas condições estejam presentes. A primeira é uma pipeline de integração confiável: não faz sentido encorajar integração frequente em uma branch central se o time não tem como saber rapidamente quando algo quebrou. A segunda é uma disciplina em relação ao tamanho das mudanças. Trunk-based com pull requests grandes não é trunk-based; é apenas um GitFlow com menos branches de nome diferente. A terceira é uma certa maturidade em testes automatizados: quanto menos cobertura, mais difícil manter a confiança em uma branch principal em constante movimento.

Quando essas condições existem, os benefícios são claros. Conflitos de merge tendem a ser menores, porque as branches não se afastam tanto. Revisões tornam-se mais manejáveis, porque os pull requests têm escopo limitado. O tempo entre um desenvolvedor começar uma mudança e essa mudança estar efetivamente presente na branch principal diminui de forma considerável. Em ambientes onde a implantação também é frequente, esse tempo se aproxima bastante do tempo até produção.

Trunk-based costuma combinar bem com arquiteturas distribuídas e microsserviços. Cada serviço pode evoluir em passos pequenos, com deploys independentes. Em vez de coordenar grandes releases contendo dezenas de alterações, a equipe se acostuma com um fluxo contínuo de mudanças menores.

Isso não significa que trunk-based seja apropriado para qualquer contexto. Em ambientes com janelas de release rígidas e processos de aprovação longos, a integração frequente precisa conviver com uma etapa posterior de aprovação, e essa transição não é trivial. Ainda assim, mesmo nesses casos, é possível se beneficiar de uma mentalidade de mudanças pequenas dentro dos limites impostos pelas regras externas.

Mudança de mentalidade

É tentador tratar GitFlow e trunk-based como escolhas puramente técnicas. Na prática, a principal diferença entre eles é de mentalidade.

Quando uma equipe adota algo próximo de GitFlow, a conversa tende a orbitar em torno das branches e das versões. Com frequência ouvimos perguntas como: “em que branch essa correção deve entrar?”, “quando abrimos a branch da versão 1.4?”, “essa mudança ainda cabe na release atual?”. A atividade de desenvolvimento é organizada em torno de “pacotes” que recebem um rótulo de versão.

Num ambiente trunk-based, as perguntas mudam de foco. O que passa a ocupar espaço é: “como podemos quebrar essa mudança em incrementos menores?”, “isso cabe em um pull request que alguém consiga revisar em poucos minutos?”, “como levamos essa alteração para produção sem depender de uma grande janela de release?”. O eixo de organização deixa de ser a versão e passa a ser o tamanho e a cadência das mudanças.

Uma forma útil de comparar esses dois modos de pensar é observar dois intervalos de tempo. O primeiro é o que vai de “alguém começa a trabalhar numa mudança” até “essa mudança está presente na branch principal”. O segundo é o que vai de “a mudança está na branch principal” até “a mudança está em produção”. Equipes que trabalham em trunk-based saudável tendem a manter esses dois intervalos relativamente curtos e previsíveis. Equipes presas em estratégias mal ajustadas frequentemente convivem com intervalos longos, cheios de exceções.

Quando esses intervalos ficam grandes demais, não importa tanto o modelo nominal: o time passa a depender de esforço heroico a cada release, e o controle de versão deixa de ser um aliado para se tornar uma fonte de ansiedade.

O “Híbrido" do mundo real

Embora seja comum apresentar GitFlow e trunk-based como extremos, a maioria das equipes acaba adotando variações intermediárias. Isso é saudável; modelos não existem para serem seguidos literalmente, mas para fornecerem ideias que possamos adaptar.

Um time que valoriza os benefícios de trunk-based pode, por exemplo, manter uma branch principal bem viva, com pull requests pequenos e uso intensivo de feature flags, mas introduzir branches de release em momentos específicos do ano, quando o risco de uma falha é particularmente caro. Durante esses períodos, as mudanças que podem ir para produção passam pela branch de release, enquanto o desenvolvimento de médio prazo continua nas branches de trabalho que convergem para main.

Da mesma forma, uma equipe que declara usar GitFlow pode gradualmente simplificar o modelo: manter main e develop, limitar fortemente a duração das branches de feature, reduzir o uso de branches de release e delegar mais responsabilidade à automação de versionamento e marcação de tags. O resultado prático se aproxima bastante de trunk-based, ainda que a nomenclatura continue a ecoar o modelo original.

Ao pensar nessas misturas, vale observar um ponto: quanto mais responsabilidade colocamos na estrutura de branches, menos somos obrigados a fragmentar as mudanças. Quanto mais decisão deslocamos para o tamanho e a forma das alterações, menos dependemos de uma estrutura sofisticada de branches. É uma escolha de trade-off organizacional, não apenas técnica.

Conventional Commits: dando forma ao histórico

Até aqui falei de como o código se movimenta entre branches. Mas o histórico que fica registrado é igualmente relevante. Um fluxo de branches bem desenhado perde muito valor se as mensagens de commit forem opacas.

É comum ver repositórios cheios de commits com mensagens como “ajustes”, “teste”, “mudanças finais”, “corrigindo bug”. Quando precisamos entender o que realmente aconteceu numa determinada área do sistema, esse tipo de histórico dificulta o trabalho. Por outro lado, quando cada commit carrega um mínimo de estrutura e contexto, o log passa a ser uma ferramenta útil tanto para humanos quanto para automações.

Conventional Commits são uma proposta de convenção leve para trazer essa estrutura. A ideia é adotar um formato simples para as mensagens, expressando o tipo de mudança, o escopo e, quando necessário, detalhes adicionais.

A forma geral é:

<tipo>[escopo opcional]: <descrição curta>

[corpo opcional]

[rodapé opcional]

O tipo indica a natureza da alteração. Em muitos projetos, um pequeno conjunto de tipos já é suficiente para começar: feat para uma nova funcionalidade, fix para correções de bugs, docs para mudanças de documentação, refactor para alterações internas sem mudança de comportamento, test para adição ou ajuste de testes, chore para tarefas auxiliares como scripts e configurações.

O escopo, quando usado, ajuda a localizar mentalmente o efeito da mudança: algo como auth, payment, checkout, api e assim por diante.

Na prática, isso se traduz em mensagens como:

feat(auth): adiciona login com Google

Ou, numa correção um pouco mais detalhada:

fix(payment): corrige cálculo de juros no parcelamento

O problema acontecia quando o número de parcelas era maior que 12.
Atualizamos a fórmula e adicionamos testes cobrindo este cenário.

Quando uma mudança quebra compatibilidade, isso pode ser explicitado:

feat(api): remove endpoint de autenticação legado

BREAKING CHANGE: o endpoint /v1/login foi removido. Clientes devem migrar para /v2/login.

Com o tempo, um histórico construído dessa forma é muito mais fácil de interpretar. Também cria uma base para automação. Se o projeto adota versionamento semântico (por exemplo, versões do tipo MAJOR.MINOR.PATCH), ferramentas podem analisar o histórico, identificar commits que introduzem BREAKING CHANGE, somar novas funcionalidades (feat) e correções (fix) e sugerir novas versões e changelogs.

Essa disciplina é útil tanto num fluxo inspirado em GitFlow quanto num trunk-based. Em estratégias centradas em release, ela ajuda a responder “o que exatamente entrou na versão 1.3.0?”. Em estratégias centradas em integração frequente, ajuda a não perder o contexto no meio de muitos commits pequenos.

Considerações finais

GitFlow oferece uma estrutura clara para contextos em que releases são unidades importantes de planejamento e comunicação. Ele funciona bem quando é usado para dar visibilidade e controle, e não como justificativa para atrasos permanentes.

Trunk-based development enfatiza mudanças pequenas e integração frequente. Ele funciona melhor onde há investimento em automação e testes, e onde o produto se beneficia de uma cadência mais contínua de entrega.

Conventional Commits, por sua vez, tratam do aspecto mais frequentemente negligenciado: a legibilidade do histórico. Independentemente do modelo de branching, o hábito de escrever commits que expliquem o que mudou, onde mudou e por quê transforma o controle de versão em uma ferramenta de entendimento, não apenas de armazenamento.

Em última análise, a pergunta relevante não é “qual modelo é melhor em abstrato?”, mas “que fluxo de versionamento ajuda este time, com este produto e estas restrições, a entregar com segurança e previsibilidade?”. A resposta raramente é uma receita pronta. Ela emerge da combinação de alguns princípios simples: reduzir o tamanho das mudanças, integrar com frequência quando isso é possível, tornar o histórico legível e ajustar a estrutura de branches ao contexto real, em vez de ao diagrama de referência.

O Git, por si só, é apenas uma ferramenta. O valor está na forma como escolhemos contar a história do sistema em cima dela.

Suleyman descreve a próxima onda tecnológica como um fenômeno caracterizado por diversas propriedades que tornam seu impacto imprevisível e desafiador. A hiperevolução tecnológica impulsiona avanços em um ritmo tão acelerado que a adaptação social e regulatória se torna difícil. Além disso, seu omniuso permite aplicações variadas, ampliando tanto seu potencial benéfico quanto seus riscos. A assimetria da tecnologia possibilita que pequenos grupos ou indivíduos tenham acesso a um nível de poder antes restrito a grandes corporações ou estados-nação, aumentando oportunidades e ameaças. Outro ponto crítico é a crescente autonomia dos sistemas de IA, que operam de formas cada vez menos transparentes, tornando sua governança mais complexa.

Tenho refletido sobre como a percepção humana em relação aos avanços tecnológicos mudou desde as grandes guerras, especialmente após a Segunda Guerra Mundial. O impacto da bomba atômica revelou um potencial destrutivo sem precedentes, capaz de ameaçar a própria existência do planeta. Desde então, tanto a comunidade científica quanto a sociedade em geral passaram a questionar com mais frequência se os benefícios de uma nova tecnologia justificam os riscos que ela pode trazer.

O Que Me Chamou a Atenção

Um dos pontos que mais me impactou na leitura foi a ideia do omniuso da tecnologia. Suleyman compara essas novas ferramentas à eletricidade, destacando sua versatilidade: podem ser usadas para impulsionar avanços significativos, mas também possuem um grande potencial destrutivo. Esse conceito nos faz refletir sobre a dificuldade de regular e antecipar os impactos dessas inovações, especialmente considerando a democratização do acesso a essas tecnologias. O fato de que pequenos grupos ou indivíduos podem, cada vez mais, ter acesso a recursos antes exclusivos de governos ou grandes corporações adiciona uma camada extra de complexidade a essa equação. O autor também descreve a IA como uma tecnologia de propósito geral, o que torna impossível prever como será usada e na resolução de quais problemas será aplicada. Trata-se de uma tecnologia que habilita a criação de novas tecnologias.

Outro aspecto que me marcou foi a discussão sobre a corrida tecnológica global, principalmente entre Estados Unidos e China. A urgência com que essas nações estão investindo em inteligência artificial e outras tecnologias emergentes cria um cenário de possível instabilidade, no qual a busca pela liderança pode levar a decisões precipitadas e até mesmo perigosas.

Minha Opinião

Embora o livro traga reflexões fundamentais, em alguns momentos o tom me pareceu excessivamente alarmista. Os riscos apresentados são reais e precisam ser debatidos, mas enfatizar demais os aspectos negativos pode gerar uma sensação de impotência no leitor. No entanto, Suleyman equilibra essa abordagem ao destacar também os benefícios da tecnologia e propor estratégias para mitigar seus impactos negativos.

Dito isso, reconheço que o objetivo do autor não é simplesmente alarmar, mas sim gerar um senso de urgência e responsabilidade. O livro cumpre esse papel, trazendo à tona questões que muitas vezes são ignoradas no debate público sobre tecnologia.

Reflexões Finais

A Próxima Onda é uma leitura que provoca reflexão. O livro não apenas alerta para os desafios do futuro, mas também sugere caminhos para o desenvolvimento responsável dessas tecnologias. Para mim, a principal lição foi a necessidade de um equilíbrio entre inovação e controle. O avanço tecnológico é inevitável, mas seu impacto dependerá diretamente das decisões que tomarmos agora.

Se você se interessa por tecnologia e seus efeitos na sociedade, recomendo a leitura. Mesmo com um tom um pouco pessimista em alguns momentos, a obra traz insights valiosos sobre o futuro que estamos construindo.

Importância da Reunião Diária

O Scrum é uma metodologia ágil que se concentra em entregar valor de forma iterativa e incremental. A reunião diária, ou Daily Scrum, é fundamental para manter a equipe alinhada e identificar rapidamente quaisquer impedimentos. Ela promove a colaboração e garante que todos estejam cientes do progresso e dos desafios enfrentados pela equipe.

Desafios Comuns

Com o tempo, algumas equipes acabam perdendo os principais benefícios dessa reunião, transformando-a em um ritual mecânico sem foco real nos objetivos da equipe. Muitas vezes, essas reuniões se transformam quase em um Status Report, onde os membros apenas relatam o que fizeram sem um verdadeiro engajamento com os objetivos da equipe. Isso pode fazer com que parte do valor da reunião seja perdido.

Mudança na percepção da daily

Sempre ouvi dizer que na daily cada integrante deve responder a 3 principais perguntas:

1. O que eu fiz ontem para ajudar a equipe a atingir seus objetivos?

2. Qual é o meu plano para hoje para ajudar a equipe a atingir seus objetivos? (Ou como sempre pensei, “Em que estou trabalhando agora“)

3. Existem obstáculos no meu caminho?

A mudança na minha percepção ocorreu especialmente na segunda pergunta. Muitas vezes, essas reuniões se transformam quase em um Status Report, onde os membros apenas relatam o que fizeram sem um verdadeiro engajamento com os objetivos da equipe. Isso pode fazer com que parte do valor da reunião seja perdido, pois o foco se desloca do alinhamento estratégico para uma simples atualização de tarefas.

É crucial que a equipe utilize esse momento para reavaliar as atividades planejadas, garantindo que elas realmente são as que mais contribuem para atingir os objetivos coletivos. Essa prática não só mantém a equipe alinhada com os objetivos do projeto, mas também assegura que todos estejam trabalhando de forma eficaz e eficiente, priorizando as tarefas que trazem maior impacto.

A reunião diária é, acima de tudo, uma reunião da equipe e para a equipe. Ela não deve se transformar em uma sessão para gestores ou outras áreas de negócios controlarem a produção do time. O foco deve estar na colaboração e no alinhamento interno, permitindo que a equipe identifique e resolva impedimentos rapidamente. Ao adotar o Scrum, as equipes podem experimentar ganhos significativos, como maior transparência, melhor comunicação, e uma capacidade aprimorada de se adaptar a mudanças. Isso resulta em entregas de maior valor e em um ambiente de trabalho mais coeso e motivado, onde todos estão comprometidos com os objetivos comuns.

Conclusão

Ao revitalizar a prática do Scrum, a equipe pode colher todos os benefícios que a metodologia tem a oferecer, promovendo um ambiente de colaboração e foco nos resultados que realmente importam. Isso resulta em entregas de maior valor e em um ambiente de trabalho mais coeso e motivado, onde todos estão comprometidos com os objetivos comuns.

Os cinco princípios que compõem o acrônimo SOLID — Single Responsibility Principle (SRP), Open/Closed Principle (OCP), Liskov Substitution Principle (LSP), Interface Segregation Principle (ISP) e Dependency Inversion Principle (DIP) — são amplamente aplicados no desenvolvimento orientado a objetos e podem ser fundamentais para o sucesso de projetos em C#.

Neste post, exploraremos cada um desses princípios, explicando seu significado e importância, e veremos exemplos práticos em C# para entender como aplicá-los no dia a dia. Seja você um iniciante em SOLID ou um profissional experiente buscando reforçar boas práticas, este guia é para você!

Single Responsibility Principle (SRP)

O Single Responsibility Principle (Princípio da Responsabilidade Única) é o primeiro dos princípios SOLID e estabelece que uma classe deve ter apenas uma razão para mudar. Em outras palavras, cada classe deve ser responsável por apenas uma funcionalidade ou tarefa no sistema. Isso reduz o acoplamento, facilita a manutenção e promove a reutilização de código.

A quebra desse princípio geralmente ocorre quando uma classe assume várias responsabilidades. Vamos explorar isso com exemplos.

Exemplo 1: Quebrando o SRP

class Invoice
{
    public void GenerateInvoice()
    {
        Console.WriteLine("Generating the invoice...");
    }

    public void SendInvoiceEmail()
    {
        Console.WriteLine("Sending invoice email...");
    }

    public void SaveInvoiceToDatabase()
    {
        Console.WriteLine("Saving invoice to database...");
    }
}

Problema:

A classe Invoice está assumindo múltiplas responsabilidades:

1. Gerar a fatura.

2. Enviar a fatura por e-mail.

3. Persistir a fatura no banco de dados.

Se qualquer uma dessas funcionalidades precisar ser alterada, a classe inteira será afetada, tornando-a mais difícil de manter e testar.

Exemplo 2: Respeitando o SRP

Vamos refatorar o código para que cada classe seja responsável por uma única tarefa.

class InvoiceGenerator
{
    public Invoice Generate()
    {
        Console.WriteLine("Generating the invoice...");
    }
}

public class EmailService
{
    public void Send(string email, string message)
    {
        Console.WriteLine($"Sending email to {email}: {message}");
    }
}

public class InvoiceRepository
{
    public void Save(Invoice invoice)
    {
        Console.WriteLine("Saving invoice to database...");
    }
}

Agora, ao invés de uma classe fazer tudo, temos três classes separadas:

• InvoiceGenerator: responsável apenas por gerar a fatura.

• EmailService: responsável por enviar o e-mail.

• InvoiceRepository: responsável por salvar a fatura no banco de dados.

Uso do Código Refatorado

class InvoiceService
{
    private readonly InvoiceGenerator _generator;
    private readonly EmailService _emailService;
    private readonly InvoiceRepository _repository;

    public InvoiceService()
    {
        _generator = new InvoiceGenerator();
        _emailService = new EmailService();
        _repository = new InvoiceRepository();
    }

    public void ProcessInvoice()
    {
        Invoice invoice = _generator.Generate();
        _repository.Save(invoice);
        _emailService.Send("client@example.com", "Your invoice has been generated.");
    }
}

Agora, o código segue o SRP, pois cada classe tem uma única responsabilidade. A classe InvoiceService coordena o fluxo geral sem violar o princípio.

Benefícios de Aplicar o SRP

1. Facilidade de Manutenção: Alterações em uma funcionalidade não impactam outras funcionalidades.

2. Melhor Testabilidade: Classes menores com uma única responsabilidade são mais fáceis de testar.

3. Reutilização de Código: Cada classe pode ser reutilizada em diferentes contextos sem modificações.

O SRP é essencial para escrever código modular e sustentável, especialmente em sistemas complexos que exigem mudanças constantes. Com ele, você evita a criação de "classes Deus" que fazem tudo e tornam o código difícil de gerenciar.

Open/Closed Principle (OCP)

O segundo princípio do SOLID, o Open/Closed Principle (Princípio Aberto/Fechado), estabelece que as entidades de software (classes, módulos, funções) devem estar abertas para extensão, mas fechadas para modificação.

Isso significa que você deve ser capaz de adicionar novas funcionalidades ao sistema sem alterar o código existente. O objetivo é minimizar os riscos de introduzir bugs ao modificar código já testado e em funcionamento.

Vamos analisar um exemplo onde esse princípio é quebrado e, em seguida, refatorá-lo para alinhá-lo ao OCP.

Exemplo 1: Quebrando o OCP

public class DiscountCalculator
{
    public decimal CalculateDiscount(string customerType, decimal totalAmount)
    {
        if (customerType == "Regular")
        {
            return totalAmount * 0.1m;
        }
        else if (customerType == "VIP")
        {
            return totalAmount * 0.2m;
        }
        else
        {
            return 0;
        }
    }
}

Problema:

• Cada vez que adicionamos um novo tipo de cliente, precisamos modificar o método CalculateDiscount.

• Isso viola o princípio, pois estamos alterando código já existente, potencialmente introduzindo erros.

Exemplo 2: Respeitando o OCP

Vamos refatorar o código usando o polimorfismo para permitir a extensão do comportamento sem modificar o código existente.

Passo 1: Criar uma interface para definir o comportamento de cálculo de desconto

public interface IDiscountStrategy
{
    decimal Calculate(decimal totalAmount);
}

Passo 2: Implementar estratégias específicas de desconto

public class RegularCustomerDiscount : IDiscountStrategy
{
    public decimal Calculate(decimal totalAmount)
    {
        return totalAmount * 0.1m;
    }
}

public class VIPCustomerDiscount : IDiscountStrategy
{
    public decimal Calculate(decimal totalAmount)
    {
        return totalAmount * 0.2m;
    }
}

public class NoDiscount : IDiscountStrategy
{
    public decimal Calculate(decimal totalAmount)
    {
        return 0;
    }
}

Passo 3: Atualizar a classe principal para utilizar as estratégias

public class DiscountCalculator
{
    private readonly IDiscountStrategy _discountStrategy;

    public DiscountCalculator(IDiscountStrategy discountStrategy)
    {
        _discountStrategy = discountStrategy;
    }

    public decimal CalculateDiscount(decimal totalAmount)
    {
        return _discountStrategy.Calculate(totalAmount);
    }
}

Uso do Código Refatorado

Agora podemos adicionar novas estratégias de desconto sem modificar o código existente.

class Program
{
    static void Main(string[] args)
    {
        var regularDiscountCalculator = new DiscountCalculator(new RegularCustomerDiscount());
        Console.WriteLine("Regular Customer Discount: " + regularDiscountCalculator.CalculateDiscount(100));

        var vipDiscountCalculator = new DiscountCalculator(new VIPCustomerDiscount());
        Console.WriteLine("VIP Customer Discount: " + vipDiscountCalculator.CalculateDiscount(100));

        var noDiscountCalculator = new DiscountCalculator(new NoDiscount());
        Console.WriteLine("No Discount: " + noDiscountCalculator.CalculateDiscount(100));
    }
}

Benefícios de Aplicar o OCP

1. Extensibilidade: Novas funcionalidades podem ser adicionadas sem alterar código existente.

2. Manutenção Simplificada: Reduz o risco de introduzir bugs ao modificar o sistema.

3. Testabilidade: Cada estratégia pode ser testada de forma independente.

O OCP promove um design mais flexível e resiliente a mudanças. Com ele, você pode evoluir o sistema de forma incremental, garantindo que o código antigo continue funcionando conforme esperado.

Liskov Substitution Principle (LSP)

O terceiro princípio do SOLID, o Liskov Substitution Principle (Princípio da Substituição de Liskov), afirma que uma classe derivada deve poder substituir sua classe base sem que o comportamento correto do programa seja alterado.

Em outras palavras, se você tiver um objeto de uma classe base, deve ser possível substituí-lo por um objeto de uma classe derivada sem que o sistema apresente problemas.

Este princípio está intimamente relacionado à herança e é essencial para evitar designs problemáticos que levam a código frágil ou imprevisível.

Exemplo 1: Quebrando o LSP

Considere o seguinte exemplo com uma classe base para formas geométricas:

public class Rectangle
{
    public virtual int Width { get; set; }
    public virtual int Height { get; set; }

    public int GetArea()
    {
        return Width * Height;
    }
}

Agora, uma classe derivada para representar quadrados:

public class Square : Rectangle
{
    public override int Width
    {
        set { base.Width = base.Height = value; }
    }

    public override int Height
    {
        set { base.Width = base.Height = value; }
    }
}

Problema:

• Embora um quadrado seja matematicamente um retângulo, a implementação acima quebra o LSP.

• O comportamento esperado do método GetArea é inconsistente quando Square é usado como Rectangle.

var rectangle = new Square();
rectangle.Width = 5;
rectangle.Height = 10; // Problema: Width também é alterado!
Console.WriteLine(rectangle.GetArea()); // Resultado inesperado: 100

Ao modificar a propriedade Height, também alteramos a propriedade Width, quebrando a lógica esperada do sistema.

Exemplo 2: Respeitando o LSP

Vamos refatorar o design para respeitar o LSP, eliminando o uso incorreto de herança.

Passo 1: Redefinir o design com uma interface comum

public interface IShape
{
    int GetArea();
}

Passo 2: Implementar classes específicas para retângulos e quadrados

public class Rectangle : IShape
{
    public int Width { get; set; }
    public int Height { get; set; }

    public int GetArea()
    {
        return Width * Height;
    }
}

public class Square : IShape
{
    public int Side { get; set; }

    public int GetArea()
    {
        return Side * Side;
    }
}

Uso do Código Refatorado

Agora cada forma tem sua própria implementação independente, e o LSP é respeitado:

class Program
{
    static void Main(string[] args)
    {
        IShape rectangle = new Rectangle { Width = 5, Height = 10 };
        Console.WriteLine("Rectangle Area: " + rectangle.GetArea()); // Saída: 50

        IShape square = new Square { Side = 5 };
        Console.WriteLine("Square Area: " + square.GetArea()); // Saída: 25
    }
}

Benefícios de Respeitar o LSP

1. Consistência: Evita comportamentos inesperados em classes derivadas.

2. Flexibilidade: O sistema pode usar objetos de diferentes classes de forma intercambiável.

3. Reutilização de Código: Ao evitar designs problemáticos, o código é mais fácil de manter e estender.

O LSP é um princípio crucial para garantir que sua hierarquia de classes seja sólida e previsível. Respeitá-lo promove a criação de sistemas robustos e mais fáceis de entender e testar.

Interface Segregation Principle (ISP)

O quarto princípio do SOLID, o Interface Segregation Principle (Princípio da Segregação de Interfaces), estabelece que nenhum cliente deve ser forçado a depender de métodos que não utiliza.

Em termos práticos, isso significa que devemos criar interfaces específicas para cada necessidade, evitando interfaces "inchadas" que exigem que as classes implementem métodos desnecessários. Esse princípio promove designs mais enxutos, flexíveis e fáceis de manter.

Exemplo 1: Quebrando o ISP

Considere uma interface genérica para gerenciamento de relatórios:

public interface IShape
{
    void CalculateArea();
    void CalculateVolume();
}

Agora, temos duas classes que implementam essa interface:

public class Square : IShape
{
    public void CalculateArea()
    {
        Console.WriteLine("Calculating area.");
    }

    public void CalculateVolume()
    {
        throw new NotImplementedException();
    }
}

public class Cube : IShape
{
    public void CalculateArea()
    {
        Console.WriteLine("Calculating area.");
    }

    public void CalculateVolume()
    {
        Console.WriteLine("Calculating Volume.");
    }
}

Problema:

As classes Square e Cube são forçadas a implementar métodos que não utilizam. Isso resulta em:

1. Código desnecessário e confuso: Os métodos não utilizados lançam exceção.

2. Manutenção difícil: Alterações na interface afetam todas as classes que a implementam, mesmo que elas não usem os métodos adicionados.

var geometricShape = new Square();
geometricShape.CalculateArea(); // Funciona
geometricShape.CalculateVolume(); // Lança uma exceção!

Exemplo 2: Respeitando o ISP

Para corrigir, vamos dividir a interface em partes menores e específicas para cada forma geométrica.

Passo 1: Definir interfaces específicas

public interface IAreaCalculation
{
    void CalculateArea();
}

public interface IVolumeCalculation
{
    void CalculateVolume();
}

Passo 2: Implementar apenas as interfaces necessárias

public class Square : IAreaCalculation
{
    public void CalculateArea()
    {
        Console.WriteLine("Calculated Area.");
    }
}

public class Cube : IAreaCalculation, IVolumeCalculation
{
    public void CalculateArea()
    {
        Console.WriteLine("Calculating area.");
    }

    public void CalculateVolume()
    {
        Console.WriteLine("Calculated Volume.");
    }
}

Uso do Código Refatorado

Agora, cada classe implementa apenas os métodos que realmente utiliza:

class Program
{
    static void Main(string[] args)
    {
        IAreaCalculation square = new Square();
        square.CalculateArea(); // Saída: Calculated Area.

        IVolumeCalculation cube = new Cube();
        cube.CalculateArea(); // Saída: Calculated Area.
        cube.CalculateVolume(); // Saída: Calculated Volume.
    }
}

Benefícios de Respeitar o ISP

1. Código mais limpo: Classes implementam apenas métodos relevantes.

2. Flexibilidade: Alterações em uma interface específica não afetam classes que não a utilizam.

3. Manutenção facilitada: Sistemas com interfaces menores e mais focadas são mais fáceis de manter e estender.

O ISP incentiva um design modular, onde cada classe e interface desempenha um papel claro e bem definido. Ao respeitar este princípio, evitamos o acoplamento desnecessário e criamos sistemas mais robustos e fáceis de evoluir.

Dependency Inversion Principle (DIP)

O quinto e último princípio do SOLID, o Dependency Inversion Principle (Princípio da Inversão de Dependência), sugere que:

1. Módulos de alto nível não devem depender de módulos de baixo nível. Ambos devem depender de abstrações.

2. Abstrações não devem depender de detalhes. Detalhes devem depender de abstrações.

Em outras palavras, devemos evitar dependências diretas entre classes concretas e, em vez disso, usar abstrações (interfaces ou classes abstratas). Isso torna o código mais flexível, desacoplado e fácil de testar.

Exemplo 1: Quebrando o DIP

Imagine um sistema que envia notificações por e-mail:

public class EmailService
{
    public void SendEmail(string message)
    {
        Console.WriteLine($"Email sent: {message}");
    }
}

public class NotificationManager
{
    private readonly EmailService _emailService;

    public NotificationManager()
    {
        _emailService = new EmailService();
    }

    public void SendNotification(string message)
    {
        _emailService.SendEmail(message);
    }
}

Problema:

1. Alto acoplamento: NotificationManager está diretamente dependente da implementação de EmailService.

2. Dificuldade de expansão: Se quisermos enviar notificações por SMS ou outro canal, será necessário modificar a lógica de NotificationManager.

3. Dificuldade para testar: Não podemos facilmente substituir EmailService por uma implementação fictícia (mock) para testes.

Exemplo 2: Respeitando o DIP

Vamos introduzir uma abstração para que o NotificationManager dependa de interfaces, e não de classes concretas.

Passo 1: Criar uma abstração

public interface INotificationService
{
    void Send(string message);
}

Passo 2: Implementar a abstração

public class EmailService : INotificationService
{
    public void Send(string message)
    {
        Console.WriteLine($"Email sent: {message}");
    }
}

public class SmsService : INotificationService
{
    public void Send(string message)
    {
        Console.WriteLine($"SMS sent: {message}");
    }
}

Passo 3: Alterar NotificationManager para depender da abstração

public class NotificationManager
{
    private readonly INotificationService _notificationService;

    public NotificationManager(INotificationService notificationService)
    {
        _notificationService = notificationService;
    }

    public void SendNotification(string message)
    {
        _notificationService.Send(message);
    }
}

Uso do Código Refatorado

Com a implementação acima, podemos facilmente injetar diferentes serviços de notificação:

class Program
{
    static void Main(string[] args)
    {
        INotificationService emailService = new EmailService();
        NotificationManager emailNotificationManager = new NotificationManager(emailService);
        emailNotificationManager.SendNotification("Hello via Email!"); 
        // Saída: Email sent: Hello via Email!

        INotificationService smsService = new SmsService();
        NotificationManager smsNotificationManager = new NotificationManager(smsService);
        smsNotificationManager.SendNotification("Hello via SMS!"); 
        // Saída: SMS sent: Hello via SMS!
    }
}

Benefícios de Respeitar o DIP

1. Baixo acoplamento: A lógica de NotificationManager é independente de implementações específicas, permitindo maior flexibilidade.

2. Facilidade de expansão: Para adicionar um novo canal de notificação, basta criar uma nova implementação de INotificationService.

3. Testabilidade: Implementações fictícias de INotificationService podem ser usadas em testes para simular diferentes cenários.

O DIP permite criar sistemas extensíveis, flexíveis e preparados para mudanças futuras. Ele promove um design orientado a abstrações, priorizando a independência de módulos de alto nível e detalhes concretos.

Conclusão

Adotar os princípios SOLID não é só sobre ser um bom desenvolvedor – é sobre evitar que seu legado seja um caos absoluto que ninguém quer encostar o dedo. Porque, convenhamos, ninguém quer ser lembrado como "aquele que zoou o projeto todo porque não entendia o Open/Closed Principle". E sim, estamos olhando pra você, amigo que gosta de fazer classes Deus. 😑

Então, aplique o SOLID, liberte-se do peso do código bagunçado e escreva algo que não cause ataques de pânico em quem vier depois de você. Ou não. Só não reclame quando suas pull requests começarem a vir com memes de tragédia. 😏

O desenvolvimento de software é uma atividade complexa que requer habilidade, conhecimento e atenção aos detalhes. Em meio aos desafios diários enfrentados pelos desenvolvedores, uma das metas mais importantes é criar códigos limpos, legíveis e de fácil manutenção. Este é um dos pilares fundamentais para o sucesso de qualquer projeto, pois reduz a complexidade e garante que o sistema possa evoluir ao longo do tempo sem comprometer sua qualidade.

Neste texto, exploraremos os princípios básicos do Clean Code, explicando como sua aplicação pode transformar o desenvolvimento de software em uma experiência mais eficiente e colaborativa.

O que é Clean Code?

Clean Code, ou código limpo, é aquele que é fácil de ler, entender e modificar. Ele segue boas práticas que ajudam os desenvolvedores a manterem um padrão consistente em todo o sistema. Popularizado por Robert C. Martin, conhecido como Uncle Bob, o conceito foi amplamente discutido em seu livro Clean Code: A Handbook of Agile Software Craftsmanship.

Uncle Bob defende que Clean Code não se trata de um conjunto de regras fixas, mas de princípios e práticas que orientam o desenvolvedor a criar soluções que possam ser facilmente compreendidas por outros profissionais. Escrever código limpo é, portanto, uma questão de mentalidade e disciplina.

Princípios fundamentais do Clean Code

1. Legibilidade

A legibilidade é uma característica essencial de um código limpo. Um código legível permite que outros desenvolvedores entendam rapidamente o que foi feito e por quê.

Imagine que você herda um projeto e encontra uma estrutura bem organizada, com nomes claros para variáveis, funções e classes. Isso torna a compreensão do código mais ágil e reduz o risco de erros ao modificar ou expandir o sistema.

Dicas para melhorar a legibilidade:

• Use nomes descritivos para variáveis, funções e classes.

• Mantenha um fluxo lógico, organizando o código em blocos coesos.

• Evite abreviações ou jargões que possam confundir outros desenvolvedores.

Um código legível também facilita revisões, permitindo que outros profissionais forneçam feedback construtivo e identifiquem melhorias potenciais.

2. Simplicidade

Código simples é mais fácil de entender, testar e modificar. Simplicidade significa reduzir a complexidade ao mínimo necessário para resolver um problema.

Estratégias para alcançar simplicidade:

• Divida em funções menores: Cada função deve ter um objetivo claro e bem definido.

• Evite complexidade desnecessária: Não introduza abstrações antes que sejam realmente necessárias.

• Refatore frequentemente: Revisite o código e busque soluções mais simples sempre que possível.

A simplicidade não significa ignorar a complexidade do problema que você está resolvendo, mas encontrar maneiras de representá-la de forma clara e compreensível.

3. Evite duplicação de código

A duplicação de código é uma armadilha comum que compromete a manutenção do sistema. Ao copiar e colar trechos de código, você cria dependências desnecessárias e aumenta o risco de inconsistências.

Adote o princípio DRY (Don’t Repeat Yourself) para evitar problemas futuros:

• Centralize a lógica compartilhada em funções reutilizáveis.

• Analise o código duplicado para identificar oportunidades de abstração.

• Tenha cuidado ao reutilizar código: certifique-se de que ele é genérico o suficiente para ser aplicado em diferentes contextos sem gerar conflitos.

4. Documentação eficaz

Embora o objetivo seja escrever um código que se explique por si só, a documentação desempenha um papel importante ao esclarecer detalhes específicos do sistema que não estão evidentes no código.

Boas práticas para documentação:

• Comente apenas quando necessário, priorizando explicações sobre o porquê de uma decisão.

• Utilize ferramentas para documentação de código, como JSDoc ou Swagger, especialmente para APIs.

• Inclua testes automatizados bem escritos, que não só validam o código, mas também funcionam como documentação executável.

5. Consistência

Manter um padrão consistente em todo o projeto é fundamental para a colaboração entre membros da equipe e para a manutenção a longo prazo.

Dicas para garantir consistência:

• Utilize guias de estilo estabelecidos, como o PEP 8 para Python ou as diretrizes do Airbnb para JavaScript.

• Padronize nomes, formatos e organização do código.

• Adote ferramentas automáticas, como linters e formatadores de código, para garantir que todos sigam os mesmos padrões.

A consistência também facilita a revisão de código, pois todos os membros da equipe compartilham as mesmas expectativas sobre como o código deve ser escrito e organizado.

Conclusão

Adotar as práticas de Clean Code é mais do que um esforço técnico; é um compromisso com a qualidade e a colaboração no desenvolvimento de software. Um código limpo não apenas reduz a probabilidade de erros e facilita a manutenção, mas também promove um ambiente de trabalho mais harmonioso, onde todos os envolvidos conseguem entender e contribuir para o projeto de forma eficiente.

Escrever código legível, simples, sem duplicações, bem documentado e consistente pode exigir mais atenção e disciplina no curto prazo, mas os benefícios a longo prazo são imensuráveis. Como desenvolvedores, devemos sempre buscar soluções que não só funcionem bem hoje, mas que também possam evoluir de forma sustentável no futuro. Afinal, um código limpo não é apenas para máquinas – é, acima de tudo, para as pessoas que trabalharão com ele.

Neste artigo, falarei as vantagens do uso do plugin de DevContainer do VS Code e explicarei como configurá-lo.

Vantagens do uso do plugin de DevContainer

Antes de detalhar a instalação e forma de uso, vamos destacar as vantagens do uso do plugin de DevContainer:

• Ambientes de desenvolvimento consistentes e isolados

Com o DevContainer, você pode garantir que todos os desenvolvedores trabalhem com o mesmo ambiente de desenvolvimento, utilizando as mesmas ferramentas e bibliotecas. Isso evita problemas de compatibilidade e garante que o desenvolvimento ocorra de forma consistente. Além disso, é possível manter uma padronização nas configurações, mesmo em diferentes máquinas.

• Fácil Configuração

A configuração de um ambiente de desenvolvimento pode ser uma tarefa complicada e demorada. Com o DevContainer, a configuração é feita automaticamente, economizando tempo e esforço.

• Ambientes de desenvolvimento escaláveis

O DevContainer permite escalar o ambiente de desenvolvimento para atender às necessidades do projeto. É possível adicionar novas ferramentas e bibliotecas ao contêiner conforme necessário, sem precisar configurar cada máquina de desenvolvimento individualmente.

• Testes de integração mais fáceis

O DevContainer torna mais fácil testar a integração do aplicativo em diferentes ambientes. É possível criar contêineres para cada ambiente de produção e teste e garantir que o aplicativo funcione corretamente em cada ambiente.

Configuração do plugin de DevContainer

Agora que destacamos as vantagens do uso do plugin de DevContainer, vamos explicar como configurá-lo:

• Instale o Docker em sua máquina.

Antes de configurar o DevContainer, você precisa ter o Docker instalado em sua máquina. Você pode baixar e instalar o Docker a partir do site oficial (https://www.docker.com/products/docker-desktop).

• Abra o VS Code e crie um novo arquivo ou pasta para o seu projeto.

• Instale o plugin Dev Container

Na aba de extensões, procure por Dev Container e siga as instruções de instalação.

• Na barra lateral, clique no ícone "Remote Explorer" ou pressione Ctrl + Shift + P para abrir a barra de comando e digite "Remote-Containers: Open Folder in Container".

• Selecione a pasta do seu projeto

• Escolha a imagem a ser utilizada

Um menu para a escolha de qual imagem deve ser usada será exibido. A lista de templates disponíveis pode ser encontrada aqui.

Isso pode levar alguns minutos, dependendo do tamanho do seu projeto.

• Depois que o DevContainer estiver configurado, o VS Code abrirá automaticamente uma nova janela com o ambiente de desenvolvimento dentro do contêiner.

É possível escolher diversas aplicações que auxiliam no processo de desenvolvimento para serem instaladas durante o build da imagem, por exemplo, AWS CLI, Google Cloud CLI, etc. Uma lista das features disponíveis pode ser encontrada aqui.

Importante comentar que o GIT já vai instalado em todas as imagens padrão disponibilizadas. Sendo assim, a imagem mais simples, que é a Alpine, já vem com o GIT não sendo necessária a sua instalação.

.devcontainer

Ao se conectar a um container pela primeira vez, uma pasta é criada, a .devcontainer. Dentro desta pasta encontramos um arquivo chamado devcontainer.json. É neste arquivo que as principais configurações são guardadas.

O conteúdo do arquivo é semelhante ao seguinte código:

{
    "name": "C# (.NET)",
    // Or use a Dockerfile or Docker Compose file. More info: https://containers.dev/guide/dockerfile
    "image": "mcr.microsoft.com/devcontainers/dotnet:0-7.0"

    // Features to add to the dev container. More info: https://containers.dev/features.
    // "features": {},

    // Use 'forwardPorts' to make a list of ports inside the container available locally.
    // "forwardPorts": [5000, 5001],
    // "portsAttributes": {
    //        "5001": {
    //            "protocol": "https"
    //        }
    // }

    // Use 'postCreateCommand' to run commands after the container is created.
    // "postCreateCommand": "dotnet restore",

    // Configure tool-specific properties.
    // "customizations": {},

    // Uncomment to connect as root instead. More info: https://aka.ms/dev-containers-non-root.
    // "remoteUser": "root"
}

Image

Na chave image é onde se localiza o nome e a versão da imagem que será usada para criar o container. É possível, troca-la por uma outra totalmente diferente caso seja necessário. Trocando o nome da imagem, ao reabrir a pasta usando o container, será exibida uma janela perguntando se a imagem precisa ser reconstruída.

Essa janela aparecerá sempre que ocorrer qualquer alteração na imagem, ou em alguma configuração do container. Para que as alterações sejam realizadas, o container precisa ser reconstruído. Depois de reconstruído, os arquivos da pasta aberta no VSCode continuarão disponíveis.

Mais informações sobre como formatar o arquivo podem ser encontradas aqui.

Variáveis de ambiente

É possível definir variáveis de ambiente no arquivo .devcontainer. Para isso basta usar a chave containerEnv.

Mais detalhes e outras formas de setar variáveis de ambiente podem ser encontradas neste link.

Usando um Dockerfile

Ao iniciar um container em uma pasta que contenha um Dockerfile o VSCode irá exibir as seguintes opções:

Ao selecionar a opção "From a predefined container...", as imagens pré-definidas serão exibidas e o fluxo seguirá como explicado anteriormente.

Selecionando a opção de usar o Dockerfile, o container será construído de acordo com o arquivo e a pasta será montada dentro do container. Neste caso, qualquer imagem, tanto do registry público do docker quanto de algum registry privado que você tenha acesso, poderá ser utilizada.

Conclusão

O plugin DevContainer do VS Code é uma ferramenta poderosa que ajuda a garantir ambientes de desenvolvimento consistentes e isolados. Ao aproveitar as vantagens do DevContainer, é possível acelerar o processo de desenvolvimento, garantir a compatibilidade e facilitar a configuração e os testes de integração. Espero que este artigo tenha sido útil e que você possa aproveitar ao máximo o DevContainer em seu próximo projeto.

Descobriu algo novo, ou usa o plugin de uma forma diferente? Conhece algo que possa funcionar melhor do que o que foi apresentado aqui? Deixa um comentário para discutirmos todas as ideias.