Introdução
Antes de falarmos de boas práticas, de código limpo, de padrões de projeto e de qualquer coisa com cara de verdade absoluta, é importante voltarmos ao começo. Ao código real.
Aquele que não está em livros, que nem sempre é bonito, mas que funciona. Aquele que nasceu do dia a dia, das urgências, da pressão, da gambiarra que virou solução permanente. Esse é o verdadeiro ponto de partida. E para entendê-lo, precisamos falar de dois conceitos fundamentais: conhecimento tácito e conhecimento explícito.
Conhecimento Tácito vs Conhecimento Explícito
Conhecimento explícito é aquele que está documentado. É o que lemos nos livros, tutoriais, artigos, nos padrões e boas práticas. Ele é essencial para aprendermos, comunicarmos e registrarmos o que foi descoberto.
Mas ele é apenas uma parte da história.
O conhecimento tácito é aquele que você adquire pela experiência. Pelo erro, pelo acerto, pela repetição. Ele está em cada solução que você não sabe explicar exatamente como chegou, mas sabe que funciona. Está no "feeling" de quem lida com sistemas complexos há anos.
"Todo conhecimento explícito é filho do tácito. O livro só nasce depois da vivência."
Existe uma história clássica, quase uma piada, mas que ilustra bem essa diferença:
Um navio parou em alto-mar. Ninguém conseguia fazer o motor voltar a funcionar. Chamaram um mecânico experiente. Ele chegou, ouviu, observou, pegou um martelo e deu uma única martelada em um ponto específico. O motor voltou a funcionar na hora.
Quando foram pagar, veio a surpresa: o preço era alto. "Mas como assim? Uma martelada vale tudo isso?"
E ele respondeu:
"A martelada custa pouco. O caro é saber onde bater."
Esse é o conhecimento tácito. O que não se ensina em tutoriais. O que é construído com anos de experiência, falhas, tentativas e acertos.
A interação entre os dois conhecimentos
Os dois tipos de conhecimento se alimentam. O explícito documenta o tácito, e o tácito atualiza o explícito. Mas quando um deles tenta existir sozinho, surgem os problemas.
- Quando temos apenas o tácito, corremos o risco de perder o conhecimento com as pessoas. Nada está escrito, nada é replicável.
- Quando temos apenas o explícito, corremos o risco de seguir regras sem entender o porquê. Repetir exemplos de padrões que não fazem sentido no contexto.
"Copiar código é fácil. Difícil é entender por que ele está daquele jeito."
Na prática, muitos desenvolvedores copiam padrões e trechos de código achando que estão absorvendo conhecimento, quando estão apenas acumulando comandos sem compreensão.
Organização real vs organização teórica
Organização não é uma estética. É uma prática funcional. Organizar não é empilhar caixas com etiquetas bonitas. É saber onde está o que você precisa.
Vamos a alguns exemplos simples do dia a dia:
- Se você deixa tudo que usa frequentemente perto da sua mesa, sua eficiência aumenta.
- Einstein usava sempre o mesmo tipo de terno. Para quê perder tempo com o que não é essencial?
- Uma gaveta organizada é aquela que você acessa rapidamente, não a mais bonita ou segmentada.
- Criar muitas subdivisões pode ser pior: você gasta mais tempo organizando do que executando.
"Se você tiver mais caixas do que coisas, sua organização virou desorganização elegante."
Essa lógica serve perfeitamente para o código. Criar muitas camadas, abstrações e arquivos pode parecer bonito, mas pode dificultar a manutenção, a compreensão e a evolução. Organizar é saber quebrar nos pontos certos, dentro do seu contexto.
A forma natural de programar: top-down, procedural
A maioria das pessoas pensa de forma sequencial. Explicamos uma ideia de cima para baixo. Começamos do geral para o específico. Programar assim é natural.
A abordagem procedural, top-down, é intuitiva. Faz sentido. Permite que você leia o código como se estivesse lendo uma instrução, uma receita, um plano.
O problema é que muitos aprendem desde cedo que isso é errado. Que precisa ser tudo orientado a objetos, com padrões, interfaces, injeções, factories, builders...
"Abstrair antes de entender é como escrever poesia em um idioma que você ainda não fala."
Não estamos dizendo que padrões são ruins. Mas eles precisam ser aplicados com critério. E, muitas vezes, um código procedural bem escrito, bem organizado, resolve muito mais com muito menos.
Níveis de conhecimento: você quer que eu baixe o nível ou que você suba o seu?
Outro ponto importante é entender que nem todos estão no mesmo nível. Um conceito que é óbvio para um pode ser inatingível para outro.
Mas isso não significa que devemos nivelar tudo por baixo.
"Baixar o nível é mais fácil. Elevar o grupo exige didática, respeito e paciência."
Quando você esconde a complexidade, você impede o aprendizado. Às vezes, é melhor mostrar o que é difícil com clareza do que empacotar tudo numa abstração que ninguém entende.
"Se o seu código é fácil pra você, ótimo. Mas se ninguém mais consegue mantê-lo, talvez você tenha se isolado no topo da montanha."
Conclusão
Antes de pensar em deixar seu código limpo, pense se ele está funcionando. Depois, veja se alguém entende. Só então pense se ele está bonito.
"O bom código é como uma boa oficina: pode até ter graxa no chão, mas tudo funciona, tudo está no lugar certo — e todo mundo sabe usar."
Este é o ponto de partida da nossa jornada.
Nos próximos episódios, vamos explorar o livro Clean Code capítulo por capítulo. Vamos reconhecer seus méritos, apontar seus exageros e, principalmente, confrontar suas ideias com a realidade do código que sustenta sistemas de verdade.
Nada de polêmica vazia. Aqui é o Clean Code Trek.
"Clean Code Trek — Onde nenhum código real jamais esteve."
"A beleza do código está no que ele entrega, e não no que ele aparenta."
