A base que separa código júnior de código sênior.
Cinco ideias que voltam a aparecer em cada um dos próximos módulos. Não são teoria — são lentes para enxergar código. Clique em cada conceito para o estudo aprofundado.
Não como dogma, mas como ferramenta. SRP é sobre razões para mudar. DIP é sobre direção de dependências. Saber quando não aplicar é tão importante quanto aplicar.
Métrica real de qualidade estrutural. Alta coesão = mudança fica num só lugar. Baixo acoplamento = posso trocar uma peça sem quebrar tudo.
Herança é acoplamento forte vertical. Composição é flexível e testável. Em Go nem existe herança — entenda por quê.
Código difícil de testar é código com design ruim. TDD não é sobre testes — é sobre forçar boas fronteiras.
Long methods, feature envy, primitive obsession, shotgun surgery. Reconhecer cheiros é metade do trabalho — refatorar é a outra metade.
Quando algo der errado em produção — e vai dar — você não terá tempo de aprender fundamentos. Eles precisam estar internalizados antes da crise.
As perguntas que separam júnior de sênior. Não decore as respostas — entenda o porquê por trás do trade-off.
Quando aplicar SOLID?
Em código que vai mudar. YAGNI vence em scripts e protótipos.
SOLID é ferramenta para gerenciar mudança — onde não há mudança esperada,
é overhead. Aplicar SOLID a uma Calculator de exemplo gera
FizzBuzzEnterpriseEdition: pedagogicamente útil para mostrar o exagero, péssimo como referência.
Herança ou composição?
Composição por default. Herança só em hierarquias verdadeiras (Animal → Cachorro), nunca para reuso. "É um" passa, "tem um" passa, "usa um" passa — "quero reaproveitar código" é cilada. Linguagens modernas (Go, Rust) excluíram herança de classe e o mundo continuou girando: isso deveria dar pra pensar.
Quanto testar?
Cobertura é métrica vaidade. Teste comportamento crítico, fronteiras de domínio, e bugs que reapareceram. 100% de cobertura com testes ruins é pior que 60% com testes que importam. O que você quer maximizar é a velocidade de mudança com confiança, não o número no relatório.
O foco não é resolver o problema (trivial). É estruturar como sênior: camadas claras, testes, configs externalizadas, logs estruturados. Implementado três vezes, em três paradigmas distintos.
Serviço que encurta URLs com analytics básico. O ganho não está em "rodar" — está em comparar como cada linguagem expressa as mesmas ideias arquiteturais.
POST /shorten — recebe URL, devolve código de 7 charsGET /:code — redireciona e incrementa contadorGET /stats/:code — devolve hits, criado em, última visitaOs três projetos no GitHub (repo por linguagem ou monorepo), README explicando trade-offs, e um ADR único comparando as três implementações: "Estruturando a mesma aplicação em três paradigmas".
Perguntas reais de entrevistas sêniores. Pratique respondendo em voz alta, articulando trade-offs com clareza.
Diferença entre acoplamento e coesão? Dê um exemplo de baixo acoplamento e baixa coesão (cilada comum).
O que é Liskov Substitution? Mostre código que viola.
Por que herança pode ser ruim? Quando é boa?
Como você testa código que depende de DB sem subir um DB?