Sabe aqueles livros que você lê e não para? Então, aconteceu isso comigo ao ler este, Clean Code é um dos poucos livros que dei nota 5 no shelfari.
O primeiro cápitulo é um dos pontos chaves da leitura, ele fala sobre as vantagens de um código limpo, e porquê você deveria se preocupar com isso. Mesmo que um trecho de código compile e funcione da maneira esperada ( certificando-se através de testes unitários ) pode ser ser considerado ruim, legado e mal escrito. O problema é que é muito difícil manter um código limpo, toda a equipe precisa estar ciente dos ganhos que isso pode trazer, e basta uma pessoa violar as regras e o código já vira um carnaval. O que acontece geralmente é que a primeira versão de um componente é desenvolvido de forma clara e bem escrito, nas manutenções subseqüentes as primeiras sujeiras começam a ser inseridas até o momento que vira um monstro onde ninguémtem coragem de tocar.
Nos Estados Unidos as reservas florestais possuem uma regra que diz: “Leave the campground cleaner than you found it”. Imagine isso em um ambiente de desenvolvimento de software, não seria o máximo ter um projeto que o código está sempre mais limpo do que ontem?
Não sei exatamente o que leva algumas empresas a não se preocupar com as boas práticas, é fato que a maior parte dos problemas ocorrem na fase de análise de sistemas, uma análise errada pode resultar em um software inútil, assim como uma ótima análise é um péssimo código resulta em um sistema com os dias contados, daqui 2 ou 3 anos vai sair mais barato fazer outro do que dar manutenção no sistema “legado”. No final quem ganha com isso são as Fábricas de Software, no final do mês são mais horas contratadas, enquanto isso o pobre cliente está lá investindo em algo que logo morre.
Talvez você não tenha como mudar as coisas na sua empresa, mas faça sua parte, limpe o acampamento antes de fazer check-in, tudo bem que um urso pode vir e destruir seu código, mas pelo menos você fica com a consciência limpa de que fez o que era certo.
Como escrever um código clean?
Sugiro a leitura do livro, ele trata sobre nomenclatura de métodos, classes e variáveis, comentários, funções, tamanho da função e responsabilidades (SRP). Dentre outros assuntos, também fala sobre testes automatizados, vejam que esse assunto está presente em todo lugar.
Não adianta ler e achar que vai virar um ninja, é claro que depois de terminar você já vai ter aprendido diversos truques, mas os mais as práticas mais elaboradas precisam de tempo e prática. Na teoria é tudo muito bonito e aparentemente fácil, quando você coloca a mão na massa você percebe que não é tão fácil e que requer muito estudo.
Segue mais alguns links interessantes sobre o assunto:
TDD é uma técnica de desenvolvimento de software onde você escreve seus testes antes de escrever o código da aplicação. Parece estranho, não? Como você vai testar algo que ainda não está pronto?
