O dia que eu aprendi o que é arquitetura de software de verdade
Durante dois anos escrevi código funcional sem entender por que certas decisões tornavam o sistema mais difícil de mudar. Então li uma frase que reorganizou tudo.
Durante dois anos na software house eu escrevi código que funcionava. Funcionar, no sentido literal: rodava em produção, resolvia o problema do cliente, não caía toda hora.
Mas existia uma coisa que eu percebia sem conseguir nomear. Certas partes do sistema eram fáceis de mudar. Outras eram um pesadelo. Adicionar uma feature simples em alguns módulos levava trinta minutos. Em outros, levava dois dias e quebravam coisas que eu nem sabia que estavam relacionadas.
Eu achava que isso era normal. Que era o custo de ter um sistema grande.
O momento de virada foi uma frase num livro que eu estava lendo meio por obrigação, meio por curiosidade. A frase era, em tradução livre: "A arquitetura de software é o conjunto de decisões de design que, se mudadas, custam caro para mudar de volta."
Parei no meio do parágrafo.
Reli três vezes.
A arquitetura não era a organização visual do código. Não era o diagrama no Confluence. Era o custo de mudança. Era o que ficava difícil de desfazer.
Com esse novo entendimento, olhei pro sistema que estávamos construindo com outros olhos.
O módulo de autenticação estava acoplado a todas as outras partes do sistema — não porque alguém tinha planejado assim, mas porque foi mais rápido no momento. Cada vez que a regra de autenticação mudava, precisávamos editar cinco arquivos em quatro módulos diferentes. O custo de cada mudança estava embutido em cada decisão original de não separar as coisas.
A lógica de negócio estava misturada com a lógica de acesso ao banco de dados. Não era fácil testar a regra de negócio sem precisar de um banco de dados rodando. Então os testes eram raros, caros de escrever e frequentemente pulados. E quando pulávamos os testes, crescia a nossa dívida de incerteza sobre o que podia ser mudado sem efeito colateral.
Entender arquitetura não significa saber desenhar diagramas bonitos ou conhecer padrões pelo nome. Significa entender qual é o custo das suas decisões de hoje no trabalho de amanhã.
Quando você une dois módulos porque é mais rápido agora, você está pagando um custo futuro diferido. Quando você coloca lógica de negócio no controller porque é mais simples no momento, você está tornando essa lógica mais difícil de testar, reusar, e mover mais tarde.
Isso não significa que a decisão esteja sempre errada. Às vezes a velocidade de hoje vale o custo de amanhã — especialmente quando você está num projeto de prova de conceito, ou quando não sabe ainda se aquela parte vai durar. O problema é fazer isso sem perceber que está fazendo.
A pergunta que mudou como eu escrevo código é simples: "se eu precisar mudar isso daqui a seis meses, quanto vai custar?"
Não é uma pergunta sobre o futuro que você vai conseguir prever com precisão. Mas o exercício de fazer a pergunta muda o que você enxerga no código que está escrevendo agora.
Quando eu comecei a fazer essa pergunta conscientemente, comecei a notar dependências que antes eram invisíveis. Comecei a separar coisas que eu antes unia por conveniência. Comecei a nomear coisas de forma que o código ficasse mais fácil de ler sem o contexto da reunião onde a decisão foi tomada.
Arquitetura, descobri, não é o trabalho de um arquiteto que decide tudo no início. É o resultado de mil decisões pequenas tomadas por quem escreve o código, durante todo o tempo que o sistema existe.
Essa semana: olhe para um módulo ou função do seu sistema atual e pergunte — "se eu precisar mudar a regra de negócio aqui, quantos arquivos vou precisar editar?" Se a resposta for mais de três, você provavelmente tem um acoplamento que vai te custar caro mais tarde.