Por que li meu primeiro livro de arquitetura de software em 2019
Não foi por curiosidade. Foi porque tinha um problema que não conseguia resolver e alguém mencionou Clean Architecture. Lembro onde estava quando aquela leitura clicou.
Li Clean Architecture do Uncle Bob em outubro de 2019.
Não por disciplina, não porque alguém mandou. Porque tinha um problema concreto que não conseguia resolver: nosso código de integração com CRM estava ficando impossível de testar. Cada função chamava o banco de dados diretamente. Para testar qualquer coisa, precisava de banco real, dado real, conexão real.
O sênior do time falou: "você precisa ler sobre separação de dependências." E jogou o nome do livro.
Livros técnicos têm uma diferença importante de documentação e tutoriais: eles explicam o porquê.
Tutorial te mostra como fazer. Documentação te diz o que cada função faz. Livro técnico bom te explica por que aquela decisão foi tomada, qual problema ela resolve, e quando ela não é a solução certa.
Clean Architecture não me ensinou a escrever código diferente imediatamente. Me deu um modelo mental para pensar sobre estrutura: a regra de dependência. Dependências devem apontar para dentro — para as regras de negócio — nunca para fora, para banco de dados, frameworks, ou UI.
Quando entendi isso, olhei para o código que eu tinha e entendi exatamente por que era difícil de testar: a lógica de negócio estava acoplada ao banco de dados. Mudar o banco precisaria de reescrever a lógica.
Não concordo com tudo no livro. Algumas partes envelheceram. O exemplo em Java é verboso demais para quem vem de Python. E tem uma tendência ao over-engineering que eu não aplicaria em sistema pequeno.
Mas leu antes de precisar de toda aquela informação você já sabe onde buscar quando precisar.
Esse é o valor de ler livros técnicos de forma não urgente: você não está lendo para resolver o problema de hoje. Está construindo vocabulário e modelos mentais para problemas futuros.
A rotina que desenvolvi a partir de 2019, que mantive até hoje:
Um livro técnico de cada vez, lendo no ritmo que faz sentido — às vezes 30 minutos por dia, às vezes ficava uma semana sem tocar. Não forçar velocidade porque compreensão real de um capítulo de arquitetura leva tempo.
Quando algo clica, anoto com próprias palavras. Não copia o texto — escreve o que você entendeu. Se não consegues escrever em suas palavras, você reconheceu o conceito mas não entendeu. Essa é a diferença do Marty Lobdell: recollection (escrever de memória) vs recognition (reconhecer quando vê). Recollection é o que fica.
300 livros lidos depois, o padrão é o mesmo: livros que ficaram foram os que eu li com problema concreto em mente ou que li devagar o suficiente para processar.
Essa semana: tem algum problema técnico que você está enrolando sem saber direito como atacar? Esse é o momento certo para procurar um livro.