Alexandre Costa

Categoria: Carreira & Reflexões

Carreira em tecnologia, liderança, aprendizado contínuo e reflexões pessoais.

  • Code review na era dos agentes: a revisão começa na especificação

    Este texto é uma releitura de um artigo que publiquei em 2019 (leia o original).

    Em 2019 eu escrevi um texto curto sobre o que tinha aprendido em 18 meses de code review. Na época eu estava numa empresa onde nenhuma linha entrava na branch principal sem passar por pelo menos outra pessoa, e confesso que no começo achei isso invasivo. Demorou pouco para eu perceber o contrário: eu aprendia mais com os comentários dos colegas do que com qualquer curso que já tinha feito.

    Sete anos depois, boa parte do código que passa por revisão não foi digitada por uma pessoa. Foi sugerida pelo Copilot, gerada por um agente a partir de uma issue ou montada a partir de um prompt. A conclusão a que cheguei é que a revisão mais importante deixou de acontecer no diff. Ela acontece antes, na especificação, e depois, em gates que nenhum humano precisa executar à mão.

    O que não mudou

    Code review continua sendo uma rua de mão dupla. Você revisa para aprender e para ensinar, não para julgar. O tom continua importando: “isso está errado” e “o que acontece aqui se a lista vier vazia?” apontam para o mesmo problema, mas só o segundo abre uma conversa. E o contexto continua sendo tudo. Revisar um diff sem entender o problema que ele resolve é ler a resposta sem saber a pergunta.

    O que mudou: o revisor virou o gargalo

    Antes, escrever código era a parte cara e revisar era a parte barata. Isso inverteu. Com agentes, uma pessoa abre em uma tarde a quantidade de pull requests que antes levaria uma semana. O código sai bem formatado, com nomes decentes e até com testes, e para na fila de revisão, porque a nossa capacidade de ler e entender não acelerou na mesma proporção. O revisor deixou de ser a segunda opinião e passou a ser, muitas vezes, a primeira pessoa que de fato leu aquele código. Se a gente tentar compensar isso só lendo mais rápido, o resultado é fadiga, e revisor cansado aprova qualquer coisa.

    A revisão começa na especificação

    Existe um detalhe que muita gente esquece: o modelo aprendeu com o código que leu. E nem todo código que ele leu está correto, seguro ou acessível. Sem orientação, o que sai é uma média de tudo o que existe por aí, com os mesmos vícios. A forma mais barata de mudar isso não é corrigir no diff, é dizer com clareza, antes, o que se espera.

    Por isso, se o código nasce de um prompt ou de uma spec, o prompt e a spec são código-fonte, e código-fonte passa por revisão. Nos projetos em que participo, versionamos as instruções que os agentes recebem, os arquivos de contexto do repositório e as specs que originam cada tarefa, e revisamos isso com o mesmo cuidado de um diff. Uma spec ambígua gera dez PRs ambíguos. Uma spec que esquece acessibilidade gera dez telas inacessíveis. Revisar a origem é corrigir uma vez em vez de dez, e é uma forma de ensinar o time inteiro de uma vez.

    Uma boa spec responde, no mínimo: qual problema de negócio estamos resolvendo, quais são os critérios de aceite, quais casos de borda importam, quais restrições de segurança, privacidade e acessibilidade valem, e o que não faz parte do escopo. Se a pessoa que pediu não consegue responder isso, o problema não é do modelo.

    Clean Code, Clean Architecture, SOLID e DDD só fazem sentido se você sabe defender

    Virou comum ver prompts do tipo “use Clean Architecture, SOLID e DDD”. O modelo obedece: cria camadas, interfaces, repositórios, agregados. O código fica com cara de bem feito. Mas cada uma dessas abordagens é uma troca. Clean Architecture compra isolamento ao custo de indireção. DDD compra alinhamento com o negócio ao custo de modelagem e de linguagem que precisa ser construída com quem entende a operação. SOLID levado ao pé da letra vira uma interface para cada classe. Nenhuma delas é grátis, e nenhuma serve para tudo.

    A minha regra é simples: só peça ao modelo uma metodologia, um framework ou uma técnica se você entende e está pronto para responder, numa revisão, por cada um dos prós e contras dela naquele contexto. Se a resposta para “por que esse agregado existe?” é “porque o agente criou”, o padrão virou cerimônia. Escrevi sobre isso em 2019, em O problema não é e nunca foi do DDD, e a IA só deixou o problema mais rápido de se reproduzir.

    Testes, mais do que nunca, são assunto de gente

    Quando o mesmo modelo escreve o código e os testes, os testes tendem a confirmar o que o código faz, não o que o negócio precisa. Eles passam, a cobertura sobe, e ninguém verificou se a regra estava certa. Por isso, testes precisam ser revisados com mais rigor do que nunca e, sempre que possível, escritos por pessoas, com apoio dos times de negócio. Os critérios de aceite da spec viram cenários de teste antes de virar código. Aí sim o agente pode implementar até tudo ficar verde, e o verde passa a significar alguma coisa.

    Gates determinísticos diminuem a fadiga da revisão

    A melhor forma de proteger a atenção de quem revisa é não gastar essa atenção com o que uma máquina verifica de forma determinística, sempre do mesmo jeito. O humano não deveria ser o primeiro a descobrir que o build quebrou ou que uma dependência tem vulnerabilidade conhecida. Os gates que eu considero mínimos:

    • Linters e formatadores, com as regras do time versionadas no repositório.
    • Análise estática de código e de segurança (SAST), incluindo dependências e segredos expostos.
    • Análise dinâmica (DAST) e verificações de acessibilidade automatizadas nas interfaces, sabendo que elas pegam só uma parte dos problemas.
    • Execução dos testes de unidade, integração e ponta a ponta, em cada etapa do desenvolvimento, não só no fim.

    E o mais importante: as mesmas regras compartilhadas em três lugares. Nos hooks do Git, para o desenvolvedor saber antes do commit. Nos hooks do harness do agente, para o próprio agente ser barrado e corrigir sozinho antes de abrir o PR. E no pipeline de CI/CD, como garantia final de que nada passou por fora. Quando a regra é a mesma nos três, o PR que chega para a pessoa já passou por tudo o que é mecânico, e a revisão humana pode se concentrar em intenção, domínio e risco.

    Modelos ajudam a revisar, mas nunca dão a palavra final

    Eu uso modelos na revisão, sim. Mas com duas condições. A primeira: o modelo que analisa precisa ser diferente do que gerou o código. Um modelo revisando o próprio trabalho tende a concordar consigo mesmo e a repetir os mesmos pontos cegos. A segunda: a análise do modelo é apoio, nunca a revisão final. Quando um time trata a aprovação automática como suficiente, o que acontece é que um modelo gera, outro aprova e ninguém entende o que foi para produção.

    O que só uma pessoa pega

    • Intenção. O código faz o que a spec pediu. Mas a spec pediu a coisa certa?
    • Domínio. A regra que só faz sentido para quem conhece a operação, o caso de borda que só aparece no fim do mês, o campo que significa outra coisa naquele sistema legado.
    • Acessibilidade. Esse é o ponto que mais me toca, como pessoa com deficiência visual e usuário de leitor de tela. Código gerado produz interfaces que parecem corretas e que, com frequência, são inutilizáveis com NVDA: botões sem nome acessível, modais que não prendem o foco, ordem de tabulação sem sentido. O modelo aprendeu com uma web que, em sua maioria, é inacessível. Ferramenta automatizada ajuda, mas não substitui alguém testando de verdade.
    • Segurança contextual. Não é a injeção de SQL, que o scanner pega. É saber que aquele endpoint não pode expor aquele campo porque existe um contrato com uma área regulada.

    O que eu levo de 2019 para 2026

    Code review nunca foi sobre encontrar erros. Sempre foi sobre construir entendimento compartilhado. Em 2026, esse entendimento começa na especificação, é protegido por gates determinísticos e termina numa pessoa que sabe responder por cada decisão que foi para produção. A ferramenta que gera o código mudou; a responsabilidade de entender continua sendo nossa.

    E no seu time, como está isso? Vocês já revisam specs e testes com o mesmo cuidado do código, ou a revisão ainda começa e termina no diff? Me conta nos comentários.

  • Quais as atribuições de um desenvolvedor em 2026?

    Este texto é uma releitura de um artigo que publiquei em 2019 (leia o original). Sete anos depois, o que mudou?

    Fala galera!

    Em 2019 eu escrevi que a gente tinha deixado de ser “atendedor de pedidos” fazia tempo. Que o desenvolvedor participava de todo o ciclo: da reunião de definição técnica até a monitoração em produção, passando por testes automatizados, pipelines e ambientes montados por código. Terminei o texto falando de métricas e de “times com atitude”, em que ninguém é dono exclusivo de uma atividade.

    Reli o artigo esses dias e a sensação foi curiosa: tudo aquilo continua valendo. Só que a régua subiu. E subiu por um motivo que em 2019 eu não previa com essa velocidade: a inteligência artificial entrou no dia a dia de quem escreve software.

    O que continua igual

    A ideia central do texto de 2019 era simples: o desenvolvedor é responsável pela entrega inteira, não só pelo trecho de código que digitou. Isso não mudou. Se algo quebra em produção às três da manhã, continua sendo problema do time, e não de um “pessoal da infra” que ninguém sabe quem é.

    Automação de testes, deploy contínuo, infraestrutura como código, observabilidade: em 2019 isso era diferencial. Em 2026 é o mínimo. Quem ainda faz deploy na mão está pagando um preço alto e nem sempre percebe.

    E as métricas de uso, que na época eu descrevia como um hobby com dados analíticos, hoje são parte da conversa de produto. Saber qual funcionalidade é usada e qual chamada de API está lenta continua sendo atribuição de quem constrói.

    O que mudou: o gargalo agora é a revisão

    Aqui está a virada. Com o Copilot e os agentes de código, escrever a linha deixou de ser a parte cara do trabalho. Eu descrevo o que quero, o agente propõe uma implementação, roda os testes, ajusta e me devolve um pull request. Em muitos casos, o que levava uma tarde agora leva o tempo de um café.

    Só que revisar código ficou pesado. A gente não consegue revisar na mesma velocidade em que o código é gerado. A revisão virou o gargalo, e por isso ter bons processos de validação desse código deixou de ser detalhe: testes, linters, análise estática, análise de segurança. Tudo isso rodando antes de um humano abrir o diff.

    Isso não significa abrir mão de entender o código. Ainda precisamos saber o que foi feito e como foi feito. A diferença é que a revisão humana passa a focar nos pontos específicos e principais — regra de negócio, segurança, decisões de arquitetura — e deixa para as ferramentas o que pode ser verificado automaticamente.

    E automação de testes hoje não é opcional. A gente entrega mais de uma vez por dia. Se cada entrega tiver de esperar um time de qualidade rodar um novo ciclo inteiro de testes, o produto não sai do lugar. O teste automatizado valida, no mínimo, o caminho crítico da aplicação: garante que nada impede a conversão de um lead em cliente, de um pedido em faturamento.

    Construir o harness virou ofício

    Se em 2019 eu dizia que a gente participava de todo o ciclo, em 2026 eu diria que a gente orquestra o ciclo. E orquestrar tem nome: harness. A gente se especializou em montar o conjunto de agentes e subagentes, skills, tools, hooks e demais recursos que os agentes de codificação oferecem, e em otimizar tudo isso para o nosso processo e, sim, para o nosso projeto. Não existe configuração genérica que sirva para todo mundo.

    Isso inclui orquestrar as demandas entre os agentes, desenhar os loops de trabalho e, principalmente, medir o consumo de tokens. Cada chamada a um modelo tem preço, e um loop mal feito pode consumir em uma hora o orçamento do mês. Gerir esse custo e demonstrar o retorno sobre o investimento é fundamental. Se você não consegue mostrar quanto a IA custa e quanto ela entrega, alguém vai decidir por você.

    Outras atribuições que ganharam peso

    • Escrever a especificação antes do código. O tal spec-driven development. Se o agente vai implementar a partir de uma descrição, a qualidade dessa descrição é o que define a qualidade da entrega. Especificar bem virou habilidade técnica, não burocracia de gerente.
    • Avaliar a saída dos modelos. Quando a aplicação que você constrói usa um modelo de linguagem, “funciona” deixa de ser binário. Você precisa de conjuntos de avaliação, métricas de qualidade da resposta, testes que detectam quando o modelo começou a alucinar depois de uma atualização. Isso é teste automatizado de 2026.
    • Observar a IA em produção. Rastrear prompts, tokens, tempo de resposta, taxa de fallback, o que o agente decidiu fazer e por quê. A observabilidade que eu defendia em 2019 para APIs agora precisa cobrir o raciocínio da aplicação.

    Na mesa do produto, não no balcão de pedidos

    Em 2019 eu dizia que tínhamos deixado de ser tiradores de pedido. Em 2026 isso ficou ainda mais literal. A gente senta junto com os stakeholders para ajudar a definir o plano de produto. Com base nas métricas de negócio, ajuda a decidir se uma nova funcionalidade é viável e rentável ou não. Quando gerar código fica barato, a pergunta mais cara passa a ser o que vale a pena construir.

    Para isso, a gente acompanha as tendências e conhece os jargões do negócio. Afinal, a spec que vai guiar o agente precisa usar a tão famosa linguagem ubíqua que Eric Evans descreve no livro Domain-Driven Design. Se o time técnico e o time de negócio não falam a mesma língua, o agente vai implementar com perfeição a coisa errada.

    Acessibilidade é atribuição de todo mundo

    Tem um ponto que em 2019 eu deixei de fora e hoje não deixo mais. Eu sou pessoa com deficiência visual e uso leitor de tela o dia inteiro, inclusive para revisar o que os agentes de código me entregam. Sei na prática que acessibilidade tratada como “fase final” vira acessibilidade que não acontece.

    E aqui a IA ajuda e atrapalha ao mesmo tempo. Ajuda porque o agente consegue gerar componentes com semântica correta, rótulos e navegação por teclado se você pedir. Atrapalha porque, se você não pedir, ele reproduz o padrão médio da internet, que é ruim. A diferença está na especificação e na validação, que são justamente as atribuições que citei acima. Quem escreve a spec, quem monta os testes automatizados de acessibilidade e quem aprova o pull request decide se a pessoa que usa leitor de tela vai conseguir usar o produto. Não dá mais para terceirizar isso para um especialista no fim do projeto.

    Times com atitude, versão 2026

    Encerrei o texto de 2019 dizendo que a gente não teria mais “donos” de atividades e precisaria de times com atitude. Sete anos depois, acho que acertei o diagnóstico e errei a escala. Não é só que o dev faz um pouco de infra e um pouco de produto. É que o dev agora coordena ferramentas que fazem parte do trabalho por ele, e a atitude que importa é a de quem assume responsabilidade pelo resultado mesmo quando não digitou cada linha.

    Atitude em 2026 é dizer “esse código foi gerado, mas eu entendo o que ele faz e respondo por ele”. É perguntar quanto custa antes de colocar um agente em loop. É recusar um componente bonito que não funciona no teclado. É medir a saída do modelo em vez de confiar no exemplo que funcionou na demo.

    O que não mudou nada é a pergunta de fundo: o que é uma atribuição justa? Continuo achando que existem vagas pedindo um profissional impossível pelo salário que querem pagar. Mas também continuo achando que quem se dispõe a enxergar o ciclo inteiro, e agora a orquestrar o ciclo inteiro, é quem torna a operação viável, especialmente em times pequenos.

    E você? O que virou sua atribuição nesses últimos anos que em 2019 nem existia?

    Até a próxima!

  • Quais as atribuições de um desenvolvedor em 2019?

    Este artigo foi publicado em 2019. Ferramentas e versões citadas podem ter mudado desde então; a reflexão permanece.

    Fala galera! Recentemente palestrei sobre empregabilidade de pessoas com deficiencia, mas um dos tópicos que comentei me remeteu a algo muito interessante que vem acontecendo com nosso mercado de trabalho. Logicamente que existem os processos de recrutamento sem noção e que pedem um profissional impossível de se encontrar ao preço que eles querem bancar, mas na verdade quais são as atribuições, justas, de um desenvolvedor nos nossos dias? A muito tempo deixamos de ser apenas os atendedores de pedidos. Não apenas recebemos uma demanda e a codificamos da melhor forma com a melhor qualidade, mas também automatizamos testes, enviamos os códigs para um ou mais ambientes, os quais muitas vezes os momntamos também de forma automatizada e logicamente nos empenhamos em sermos os mais ágeis possível na solução dos problemas que infelizmente só foram detectados em produção. Ou seja estamos em todo o ciclo do desenvolvimento participando desde as reuniões de definições técnicas do início do projeto até a monitoração da nossa entrega em produção. Em empresas maiores você acaba dividindo estas atribuições com outros papéis, arquitetos, profissionais de infra, etc. mas em empresas menores e principalmente nas Startups ter esta dedicação é mais que desejável, é o que acaba tornando a operação via’vel nos primeiros dias sem clientes. E o que podemos fazer para ir além? Venho estudado muito sobre métricas, tanto do ponto de vista de analisar como minha solução está performando tecnocamente, quanto o quanto ela está atingindo os clientes. Tenho brincando com o ‘dados analíticos de nossos usuários e verificando de forma mais objetivas porque determinada funcionalidade é mais ou menos utilizada, ou quais conjuntos de chamadas a API trazem menor tempo de resposta, ou quais dados nm são tão utilizados assim. Isto tem me trazido insights bem interessantes de possível próximos passos e como otimizar o tempo do time naquilo que realmente traz valor. Acredito que cada vez mais isto será papel do time como um todo, em que muito tempo não teremos mais “donos” de atividades, e precisaremos cada vez mais de times com atitude. E você? O que tem feito de diferente e que virou sua atribuição? Até a próxima!
  • O dia em que conheci Satya Nadella

    O dia em que conheci Satya Nadella

    Este artigo foi publicado em 2019. Ferramentas e versões citadas podem ter mudado desde então; a reflexão permanece.

    Fala galera! Foi uma semana muito intensa com viagens, palestra e uma foto que marca um momento tão importante para minha vida pessoal e profissional. Na última terça-feira dia 12 ocorreu em São Paulo o evento Microsoft AI+ Tour que teve como keynote o CEO Satya Nadella que trouxe em seu discurso muita inspiração e insights sobre as oportunidades que se abrem quando se une vontade e tecnologia. Ele reforçou muito um conceito o qual ele aplica diariamente na Microsoft a Tech Intensity, ou seja, não basta termos a tecnologia a disposição, temos de ter intensidade em aplicaça-la. Mas o dia só estava começando eu nem imaginava o quanto ele poderia melhorar. Participei deste evento pois tive a honra de ser convidado, juntamente com mais nove MVPs, a partificar de uma foto com o Satya. Seria algo muito rápido, afinal a agenda de um CEO é realmente controlada minuto a minuto. Na hora de nos posicionarmos para recebe-lo fui colocado estratégicamente como primeiro da fila, e ao ouvir que ele havia entrado na sala só tive uma reação a de extender minha mão para cumprimentá-lo e ao perceber que ele estava próximo dizer “Thank you for changing my life!” (Obrigado por mudar minha vida). Após cumprimentar todos na sala, e nos posicionarmos como haviamos ensaiado duas vezes, afinal o tempo era nosso inimigo, foram tiradas algumas fotos e logo após ele novamente se direcionou a mim perguntando quais tecnologias eu trabalhava. Falei que usava o Visual Studio, Visual Studio Code e Azure e ele me perguntou sobre a acessibilidade. Relatei que els haviam melhorado muito nos últimos anos, que me sentia satisfeito e que eles estavam no caminho certo. Logicamente que o pouco tempo que eu teria não iria chorar as pitangas do portal do Azure. Ele disse que sabe o quão importante é ter ferramentas acessíveis e que o desafio dlees atualmente é manter a consistencia, ou seja, o que estiver bom continuar bom e introduzir novas melhorias. Ele me cumprimentou novamente e aos demais participantes apenas perguntou quais as tecnologias. Coisas que gostaria de ressaltar: é impressonante a simplicidade e simpatia do Satya. Ele estava a todo momento sorrindo, e posteriormente ouvindo como como foi a passagem dele no Brasil só aumentou minha adimiração pelo mesmo. A energia naquela sala realmente mudou desde a hora que ele entrou, e meu dia foi baseado na ansiedade de receber aquela foto e poder postar. A segunda coisa é o quanto ele onhece o seu público, seja ele em qual seja o ambiente. Ele deu uma visão muito boa de negócios para a Inteligencia Artificial, foco claro do evento, mas conseguiu flar de tecnologia com os MVPs perguntando das das ferramentas que usavamos e fazendo comentários rápidos sobre as mesmas. Depois da foto ele ainda teve uma reunião com todos os funcionários da Microsoft Brasil, falou com alunos de escola pública, deu uma palestra para participantes de uma ONG e a noite ainda viajaria para Colombia. E mesmo assim, em todos os momentos ele estava sempre sorrindo, sempre cumprimentando a todos e mesmo assim ele conseguiu nos atender, e dedicar 1/5 do tempo que ele tinha conosco falando comigo. Sem sombra de duvidas é um dos dias mais importantes da minha vida e me mostra que não importa quantos degrais subamos, quando olharmos ao redor temos de ver a todos com o mesmo tamanho pois subir não quer dizer ser melhor. Áté a próxima!

  • O que aprendi nos últimos 18 meses com Code Review

    Este artigo foi publicado em 2019. Ferramentas e versões citadas podem ter mudado desde então; a reflexão permanece.

    Fala galera! Já durante o processo para entrar para ArcTouch já tive meu primeiro contato com a cultura de Code Review e esta é uma prática muito importante de nosso processo. Nenhum código deveria ser integrado sem antes passar por pelo menos um outro desenvolvedor, e em tarefas de desenho ou atualização de User Interfaces de um designer (com anexos dos screenshots). Em um primeiro momento achei isto um pouco invasivo, e de certa forma, até um pouco preocupante já que alguém estaria criticando diretamente o meu trabalho, o código que fiz. Mas o efeito é totalmente o contrário. Quando comecei a eceber os primeiro feedback sobre meu código percebi algumas lacunas na forma de pensar para resovler um problema. Muitas vezes estamos tão preocupados em primeiro entregar a solução, que não nos atentamos prática de refatorar o nosso código para que ele seja de melhor qualidade. Percebi também que eu tinha gaps de testes, que existem áreas que eu preciso melhorar meu feramental, ou seja estou crescendo muito como profissional com as dicas que vim recebendo no caminho. E isto é uma rua de mão dupla. Toda vez que vejo um código penso em como consigo tornar o trabalho dos meus pares ainda melhor,dando uma dica do que sei, indicando um problema que não havia sido percebido. O github torna este processo muito agradável. E tenho aprendido cada vez mais a fazer melhores reviews. Inclusive se quiserem fazer qualquer tipo de comentários lá nos meus repositórios, por avor fiquem a vontate. Até amanhã!

  • O green field de cada dia nos dai hoje!

    Este artigo foi publicado em 2019. Ferramentas e versões citadas podem ter mudado desde então; a reflexão permanece.

    Fala galera! Você foi alocado para um novo projeto e quando se depara com o código, que tem alguns débitos técnicos, qual sua primeira reaçao? Sem sombra de duvidas vvocêvai pensar que se você estivesse lá desde o começo teria feito tudo diferente, a arquitetura estaria melhor, o código melhor implementado seguindo as boas práticas, tudo aquilo que manda as boas práticas que estudamos todos os dias. Já parou par para pensar que esta situação pode ser a mesma para quem herdar seu projeto atual? Muitas vezes temos a sensação que se pudessemos voltar no tempo fariamos tudo diferente. E provavelmente com o conhecimento do que houve, caso as teorias de que não é possível se mudar a linha do tempo, e acabariamos na mesma situação. Ok! Mas então onde você quer chegar com este post? Você está se perguntando. Simplesmente porque, lembrando de uma palestra do meu amigo Eric Lemes, no TDC acho que em 2014, ele falou exatamente sobre isto. Por que ao invés de reclamarmos dasituação atual não tentamos melhorá-la? Por que não topar o desafio de refatorar o código, matar os débitos técnicos e manter tudo funcionando, e quem sabe deixar algo melhor pro próximo amigo que herdar o projeto? Pareceu interessante? Se sim, acredito que você deveria tomar algumas providencias: Utilizar alguma ferramenta de análise estática, Sonarqube por exemplo, para que os problemas sejam catalogados e vocêpossa acompanhar a evolução. Lógico que você já faz testes automatizados, e eles estão rodando sem erros, mas no caso disto não estar acontecendo ainda é uma boa oportunidade. Escreva o teste para a funcionalidade, faça as alteraç oes e confirme que ela continuará funcionando. Colocado isto em prática, caso você não faça isto ainda, coloque estes passos como parte da sua integração contínua. Ter este feedback a cada push é muito ”util e ajuda bastante o code review e a cadencia do projeto. Faça a experiencia e depois me diga se não é tão reconfortante quanto a da construção de um bom projeto do zero? PS: Saiba que o código que voc escreveu ontem já é legado. Se você não pratica as técnicas que cito aqui, provavelmente me pouco tempo você estará na situação inicial do post. Até amanhã!

  • Continuando o papo sobre hype

    Este artigo foi publicado em 2019. Ferramentas e versões citadas podem ter mudado desde então; a reflexão permanece.

    Fala galera! Continuando os desabafos do post de ontem gostaria de esclarecer que o título, propositalmente polemico, reflete o que eu penso das tecnologias que citei dentro do artigo. As discussões no Twitter foram bem interessantes e lá coloquei outros pontos que também irei colocar aqui. Em primeiro lugar sou tão contra o over engineering quanto ao, como chamei no Twitter, “meter o loco” e ver no que vai dar. Infelizmente tudo é questão de interpretação e as pessoas nem sempre tem o bom senso de entender que um MVP, uma primeira versão de um produto, não tem necessariamente de ser uma versão final, mas tem de sr algo que quando entregue tenha toda a qualidade. Ninguém fará o teste do seu produto por você se encontrar bugs, ningu’m voltará a seu site se ao entrar no lin kde convite ou de uma divulgação em rede social o servidor cair. Somos responsáveis não só por realizarmos o sonho de nosso clinet de entregar algo funcionando e atendendo ao negócio, somos responsáveis pela continuidade deste negócio com base na qualidade de nossas entregas. E não vejo nenhuma das siglas e práticas sendo utilizadas de forma isoladas. DDD me dará a melhor forma de modelar o negócio para um produto digital, onde conhecerei os processos e os mapiarei da melhor forma dentro dos bounded contexts. Estes bounded contexts podem estar na mesma aplicação ou dividiso em serviços menores, ou seja, bounded contexts é uma técnica maravilhosa de discovery e implementação de micro serviços. Só conseguirei ter isto tudo funcionando a pleno vapor se utilizar uma boa estratégiade testes, preferencialmente automatizados e desde o início, o TDD, e como me comunicarei com meus usuários, terei muito material para escrever testes de aceitação com BDD. Juntando todas estas peças em uma esteira de etrega contínua, automação, infra como código e tudo mais, encontramos o DEVOPS. A única coisa que não concordo, e por favor se vocêfaz isto pare agora, é achar que todo o novo projeto que vvocêvai começar já tem de ter isto. Se vocêsabe que precisará de tudo isto, em uma equipe madura e que já tem experiencia, parabéms, mas caso contrário pense: vvocêseria cliente de um médico com uma ‘nova técnica que ele aprendeu em um congresso? Se vocênão arriscaria sua vida nesta experiencia, por que cargas d’água o seu cliente tem de pagar pelo seu teste de experiencia do hype no projeto dele? Vamos ser mais conscientes, vamos entregar mais valo em nossas aplicações, vamos estudar e entender as tendencias do mercado, e vamos aplicar de forma mais efetiva aquilo que aprendemos. Até amanhã!

  • O problema não é e nunca foi do DDD

    Este artigo foi publicado em 2019. Ferramentas e versões citadas podem ter mudado desde então; a reflexão permanece.

    Fala galera! Quando Evans cunhou o termo Domain Driven Design, escreveu aquele livro super dificil de se ler, tenho total certeza de que ele não imaginava a revolução, e a confusão, que ele estava criando. Nossa área é muito movida pelo hype e os desenvolvedores tendem a achar que uma nova tecnologia, metodologia, técnica ou framework vem para substituir o que existia e não paa complementá-las. Hoje é dificil pedir em uma entrevista para o candidato fazer uma simples tela de soma de dois valores simplesmente porque em um projeto, que não dev3ria ter mais do que 00 linhas vamos encontrar misturados DDD, CQRS, Event Sourcing e por muito pouco isto não estará sendo construído em cima de um cluster kubernets na nuvem. Isto porque é legal. Isto é porque a internet está cheia de palestras e artigos dizendo como os sistemas deveriam se modelados e entregues. Isto porque os casos de sucesso de Amazon, Facebook, NetFlix e Uber tem de ser replicados por todos os cantos. Pera lá! Comecei minha carreira desenvolvendo em Clipper. Atendi desde de lojas de bairo até as finadas locadoras. Máquinas físicas, o hardware mais modesto que conseguia montar com o orçamento que tinha, backups em disquete, os quais provavelmente não iriam funcionar. Sabe por que? Era o que atendia ó negócio. Um dos maiores defeitos de nossa área é nosso ego. Sim TI deixou de ser uma área utilitária para ser estratégico, em muitos casos o core do negócio. Mas vejam só, se somo o core do negóio, o que é mais importante? Isto aí o negócio. Fazemos muito over engineering. Achamos que o sistem que estamos iniciiando hoje já tem de sair de fábrica atendendo um bilhão de requisições. Apesar de estarmos fazendo o CRUD das primeiras tabelas j’temos de pensar em como distribuir isto em micro serviços, e daqui a 3 meses quando o dinheiro que o tio do CEO da startup que nos contratou falar que não vai conseguir mais dar dinheiro porque até o momento não viu uma tela vamos achar que ele éstá errado em não acreditar, o pir não nos negócios, mas em nosso sistema. Cansei de ver em foruns a pergunta: mas em DDD onde eu coloco tal dependencia. Em micro serviços como faço sei lá o que. Amigos, se vocênão conseguem sozinhos responder estas perguntas, você conseguem me jurar queo problema é o DDD ou o micro serviço? Vamos começar menos e entregar mais ao invés de comecár mais e entregar menos. Aprenda a fazer um código limpo, aprenda a fazer uma arquitetura desacoplada, aprenda a tirar o mair proveito do framework que está a sua disposi’~ao, automatize a entrega, tenha bos práticas de code review, versionamento. Saiba como realmente funciona o banco de dados que vvocê. Isto sem duvidas vai te guiar aquilo que DDD micro serviços, 12 factors app e tudo mais te diz pra fazer. Até amanhã!

  • Entenda o seu fluxo de energia

    Este artigo foi publicado em 2019. Ferramentas e versões citadas podem ter mudado desde então; a reflexão permanece.

    Fala galera! Tenho postado diariamente e tenho de confessar que há dias, como o de ontem, em que é dificil entrar aqui e escrever alguma coisa. Isto porque para que consigamos concluir qualquer atividade precisamos de dois ingredientes: tempo e energia. Acontece que somos negligentes com o tempo e dificilmente entendemos nosso fluxo de energia, e a combinação destes dois fatores nos fazem procrastinar em nossas atividades e dificultam demaisalcançarmos nossos objetivos. Mas então o que é este tal de fluxo de energia? Sabe aquela pessoa que diz que é mais noturna? Ou aquelas pessoas que dizem que acordam pilhadas? Nosso corpo tem uma quantidade diária finita de energia, quje pode se apresentar logo pela manhà ou receber uma turbinada a tarde, ou pior a noite. Quando entendemos quando estamos mais energizados fica fácil direcionar as atividades que demandam mais de nossa energiap ara estes periodos. Sempre fui uma pessoa noturna mas trabalhar em um regime de horário rígido teve de me fazer mudar um pouco. Acordo pilhado, utilizo esta energia para programar meu dia, e distribuo o restante da energia pelo dia. Neste horáril, que estou escrevendo agora, estou cansado e é por isto que vou tentar mudar minha rotina de escrita para amanhã. Veremos se os próximos posts, provavelmente da próxima semana, serão melhores. Até amanhã!

  • Não somos como as máquinas que controlamos

    Este artigo foi publicado em 2019. Ferramentas e versões citadas podem ter mudado desde então; a reflexão permanece.

    Fala galera! Hoje estou un pouco mais cansado e por isto deixo a reflexão: Diferente de nossos computadores precisanos de pausas. R nesno eles ten rotinas de manutenção. Até amanhã!