--- title: "Capítulo 4. Mudar uma coisa sem quebrar tudo" url: "https://www.mikefluff.com/pt/read/nobody-writes-code/ch04" locale: "pt" author: "Mikhail Savchenko (Mike Fluff)" updated: "2026-10-10T17:48:25.825Z" book: "https://www.mikefluff.com/pt/books/nobody-writes-code" access: "free" alternates: - locale: "ru" url: "https://www.mikefluff.com/ru/read/nobody-writes-code/ch04" markdown: "https://www.mikefluff.com/ru/read/nobody-writes-code/ch04.md" - locale: "en" url: "https://www.mikefluff.com/en/read/nobody-writes-code/ch04" markdown: "https://www.mikefluff.com/en/read/nobody-writes-code/ch04.md" - locale: "pt" url: "https://www.mikefluff.com/pt/read/nobody-writes-code/ch04" markdown: "https://www.mikefluff.com/pt/read/nobody-writes-code/ch04.md" --- # Capítulo 4. Mudar uma coisa sem quebrar tudo *[Ninguém Mais Escreve Código](https://www.mikefluff.com/pt/books/nobody-writes-code)* Voltemos ao site do salão de manicure e imaginemos que ele já funciona há seis meses. Tem três mil clientes, doze manicures, os lembretes saem por SMS na véspera do atendimento, e uma vez por mês a contadora exporta uma planilha com os agendamentos e os pagamentos. Um dia a administradora do salão pede uma pequena melhoria: que a cliente possa informar vários telefones, porque algumas marcam horário para as filhas e querem receber os lembretes elas mesmas. O agente resolve em uns três minutos. No formulário aparece o botão “adicionar outro telefone”, no banco de dados aparece espaço para um segundo e um terceiro número, a administradora confere que tudo salva e abre e fecha a tarefa toda contente. Tudo funciona como foi pedido. Umas duas semanas depois descobre-se que os lembretes pararam de chegar a mais ou menos um terço das clientes. Mais uma semana, e uma das manicures liga para uma cliente no segundo número, que acaba sendo o do marido, e fica sabendo da vida conjugal da cliente mais do que ela gostaria. No fim do mês a exportação da contadora não abre: o programa que a contadora um dia configurou para processar a planilha esperava um único número na coluna “telefone” e não sabe o que fazer com uma lista. Nenhuma dessas quebras estava visível no momento em que a administradora conferiu o resultado, e todas foram causadas pela mesma mudança, que na tela parecia impecável. * * * Os desenvolvedores chamam uma mudança no código de diff, do inglês difference, “diferença”: é a lista das diferenças entre como o programa era antes da edição e como ficou depois, mais ou menos como o controle de alterações de um editor de texto, em que o que foi riscado aparece em vermelho e o que foi acrescentado, em verde. Quando você pede a um modelo que mude alguma coisa, ele produz exatamente uma lista de diferenças assim e se esforça para que ela seja boa: caprichada, clara, resolvendo a tarefa proposta. Por natureza, um modelo de linguagem resolve muito bem a tarefa “faça a mudança X”. A tarefa real de engenharia quase sempre é formulada de outro jeito: faça a mudança X de modo que, depois dela, o sistema inteiro continue íntegro. Entre essas duas formulações está quase toda a profissão, e o salão de manicure mostra onde. O telefone da cliente fica guardado no programa em muito mais de um lugar, mesmo que na tela pareça um único campo. Primeiro ele está gravado no banco de dados, e a maneira como o banco é organizado, que células existem e o que há em cada uma, chama-se esquema de dados. Antes o esquema tinha uma célula para o telefone; agora precisa de uma lista, e isso já é outro esquema. Depois é preciso decidir o que fazer com as três mil clientes cujo telefone já está gravado na célula antiga, e gravado de qualquer jeito: umas com o 8 na frente, outras com +7, e em alguns casos, na mesma célula, a observação “ligar depois das seis”. A transferência dos dados antigos para o novo esquema chama-se migração, e é uma das operações mais tensas do desenvolvimento, porque um erro nela não se corrige simplesmente voltando o código ao que era: os dados já foram mudados de lugar. Depois vem a lógica do próprio negócio, o que os desenvolvedores chamam de domínio. Para quem mandar o lembrete se há três telefones: para todos, para o primeiro, para o que está marcado como principal? Quem decide qual é o principal se a cliente não indicou? Um modelo a quem ninguém perguntou vai responder a essas perguntas em silêncio e de qualquer jeito, e no nosso caso o serviço de lembretes continuou procurando o telefone na célula antiga, que para parte das clientes ficou vazia depois da migração. O telefone da cliente é necessário também fora do site: o serviço de envio de SMS, a exportação da contadora e talvez mais alguma coisa de que a administradora já esqueceu pedem ao site o telefone da cliente por meio da chamada interface de programação, um conjunto de combinados sobre como um programa pede dados a outro e em que forma recebe a resposta. Antes a resposta era um número, agora é uma lista, e cada programa que não sabe disso quebra do seu jeito. Há ainda a questão das permissões. Antes a manicure via o telefone da cliente porque às vezes precisa avisar sobre uma remarcação. A manicure deve ver os três números, inclusive o do marido? Provavelmente não, mas ninguém escreveu essa regra, porque até hoje o segundo número não existia. E o telefone da cliente ainda aparece na agenda da manicure, na ficha da cliente, no painel da administradora, no e-mail de confirmação do agendamento e no recibo, e cada um desses lugares precisa aprender a mostrar uma lista ou a escolher um número dela. Restam as verificações. O programa tinha testes automáticos que verificavam se o telefone era salvo e se o lembrete saía, e eles tinham sido escritos para um único telefone. Se depois da mudança eles falharam, é uma boa notícia, porque foi assim que o sistema avisou do problema. Se o agente, ao ver os testes falhando, os ajustou para que passassem de novo, a notícia é ruim, e sobre isso haverá um capítulo à parte. O resultado é uma cadeia de sete elos: esquema de dados, migração, lógica, ligações com outros programas, permissões, telas, verificações. O pequeno pedido da administradora mexeu com os sete, e a mudança que o agente fez mexeu com dois. Qualquer nova capacidade de um programa, mesmo a mais modesta, altera uma rede conectada em que cada elo está ligado aos vizinhos, e mudar um elo sem olhar para os outros é deixar uma quebra que vai aparecer mais tarde e em outro lugar. * * * O problema em si é tão velho quanto a programação. Em 1978, numa conferência em Chicago, três pesquisadores, Stephen Yau, James Collofello e T. MacGregor, apresentaram um trabalho sobre o que chamaram de efeito ondulação: uma mudança numa parte do programa se espalha pelas demais como os círculos de uma pedra na água, e quanto mais complexo o programa, mais longe vão esses círculos. Eles chegaram a inventar um jeito de estimar de antemão até onde iria a ondulação de uma edição específica. Desde então, saber prever para onde vai a ondulação é considerado uma das principais marcas de um engenheiro experiente. O iniciante vê o lugar que pediram para mudar. O engenheiro experiente vê o que mais vai se mexer junto. Esse problema tem ainda uma formulação mais recente e mais cruel. Hyrum Wright, engenheiro do Google, observou que, se um programa tem usuários suficientes, alguém certamente vai depender de qualquer característica dele que se possa observar de fora, tenha ela sido prometida ou não. Ninguém prometeu fazer a exportação da contadora no formato “um telefone por coluna”, simplesmente saiu assim, mas a contadora se apoiava nisso, e a mudança quebrou um combinado que oficialmente não existia. Os programadores chamam isso de lei de Hyrum e se lembram dela toda vez que uma edição inofensiva quebra alguma coisa no departamento vizinho. * * * A ilustração mais cara de como é uma pequena mudança num sistema grande aconteceu no dia primeiro de agosto de 2012 com a empresa americana Knight Capital, então uma das maiores intermediárias da bolsa de valores. A Bolsa de Nova York estava lançando um novo programa para investidores de varejo, e a Knight escreveu código novo para ele. No sistema de negociação da empresa havia muito tempo um velho pedaço de código chamado Power Peg, que deixara de ser usado já em 2003, mas nunca fora apagado. Ele tinha um contador que acompanhava quantas ações de uma ordem já tinham sido compradas e parava o envio de instruções assim que a ordem era executada. Em 2005 esse contador foi transferido para outro lugar do programa, e ninguém pensou em verificar se o Power Peg continuava funcionando depois disso, porque ninguém o usava mesmo. O código novo, como a Comissão de Valores Mobiliários dos Estados Unidos apurou depois, reaproveitou o interruptor que antes ligava aquele pedaço antigo. Em si é uma escolha razoável: o interruptor existe, está livre, por que não usar. O código novo tinha de ser instalado em oito servidores. O técnico o instalou em sete. Ninguém percebeu, porque não havia nenhuma verificação que comparasse os oito servidores entre si. Na manhã do primeiro de agosto, quando o pregão abriu, o interruptor foi ligado, e em sete servidores começou a rodar o código novo, enquanto no oitavo acordou o velho Power Peg, que recebeu ordens reais de clientes e começou a executá-las, só que já sem o contador que um dia lhe mandava parar. Para executar 212 ordens de clientes, o sistema mandou ao mercado em quarenta e cinco minutos mais de quatro milhões de instruções e comprou e vendeu ao todo 397 milhões de ações. Quando foi parado, a empresa tinha perdido mais de 460 milhões de dólares, teve problemas com o capital próprio exigido por lei e, menos de um ano depois, fundiu-se com outra corretora e deixou de existir como empresa independente. Nessa história não há uma única decisão burra, se cada uma for olhada separadamente. O código novo, ao que tudo indica, foi escrito corretamente. Reaproveitar um interruptor livre é prática comum. O técnico errou como erram todas as pessoas. A catástrofe surgiu nas junções: entre a mudança de 2005 e o código que ninguém verificou depois dela, entre o código novo e o antigo que esqueceram de apagar, entre o interruptor e o seu significado anterior, entre oito servidores que deveriam ser iguais. Cada elo parecia em ordem isoladamente, e juntos eles derrubaram a empresa. * * * A Knight Capital quebrou em quarenta e cinco minutos, mas é mais comum a rede se romper devagar, e então isso parece mais uma doença crônica do que um acidente. Em junho de 2026 eu estava analisando a estrutura de uma empresa de software na qual, até então, tinham sido investidos cerca de um milhão e meio de dólares. Os donos tinham uma única queixa e a formulavam quase com as mesmas palavras: cada nova funcionalidade quebra uma antiga. A interface e a parte de servidor tinham virado, em alguns anos, um zoológico em que cada bicho tinha as suas manias, e ninguém sabia mais dizer onde ficava a fonte da verdade dos dados: o mesmo número vivia em três lugares e em cada um era um pouco diferente. Não encontrei ali nenhuma decisão ruim isolada. Havia centenas de mudanças razoáveis, cada uma feita sem perguntar o que se mexeria na vizinhança, e por um milhão e meio de dólares a empresa tinha comprado para si um sistema em que dava medo mexer. * * * Os modelos de linguagem são especialmente vulneráveis nesse ponto, e a razão é bem técnica. O modelo vê o que lhe mostraram: os arquivos que lhe passaram diante dos olhos, a descrição da tarefa, o resultado da última verificação. Todo o resto não existe para ele. Se o serviço de lembretes está em outro arquivo, a que o modelo não chegou, ele não sabe que o serviço lê o telefone da célula antiga. Se a exportação da contadora é feita por um programa separado no computador da própria contadora, o modelo nunca vai saber dele. Os bons agentes sabem procurar no projeto inteiro, e procuram melhor a cada ano, mas vão procurar o que lhes mandaram procurar e vão parar quando a tarefa parecer resolvida. Além disso, o modelo tem uma ideia muito clara de sucesso: a mudança pedida foi feita, as verificações visíveis passaram. Quando o agente escreve “pronto”, ele informa honestamente que a sua lista de diferenças terminou e não sabe nada sobre se o sistema terminou. Disso decorre uma distinção que considero uma das principais deste livro. O modelo otimiza a mudança atual e se esforça para fazê-la o melhor possível. O arquiteto, ou seja, a pessoa responsável pela estrutura do sistema como um todo, minimiza a desordem no sistema inteiro e pergunta antes de tudo o que mais vai se mexer se isto aqui for mexido. É possível ensinar o modelo a fazer essa pergunta, e adiante vou contar como, mas para isso alguém precisa saber que a pergunta existe. A maioria das pessoas que hoje se senta pela primeira vez para montar um programa com IA não sabe que essa pergunta existe, e a culpa não é delas: antes, para ficar sabendo, era preciso passar alguns anos escrevendo código e levando regularmente na cabeça.