Para quem acompanha o blog e ainda não entendeu a moral de falarmos de código limpo em um blog sobre testes de software, gostaria que refletissem um pouco e percebessem se tal questionamento realmente faz sentido, afinal de contas, estamos falando de uma atividade intimamente relacionada ao desenvolvimento de software, senão obrigatória, ainda mais em uma época em que a agilidade está tão em alta.
Falar de teste de software nos dias atuais e não pensar em automação de testes ou mesmo em TDD é algo incomum. E como diria Klaus Wuestefeld,
Testar software manualmente, no século 21, é antiético, como um cirurgião operar sem lavar as mãos.
Portanto, a ideia da série de insights de código limpo é exatamente tentar despertar interesse naqueles que ainda não perceberam a arte por trás dos códigos e trazê-los mais para perto dessa realidade, já que não há nada que não possa ser aprendido.
Teste de software também é sobre código limpo. Vamos juntos desbravar este mundo dos códigos e nos tornarmos melhores profissionais?
Deixa um comentário aí e vamos conversar…
TALKING ABOUT TESTING 
Walmyr,
Não sei se minha linha de raciocínio é correta ou se estou viajando, mas quando ouço o termo ´código limpo´ o primeiro ponto que me vem em mente é ´complexidade de código´. Tentarei explicar meu raciocínio…
Código complexo vai demandar mais tempo para o desenvolvedor compreendê-lo para só depois iniciar a manutenção (supondo que compreendeu corretamente). E por ser complexo, muitas vezes um ´malabarismo´ se faz necessário pra realizar a manutenção sem impactar em outras funcionalidades já existentes (Malabarista de Código). E nesse malabarismo, além das linhas de código da manutenção propriamente dita, mais um bocado de linhas de código auxiliares (vulgo gambiarra/camanguinha) virão junto. Enfim, é isso um ´código limpo´? Acredito que não. Além do desenvolvedor precisar de mais tempo pra compreender o código existente, a manutenção será mais demorada pois (bem) mais linhas de código terão que ser adicionadas, e isso tenderá a causar mais bugs.
Agora imagine a situação que o código já existente foi elaborado seguindo conceitos básicos de acoplamento/coesão e com o cuidado de não criar classes/métodos extensos! O código tende a ser mais simples e mais facilmente compreensível, os (eventuais) impactos na manutenção do código serão mais fáceis de identificar. Além de demandar menos tempo para compreendê-lo, a manutenção tenderá a ser menos custosa, e os tais ´códigos auxiliares´ não serão tão necessários (senão desnecessários). O código tende a ficar mais limpo, e sua manutenção mais ágil!
Essa é uma visão que tenho quando ouço o termo ´código limpo´. 🙂
Abraço!
Muito legais teus pontos Cristiano, pessoas diferentes enxergam código limpo como coisas parecidas, mas diferentes. Para mim, além do que já comentaste, a existência de testes no código o torna mais limpo também (no sentido de design de código, quando desenvolvido com técnicas de TDD), além é claro de questões de legibilidade/facilidade de leitura e manutenção de código, além da eliminação de dependências e eliminação de duplicidade de código.
Só achei meio confusa teu primeiro ponto, onde creio que você se confundiu um pouco, ao dizer que ao ouvir ‘código limpo’ pensa em ‘complexidade de código’. Ao meu ver é exatamente o contrário, ou seja, ‘código sujo’ == ‘código complexo’ e ‘código limpo == ‘código simples/legível’.
Sim, ficou um pouco confuso o que eu escrevi, mas a comparação que tu fez (‘código sujo’ == ‘código complexo’ e ‘código limpo == ‘código simples/legível’) torna bem mais claro o que eu tentei expressar – tu captou bem a ideia. ‘Código complexo’ tende a ser um ‘código sujo’ pois fica mais difícil de realizar manutenção e de aplicar as boas práticas que poderiam torná-lo ´mais limpo´. E claro, ‘código simples/legível´ tende a ser ´código limpo´.
Foi isso que eu tentei expressar quando disse ´ao ouvir código limpo me vem em mente complexidade de código´: se eu quero um código limpo, devo me atentar a ter um código o menos complexo possível. E para ser menos complexo, as boas práticas (design, TDD,…) devem estar presentes logo no início da codificação!