O primeiro capítulo do livro começa com uma história sobre um aplicativo popular nas décadas passadas que declinou devido ao código confuso e não gerenciável, demorando muito tempo para lançar novas atualizações, corrigir bugs, etc. Isso serve como uma introdução ao problema central abordado no livro: os efeitos prejudiciais de um código ruim.

Mas, afinal de contas, por que criamos códigos ruins? Foram criados sob pressão? Criados rapidamente? Você queria terminar a tarefa logo e pensou “depois eu refatoro e faço melhor”? Daí vem uma frase mostrada no livro que gostei muito: Mais tarde é igual a nunca.

E quais as consequências de um código ruim? Conforme o tempo passa, a produtividade diminui. Uma equipe começa a perceber que o código que criaram rapidamente há alguns anos está dando prejuízo nos dias de hoje: cada alteração feita no código causa uma falha em outras partes do mesmo código, cada adição ao código faz com que códigos já existentes devem ser modificados, entre outros diversos problemas. A bagunça está feita.

Dedicar tempo para escrever código limpo não é apenas eficaz em termos de custo, mas uma questão de sobrevivência profissional.

Tentamos nunca nos responsabilizar por ter criado um código ruim, sempre colocando a culpa em curtos prazos, pressões, clientes intolerantes, etc. Mas lembre-se: você é um profissional, e não é profissional que programadores cedam à vontade dos gerentes que não entendem os riscos de se gerar códigos confusos.

Saber distinguir um código limpo de um código ruim não significa que você sabe escrever um código limpo. Escrever código limpo exige o uso disciplinado de diferentes técnicas. Essas técnicas estão relacionadas a como organizar e estruturar o código para que ele seja fácil de entender e manter. Com o tempo e a experiência, você desenvolve uma espécie de "senso" ou intuição para identificar o que torna um código mais "limpo" ou melhor.

E o que significa um código limpo? Existem várias definições, e para responder essa pergunta, Robert C. Martin perguntou a diversos programadores experientes o que eles achavam.

Bjarne Stroupstrup, criador do C++, diz que o código limpo faz bem apenas uma coisa. Ele é centralizado.

Uma metáfora expressa no livro que gostei muito foi

“Uma construção com janelas quebradas parece que ninguém cuida dela. Dessa forma, outras pessoas deixam de se preocupar com ela também. Elas permitem que as outras janelas es quebrem também. No final das contas, as próprias pessoas as quebram. Elas estragam a fachada com pichações e deixam acumular lixo. Uma única janela inicia o processo de degradação.”

Um código ruim incita o crescimento do caos num código. Quando outras pessoas alteram um código ruim, elas tendem a piorá-lo.

Grady Booch, autor de um livro sobre orientação a objetos, diz que um código limpo é simples e direto, estando repleto de abstrações claras e linhas de controle objetivas. Deve ser decisivo, sem especulações. Deve expor claramente as questões do problema a ser solucionado.

Dave Thomas, fundador da OTI, diz que um código sem testes não está limpo. Ressalta também que o código deve ser escrito de uma forma que seja inteligível (compreensível) aos seres humanos.

Michael Feathers, autor de um livro sobre códigos legados, diz que um código limpo sempre parece que foi escrito por alguém que se importava com o que estava escrevendo.

Ron Jeffries, autor de um livro C#, resume que o código limpo deve ser um código com testes, sem duplicação, entidades devem seguir o padrão de responsabilidade única (isto será abordado e discutido mais a frente), deve ser expressivo e com pequenas abstrações.

Ward Cunningham, cocriador do eXtreme programming, diz que ao ler um código limpo nada deve te surpreender. O código é óbvio, simples e convincente. Cada módulo prepara o terreno para o seguinte.

Por fim, o livro diz para não tornar este conhecimento descrito ao decorrer como “a única fonte da verdade”, você pode concordar ou discordar de certos pontos. E está tudo bem. Além disso, somos autores de códigos e todo autor tem leitores, com os quais uma boa comunicação é responsabilidade dos autores. Constantemente também lemos códigos antigos quando escrevemos novos.

Se quer que seu código seja de fácil escrita, torne-o de fácil leitura.

Não basta escrever um código bom. Ele precisa ser mantido sempre limpo. “Deixe a área do acampamento mais limpa do que como você a encontrou.”

A refatoração para o código limpo nunca acaba. Sempre há código que pode ser melhorado.