Existe uma ideia comum de que código limpo é algo com que grandes equipas de engenharia se preocupam. Algo que importa quando tens dez developers a trabalhar no mesmo código, mas não quando estás a contratar uma pessoa para construir um site ou uma aplicação pequena.
Essa ideia está errada, e tende a ser cara de descobrir.
O que significa código limpo
Código limpo não é seguir um conjunto rígido de regras ou escrever código que pareça impressionante. É escrever código que é fácil de ler, fácil de alterar, e fácil de passar a outra pessoa.
Significa usar nomes para variáveis e funções que descrevem o que fazem. Significa manter funções curtas e focadas numa única coisa. Significa não deixar para trás blocos de código antigo comentado, ficheiros não utilizados, ou lógica que só faz sentido se estavas presente quando foi escrita.
É a diferença entre um código que um novo developer consegue entender numa tarde e um que demora semanas a fazer sentido, e mesmo assim apenas parcialmente.
Porque importa em projetos mais pequenos
Os projetos pequenos não ficam pequenos para sempre. Um site que começa com cinco páginas torna-se muitas vezes quinze. Um plugin construído para um propósito específico é estendido para fazer mais três coisas. Um cliente volta um ano depois a precisar de alterações, e quem abre o código nessa altura precisa de o conseguir entender rapidamente.
Se o código original foi escrito sem cuidado, cada alteração torna-se mais difícil e arriscada do que devia ser. Os developers cobram mais para trabalhar em código confuso porque custa mais tempo. Os bugs são mais difíceis de encontrar. As novas funcionalidades demoram mais a construir porque tudo está entreaçado.
Código limpo desde o início significa que cada alteração futura é mais barata e mais rápida.
Como se parece na prática
Quando entrego um projeto, o código está estruturado de forma a que outra pessoa o possa pegar sem precisar que eu o explique. Os nomes dos ficheiros fazem sentido. As funções fazem o que os seus nomes dizem que fazem. Não há surpresas escondidas na lógica.
Também evito sobre-engenharia. Código limpo não significa código complexo. Significa a solução mais simples que resolve o problema corretamente e que pode ser mantida sem dificuldade. Adicionar camadas desnecessárias de abstração é apenas um tipo diferente de confusão.
O custo a longo prazo de cortar caminho
A dívida técnica é real. Acumula-se silenciosamente e depois torna-se subitamente muito cara quando um projeto precisa de crescer ou mudar. Já vi sites pequenos que custaram três vezes mais a atualizar do que deviam porque o developer original priorizou velocidade em detrimento de qualidade.
Os clientes que mais sofrem com isto são os que não sabiam que deviam perguntar sobre qualidade de código quando contrataram alguém. Não é algo óbvio de verificar a menos que saibas o que procurar.
O que perguntar antes de contratar um developer
Não precisas de ler código para te preocupares com a sua qualidade. Algumas perguntas dizem-te muito. Pergunta se seguem algum padrão de código. Pergunta como estruturam os seus projetos. Pergunta o que acontece se precisares de contratar outra pessoa para continuar o trabalho depois deles.
Um developer que pensa nestas coisas terá respostas claras. Um que não pensa ficará na defensiva ou dará garantias vagas.
Se quiseres trabalhar com alguém que leva isto a sério, entra em contacto. A qualidade do código não é um extra opcional para mim. Faz parte da forma como trabalho em todos os projetos, independentemente do tamanho.