Rich Hickey e Clojure: Simplicidade, Imutabilidade e Melhores Padrões

Por que a complexidade continua vencendo em projetos reais

O software raramente fica complicado de uma vez. Ele chega lá por uma decisão “razoável” de cada vez: um cache rápido para cumprir um prazo, um objeto mutável compartilhado para evitar cópias, uma exceção às regras porque “este é especial”. Cada escolha parece pequena, mas juntas elas criam um sistema onde mudanças parecem arriscadas, bugs são difíceis de reproduzir e adicionar funcionalidades começa a levar mais tempo do que construí-las.

A complexidade vence porque oferece conforto de curto prazo. Frequentemente é mais rápido conectar uma nova dependência do que simplificar uma existente. É mais fácil corrigir estado do que perguntar por que o estado está espalhado por cinco serviços. E é tentador confiar em convenções e conhecimento tribal quando o sistema cresce mais rápido que a documentação.

O que este artigo é (e o que não é)

Isto não é um tutorial de Clojure, e você não precisa conhecer Clojure para tirar proveito. O objetivo é emprestar um conjunto de ideias práticas frequentemente associadas ao trabalho de Rich Hickey — ideias que você pode aplicar a decisões de engenharia do dia a dia, independentemente da linguagem.

Por que os padrões padrão importam mais do que você imagina

A maior parte da complexidade não é criada pelo código que você escreve deliberadamente; é criada pelo que suas ferramentas tornam fácil por padrão. Se o padrão é “objetos mutáveis por toda parte”, você acabará com acoplamento oculto. Se o padrão é “o estado vive em memória”, você vai ter dificuldades com depuração e rastreabilidade. Padrões moldam hábitos, e hábitos moldam sistemas.

Focaremos em três temas:

• Simplicidade: não menos funcionalidades, mas menos partes móveis e menos casos especiais.
• Imutabilidade: tratar dados como valores que não mudam, para que você possa raciocinar sobre eles.
• Melhores padrões: escolher padrões que tornam a opção segura e previsível a mais fácil.

Essas ideias não eliminam a complexidade do seu domínio, mas podem impedir que seu software a multiplique.

Rich Hickey e o que Clojure buscou consertar

Rich Hickey é um desenvolvedor e designer de software de longa data, mais conhecido por criar Clojure e por palestras que desafiam hábitos comuns de programação. Seu foco não é seguir tendências — é as razões recorrentes pelas quais sistemas se tornam difíceis de mudar, difíceis de entender e difíceis de confiar à medida que crescem.

O que é Clojure (visão geral, sem jargão)

Clojure é uma linguagem de programação moderna que roda em plataformas conhecidas como a JVM (runtime do Java) e JavaScript. Foi projetada para funcionar com ecossistemas existentes enquanto incentiva um estilo específico: representar informação como dados simples, preferir valores que não mudam e manter “o que aconteceu” separado do “que você mostra na tela”.

Você pode pensar nela como uma linguagem que te empurra em direção a blocos de construção mais claros e para longe de efeitos colaterais ocultos.

Os problemas que ela foi criada para reduzir

Clojure não foi criada para tornar scripts pequenos mais curtos. Foi direcionada a dores recorrentes de projeto:

• Complexidade crescente por estado compartilhado: quando muitas partes de um sistema podem modificar os mesmos dados, bugs se tornam dependentes de temporização e difíceis de reproduzir.
• Acoplamento forte entre dados e comportamento: quando informação fica trancada dentro de objetos ou classes, reutilizar fica mais difícil e mudanças se espalham pelo código.
• Dores de cabeça com concorrência: conforme sistemas adicionam jobs de background, filas e trabalho paralelo, “quem mudou o quê, quando?” vira um problema diário.

Os padrões de Clojure empurram para menos partes móveis: estruturas de dados estáveis, atualizações explícitas e ferramentas que tornam a coordenação mais segura.

Útil mesmo que você nunca adote Clojure

O valor não se limita a trocar de linguagem. As ideias centrais de Hickey — simplificar removendo interdependências desnecessárias, tratar dados como fatos duráveis e minimizar estado mutável — podem melhorar sistemas em Java, Python, JavaScript e além.

Simplicidade: não “fácil”, mas menos partes móveis

Rich Hickey traça uma linha nítida entre simples e fácil — e é uma linha que a maioria dos projetos ultrapassa sem perceber.

Simples vs. fácil (com exemplos do dia a dia)

Fácil é sobre como algo parece agora. Simples é sobre quantas partes tem e quão entrelaçadas elas estão.

• Miojo é fácil. Um ensopado básico pode ser simples: poucos ingredientes, uma panela, nada escondido.
• Um controle remoto com 60 botões pode tornar uma função “fácil” (está ali), mas não é simples. Um controle com 6 botões claros é mais simples, mesmo que leve um minuto para aprender.

No software, “fácil” frequentemente significa “rápido de digitar hoje”, enquanto “simples” significa “mais difícil de quebrar no mês que vem”.

Como “fácil agora” cria complexidade futura

Times frequentemente escolhem atalhos que reduzem atrito imediato mas adicionam estrutura invisível que precisa ser mantida:

• “Vamos só adicionar uma flag.” Agora toda feature precisa considerar essa flag.
• “Vamos armazenar o valor computado para economizar tempo.” Agora você tem que mantê-lo sincronizado por caminhos de código.
• “Podemos consertar na UI.” Agora a mesma regra de negócio existe em vários lugares.

Cada escolha pode parecer velocidade, mas aumenta o número de partes móveis, casos especiais e dependências cruzadas. É assim que sistemas ficam frágeis sem nenhum erro dramático isolado.

Velocidade não é o mesmo que simplicidade

Entregar rápido pode ser ótimo — mas velocidade sem simplificar geralmente significa que você está tomando empréstimo sobre o futuro. Os juros aparecem como bugs difíceis de reproduzir, onboarding demorado e mudanças que requerem “coordenação cuidadosa”.

Um checklist rápido para complexidade acidental

Faça estas perguntas ao revisar um design ou PR:

• Introduzimos novos modos, flags ou ramos de configuração?
• Estamos fazendo cache ou duplicando dados que precisam ser mantidos consistentes?
• Vários módulos precisam mudar juntos por um único comportamento?
• A regra está implementada em mais de um lugar?
• Um novo colega preveria como isso funciona sem explicação extra?

Estado: o multiplicador silencioso da complexidade

“Estado” é simplesmente as coisas no seu sistema que podem mudar: o carrinho de compras de um usuário, o saldo de uma conta, a configuração atual, em que passo um workflow está. A parte complicada não é que a mudança exista — é que cada mudança cria uma nova oportunidade para discordância.

Quando dizem “estado causa bugs”, normalmente significam isto: se a mesma informação pode ser diferente em momentos distintos (ou em lugares distintos), seu código tem que responder constantemente: “Qual versão é a real agora?” Errar essa resposta produz erros que parecem aleatórios.

Mutabilidade: mudança que você não consegue ver

Mutabilidade significa que um objeto é editado no lugar: a “mesma” coisa se torna diferente ao longo do tempo. Isso parece eficiente, mas torna o raciocínio mais difícil porque você não pode confiar no que viu um momento atrás.

Um exemplo próximo é uma planilha ou documento compartilhado. Se várias pessoas podem editar as mesmas células ao mesmo tempo, seu entendimento pode ser invalidado instantaneamente: totais mudam, fórmulas quebram, ou uma linha desaparece porque alguém reorganizou. Mesmo sem intenção maliciosa, a natureza compartilhada e editável é o que cria confusão.

O estado do software se comporta da mesma forma. Se duas partes do sistema leem o mesmo valor mutável, uma parte pode silenciosamente mudá-lo enquanto a outra continua com uma suposição desatualizada.

Por que depurar fica tão doloroso

Estado mutável transforma depuração em arqueologia. Um relatório de bug raramente diz “os dados foram alterados incorretamente às 10:14:03”. Você só vê o resultado final: um número errado, um status inesperado, uma requisição que falha só às vezes.

Porque o estado muda ao longo do tempo, a pergunta mais importante torna-se: qual sequência de edições levou até aqui? Se você não pode reconstruir essa história, o comportamento fica imprevisível:

• A mesma ação produz resultados diferentes dependendo da temporização.
• Correções “funcionam na minha máquina” mas não em produção.
• Adicionar logging altera a temporização e o bug desaparece.

É por isso que Hickey trata o estado como um multiplicador de complexidade: uma vez que dados são compartilhados e mutáveis, o número de interações possíveis cresce mais rápido que sua capacidade de mantê-las claras.

Imutabilidade explicada sem jargão de ciência da computação

Imutabilidade simplesmente significa dados que não mudam depois de criados. Em vez de pegar uma peça de informação existente e editá-la no lugar, você cria uma nova peça de informação que reflete a atualização.

Pense em um recibo: uma vez impresso, você não apaga itens e reescreve totais. Se algo muda, você emite um recibo corrigido. O antigo ainda existe, e o novo é claramente “a versão mais recente”.

Por que reduz surpresas

Quando dados não podem ser modificados silenciosamente, você para de se preocupar com edições invisíveis acontecendo por trás das costas. Isso facilita muito o raciocínio cotidiano:

• Se você segura um valor, pode confiar que ele vai permanecer assim.
• Bugs ficam mais fáceis de reproduzir porque a mesma entrada permanece constante.
• Compartilhar dados entre partes do sistema é mais seguro porque ninguém pode “estragar” acidentalmente para outra pessoa.

Isso é grande parte do motivo pelo qual Hickey fala sobre simplicidade: menos efeitos colaterais ocultos significa menos ramos mentais para acompanhar.

“Novas versões” vs. “editar no lugar”

Criar novas versões pode parecer desperdiçador até comparar com a alternativa. Editar no lugar pode deixar você perguntando: “Quem mudou isto? Quando? Como era antes?” Com dados imutáveis, mudanças são explícitas: existe uma nova versão, e a antiga permanece disponível para depuração, auditoria ou rollback.

Clojure incentiva isso tornando natural tratar atualizações como produção de novos valores, não mutações dos antigos.

Compensações, para ser honesto

Imutabilidade não é de graça. Você pode alocar mais objetos, e times acostumados a “só atualizar a coisa” podem precisar de tempo para se ajustar. A boa notícia é que implementações modernas frequentemente compartilham estrutura internamente para reduzir custo de memória, e o retorno costuma ser sistemas mais calmos com menos incidentes difíceis de explicar.

Concorrência fica mais fácil quando dados não mudam

Concorrência é apenas “muitas coisas acontecendo ao mesmo tempo”. Um app web atendendo milhares de requisições, um sistema de pagamentos atualizando saldos enquanto gera recibos, ou um app mobile sincronizando em background — tudo isso é concorrente.

A parte complicada não é que múltiplas coisas aconteçam. É que elas frequentemente tocam os mesmos dados.

Por que dados compartilhados e mutáveis criam condições de corrida

Quando dois workers podem ler e então modificar o mesmo valor, o resultado final pode depender da temporização. Isso é uma condição de corrida: não é um bug fácil de reproduzir, mas aparece quando o sistema está ocupado.

Exemplo: duas requisições tentam atualizar um total de pedido.

1. Requisição A lê total = 100
2. Requisição B lê total = 100
3. A adiciona 20 e escreve 120
4. B adiciona 10 e escreve 110

Nada “crashou”, mas você perdeu uma atualização. Sob carga, essas janelas de temporização ficam mais comuns.

As correções tradicionais — locks, blocos sincronizados, ordenação cuidadosa — funcionam, mas forçam todo mundo a coordenar. Coordenação é cara: reduz throughput e fica frágil conforme o código cresce.

Como a imutabilidade reduz a coordenação ao mínimo

Com dados imutáveis, um valor não é editado no lugar. Em vez disso, você cria um novo valor que representa a mudança.

Essa única mudança evita toda uma categoria de problemas:

• Leitores não precisam se preocupar que o que eles estão vendo mude durante a leitura.
• Escritores não “brigam” pela mesma memória; eles produzem novas versões.
• O sistema pode escolher maneiras seguras de publicar a versão mais recente (frequentemente com primitivas simples e bem testadas).

O resultado: comportamento previsível sob carga

Imutabilidade não torna concorrência gratuita — você ainda precisa de regras sobre qual versão é atual. Mas torna programas concorrentes muito mais previsíveis, porque os dados em si não são um alvo em movimento. Quando o tráfego sobe ou jobs de background se acumulam, é menos provável ver falhas misteriosas dependentes de temporização.

O que “melhores padrões” significa na prática

“Melhores padrões” significa que a escolha mais segura acontece automaticamente, e você só assume risco extra quando opta explicitamente por isso.

Parece pequeno, mas padrões orientam silenciosamente o que as pessoas escrevem numa segunda-feira de manhã, o que revisores aceitam numa sexta à tarde e o que um novo colega aprende ao tocar o primeiro código.

Padrões que reduzem risco

Um “melhor padrão” não é sobre tomar todas as decisões por você. É sobre tornar o caminho comum menos sujeito a erro.

Por exemplo:

• Dados imutáveis por padrão: em vez de “mudar a coisa”, você cria uma nova versão dela. Isso torna mais difícil afetar acidentalmente outras partes que dependiam do valor antigo.
• Funções puras como estilo normal: uma função recebe entradas e retorna uma saída, sem mudar dados compartilhados ou depender de estado global escondido. Isso torna o comportamento mais previsível e testável.
• Mudanças de estado explícitas: quando algo tem que mudar, acontece por mecanismos claros e bem definidos (em vez de qualquer parte do código poder mutar qualquer coisa).

Nada disso elimina complexidade, mas impede que ela se espalhe.

Como padrões moldam times e revisões de código

Times não seguem só a documentação — seguem o que o código “quer” que você faça.

Quando mutar estado compartilhado é fácil, vira um atalho normal, e revisores acabam debatendo intenção: “Isso é seguro aqui?” Quando imutabilidade e funções puras são o padrão, revisores podem focar em lógica e correção, porque movimentos arriscados se destacam.

Em outras palavras, melhores padrões criam uma linha de base mais saudável: a maioria das mudanças parece consistente, e padrões incomuns são óbvios o suficiente para questionar.

Manutenção e onboarding

Manutenção a longo prazo é principalmente sobre ler e mudar código existente com segurança.

Melhores padrões ajudam novos colegas a subir mais rápido porque há menos regras escondidas (“cuidado, esta função atualiza secretamente aquele mapa global”). O sistema fica mais fácil de raciocinar, o que reduz o custo de cada nova feature, correção e refatoração.

Separe fatos de visões: tempo, histórico e rastreabilidade

Uma mudança mental útil nas palestras de Hickey é separar fatos (o que aconteceu) de visões (o que acreditamos ser verdade agora). A maioria dos sistemas mistura isso ao armazenar apenas o valor mais recente — sobrescrevendo ontem com hoje — e isso faz o tempo desaparecer.

Fatos são apenas-apêndice; visões são derivadas

Um fato é um registro imutável: “Pedido #4821 foi feito às 10:14”, “Pagamento realizado”, “Endereço foi alterado”. Esses não são editados; você adiciona novos fatos conforme a realidade muda.

Uma visão é o que seu app precisa agora: “Qual é o endereço de envio atual?” ou “Qual é o saldo do cliente?” Visões podem ser recompostas a partir de fatos, cacheadas, indexadas ou materializadas para velocidade.

Por que manter histórico compensa

Quando você retém fatos, ganha:

• Auditabilidade: você pode explicar por que o valor atual é o que é.
• Depuração: você pode reproduzir a sequência e encontrar o momento em que as coisas divergiram.
• Rastreabilidade: “Quem mudou isto, quando e como era antes?” vira uma pergunta de dados, não um caso de detetive.

Um exemplo acessível: sobrescrever vs. anexar

Sobrescrever registros é como atualizar uma célula de planilha: você só vê o número mais recente.

Um log apenas-apêndice é como um registro de cheques: cada entrada é um fato, e o “saldo atual” é uma visão calculada a partir das entradas.

Nem todo sistema precisa de event sourcing completo

Você não precisa adotar uma arquitetura de event sourcing completa para se beneficiar. Muitas equipes começam menor: mantenha uma tabela de auditoria apenas-apêndice para mudanças críticas, armazene eventos de mudança imutáveis para alguns workflows de alto risco ou retenha snapshots mais uma janela curta de histórico. O essencial é o hábito: trate fatos como duráveis e trate o estado atual como uma projeção conveniente.

Dados em primeiro lugar: torne a informação durável e flexível

Uma das ideias mais práticas de Hickey é data-first: trate a informação do sistema como valores simples (fatos) e trate o comportamento como algo que você executa contra esses valores.

Dados são duráveis. Se você armazenar informações claras e autocontidas, pode reinterpretá-las depois, movê-las entre serviços, reindexá-las, auditar ou usá-las em novas features. Comportamento é menos durável — código muda, pressupostos mudam, dependências mudam.

Valores vs ações (sem jargão)

• Dados (valores): “O que é verdade?” O e-mail de um cliente, o total de um pedido, um timestamp, um status.
• Comportamento (ações): “O que fazemos?” Validar, calcular descontos, enviar notificações, decidir o que um status significa.

Quando você mistura isso, sistemas ficam pegajosos: você não consegue reutilizar dados sem arrastar junto o comportamento que os criou.

Menos acoplamento, mais reutilização

Separar fatos de ações reduz acoplamento porque componentes podem concordar numa forma de dados sem concordar num caminho de código compartilhado.

Um job de relatórios, uma ferramenta de suporte e um serviço de cobrança podem consumir os mesmos dados de pedido, cada um aplicando sua própria lógica. Se você embute lógica na representação armazenada, cada consumidor depende dessa lógica embutida — e mudá-la vira arriscado.

Exemplo: armazenar dados limpos vs armazenar mini-programas

Dados limpos (fáceis de evoluir):

{
  "type": "discount",
  "code": "WELCOME10",
  "percent": 10,
  "valid_until": "2026-01-31"
}

Mini-programas no armazenamento (difíceis de evoluir):

{
  "type": "discount",
  "rule": "if (customer.orders == 0) return total * 0.9; else return total;"
}

A segunda versão parece flexível, mas empurra complexidade para a camada de dados: agora você precisa de um avaliador seguro, regras de versionamento, limites de segurança, ferramentas de depuração e um plano de migração quando a linguagem de regras mudar.

Por que isso torna sistemas evolutivos

Quando a informação armazenada permanece simples e explícita, você pode mudar o comportamento ao longo do tempo sem reescrever o histórico. Registros antigos permanecem legíveis. Novos serviços podem ser adicionados sem “entender” regras de execução legadas. E você pode introduzir novas interpretações — novas visões de UI, novas estratégias de preço, novas análises — escrevendo novo código, não mutando o que seus dados significam.

Aplicando as ideias a sistemas complexos (sem reescrever tudo)

A maioria dos sistemas empresariais não falha porque um módulo é “ruim”. Eles falham porque tudo está ligado a tudo.

Modos de falha a observar

Acoplamento forte aparece como mudanças “pequenas” que disparam semanas de retestes. Um campo adicionado a um serviço quebra três consumidores downstream. Um esquema de banco de dados compartilhado vira gargalo de coordenação. Um cache mutável ou um singleton de “config” silenciosamente vira dependência de metade da base de código.

Mudanças em cascata são o resultado natural: quando muitas partes compartilham a mesma coisa mutável, o raio de explosão aumenta. Times respondem adicionando mais processos, mais regras e mais handoffs — frequentemente deixando a entrega ainda mais lenta.

Reduza o raio de explosão com limites mais simples

Você pode aplicar as ideias de Hickey sem trocar de linguagem ou reescrever tudo:

• Prefira dados imutáveis nas fronteiras. Trate mensagens, eventos e entradas de API como “fatos” que não são editados no lugar. Se algo muda, crie uma nova versão.
• Mova estado para as bordas. Mantenha a lógica central como transformações puras: dados de entrada → dados de saída. Deixe bancos, caches e UIs lidarem com “estado atual”.
• Pare de compartilhar estruturas mutáveis. Se dois módulos escrevem no mesmo objeto, eles estão acoplados. Passe valores, não referências que você planeja mutar.

Quando os dados não mudam sob seus pés, você gasta menos tempo depurando “como isso entrou nesse estado?” e mais tempo raciocinando sobre o que o código faz.

“Melhores padrões” entre equipes

Padrões são onde a inconsistência se infiltra: cada time inventa seu próprio formato de timestamp, forma de erro, política de retry e abordagem de concorrência.

Melhores padrões parecem com: esquemas de eventos versionados, DTOs imutáveis padrão, propriedade clara das escritas e um pequeno conjunto de bibliotecas aprovadas para serialização, validação e tracing. O resultado é menos integrações-surpresa e menos correções one-off.

Adoção incremental que funciona em bases legadas

Comece onde a mudança já está acontecendo:

1. Encapsule módulos existentes com uma API que aceite/retorne dados imutáveis.
2. Converta um workflow de alta rotatividade para registros “apenas-apêndice” estilo evento.
3. Substitua caches mutáveis compartilhados por visões recomputáveis a partir de fatos duráveis.

Essa abordagem melhora confiabilidade e coordenação de times enquanto mantém o sistema em funcionamento — e mantém o escopo pequeno o bastante para terminar.

Onde plataformas e ferramentas podem reforçar “melhores padrões”

É mais fácil aplicar essas ideias quando seu fluxo de trabalho suporta iteração rápida e de baixo risco. Por exemplo, se você está construindo novas features no Koder.ai (uma plataforma de vibe-coding baseada em chat para web, backend e apps móveis), duas funcionalidades se mapeiam diretamente à mentalidade de “melhores padrões”:

• Modo de planejamento incentiva você a deixar fronteiras e formas de dados explícitas antes da implementação — muitas vezes a diferença entre fluxo de dados simples e acoplamento acidental.
• Snapshots e rollback tornam mudanças mais seguras para enviar, porque você pode reverter rapidamente quando um atalho “fácil” vira um pico de complexidade.

Mesmo se sua stack for React + Go + PostgreSQL (ou Flutter para mobile), o ponto central permanece: as ferramentas que você usa todo dia ensinam silenciosamente um jeito de trabalhar. Escolher ferramentas que tornem rotina a rastreabilidade, rollback e planejamento explícito pode reduzir a pressão de “só conserte na hora”.

Compensações, limites e evitar ideologia

Simplicidade e imutabilidade são padrões poderosos, não regras morais. Eles reduzem o número de coisas que podem mudar inesperadamente, o que ajuda quando sistemas crescem. Mas projetos reais têm orçamento, prazos e restrições — e às vezes mutabilidade é a ferramenta certa.

Quando a mutabilidade é aceitável

Mutabilidade pode ser uma escolha prática em hotspots de performance (loops apertados, parsing de alto throughput, gráficos, trabalho numérico) onde alocações dominam. Também pode ser aceitável quando o escopo está controlado: variáveis locais dentro de uma função, um cache privado escondido por uma interface, ou um componente single-threaded com limites claros.

A chave é contenção. Se a “coisa mutável” nunca vaza, ela não pode espalhar complexidade pela base de código.

Limite a complexidade com propriedade e interfaces

Mesmo num estilo majoritariamente funcional, times ainda precisam de propriedade clara:

• Um módulo possui um pedaço de estado e expõe uma API pequena.
• Dados atravessam fronteiras como valores simples (não objetos vivos com comportamento secreto).
• Efeitos colaterais são empurrados para as bordas (I/O, bancos, tempo).

É aqui que a inclinação de Clojure para dados e fronteiras explícitas ajuda, mas a disciplina é arquitetural, não específica de linguagem.

O que Clojure não vai resolver

Nenhuma linguagem conserta requisitos ruins, um modelo de domínio confuso ou um time que não concorda sobre o que significa “pronto”. Imutabilidade não vai tornar um fluxo de trabalho confuso compreensível, e código “funcional” ainda pode codificar regras de negócio erradas — só que de forma mais elegante.

Evite dogmas: reduza risco com a menor mudança possível

Se seu sistema já está em produção, não trate essas ideias como uma reescrita tudo-ou-nada. Procure o menor movimento que reduza risco:

• Substitua estruturas mutáveis compartilhadas por dados imutáveis nas fronteiras dos módulos.
• Adicione logs de eventos ou histórico apenas-apêndice onde a auditabilidade importa.
• Encapsule estado legado por trás de uma interface estreita e impeça que ele se espalhe.

O objetivo não é pureza — é menos surpresas por mudança.

Um checklist prático para caminhar rumo a software mais simples

Isto é um checklist de tamanho de sprint que você pode aplicar sem trocar linguagens, frameworks ou estrutura de times.

3–5 coisas para tentar no próximo sprint

1. Faça suas “formas de dados” imutáveis por padrão. Trate objetos de request/response, eventos e mensagens como valores que você cria uma vez e nunca modifica. Se algo precisa mudar, crie uma nova versão.

2. Prefira funções puras no meio dos fluxos. Comece com um workflow (por exemplo, precificação, permissões, checkout) e refatore o núcleo em funções que recebem dados e retornam dados — sem leituras/gravações escondidas.

3. Mova estado para menos lugares e mais claros. Escolha uma fonte de verdade por conceito (status do cliente, feature flags, inventário). Se múltiplos módulos mantêm cópias próprias, faça disso uma decisão explícita com estratégia de sincronização.

4. Adicione um log apenas-apêndice para fatos-chave. Para uma área de domínio, registre “o que aconteceu” como eventos duráveis (mesmo que você ainda armazene estado atual). Isso melhora rastreabilidade e reduz suposições.

5. Defina padrões mais seguros nas APIs. Padrões devem minimizar comportamento surpreendente: timezones explícitos, tratamento explícito de nulls, retries explícitos, garantias de ordenação explícitas.

Perguntas para revisão de design (use-as literalmente)

• Quais são as partes mutáveis aqui, e quem está autorizado a mudá-las?
• Podemos modelar isto como “fatos” mais uma visão derivada em vez de sobrescrever campos?
• Se duas requisições rodarem ao mesmo tempo, o que quebra?
• Em quais padrões estamos confiando (tempo, ordenação, retries, caching), e eles estão documentados?
• O que precisaríamos para depurar isto daqui a três meses?

Tópicos sugeridos para revisitar das palestras de Hickey

Busque material sobre simplicidade vs facilidade, gerenciamento de estado, design orientado a valores, imutabilidade e como “histórico” (fatos ao longo do tempo) ajuda depuração e operações.

Simplicidade não é uma feature que você adiciona — é uma estratégia que você pratica em escolhas pequenas e repetíveis.