Seguindo com o post sobre código limpo, estamos agora na 3ª parte do mesmo e falaremos sobre:
- Testes de unidades (TDD)
- Classes
- Sistemas
1 - Testes de unidades (TDD): muita gente torce o nariz quando se fala sobre testes unitários pois é um empenho realmente grande para que os testes funcionem, mais ainda para que funcionem corretamente.
A ideia de se ter um teste é que você possa ter a certeza de que a mínima alteração em algo no seu código não afetará outros pontos do mesmo, ou, se afetar, você sabe exatamente onde foi e o corrige imediatamente. Em um primeiro momento pode parecer inútil ter um teste unitário pois afinal de contas sua produtividade ficará mais "lenta" e isso é bom! Tá brincando né? Quer dizer que eu desenvolver mais lentamente é bom, explique-me!
É bom sim. Pense em um sistema onde deve ser convertido o valor de moeda de real (BRL) para dolar (USD), hoje funciona perfeitamente todas as conversões se dão com sucesso e você sabe exatamente onde e como está sendo realizada esta conversão. Imagine que você não tem um teste para tal funcionalidade e que depois de 1 ano e meio que o sistema está no ar seu cliente pede para que seja realizada a conversão para euros. Você (re)começa a trabalhar no sistema, cria o método que realiza a conversão para euro seguindo a mesma lógica do método que converte para dolar. No entanto percebe que há dois métodos realizando a mesma coisa, e isso caracteriza-se como duplicação. Com isso você decide apenas modificar o método de conversão de dolar alterando seu nome para um nome genérico e adicionando um parâmetro de entrada para informar qual conversão deseja utilizar (se dolar ou euro), aplica a proporção de conversão e realiza manualmente um teste fornecendo um valor em reais para que seja convertido em euro, funciona!!!
Logo você acredita que está tudo ok pois incrementou uma nova funcionalidade "sem estragar outra", lembrando que você não criou um teste unitário para tal e estava com a maior pressa do mundo, com isso subiu a nova funcionalidade e informou seu cliente que está tudo certo. Alguns instantes depois seu cliente liga e informa que a conversão para dolar está sendo realizada errada, ou seja, tanto em dolar quanto em euro sempre converte para euro. Você tem que parar o que está fazendo e mexer novamente em um sistema que deveria estar funcionando perfeitamente. Se existisse um teste unitário para tal conversão, você se veria obrigado a rodá-lo e constataria imediatamente que a conversão para dolar está errada, assim corrigiria antes de atualizar o módulo para o cliente e evitaria este atrito. Neste ponto você perde mais tempo tentando corrigir sem talvez saber o que causou o erro do que se tivesse criado o teste e visto imediatamente onde o mesmo ocorreria, assim dirigindo-se ao ponto exato para tal correção.
O exemplo fornecido acima é muito obvio pois novamente estamos falando de apenas um fragmento de código e dificilmente um programador atencioso deixaria este tipo de detalhe passar, ou melhor, deixaria de testar manualmente se ambas as conversões estão funcionando corretamente. No entanto ao falarmos de um sistema de médio ou grande porte ou uma grande equipe de programadores este cenário se tornaria muito mais propício a este tipo de erro.
Automatize seus testes: O conceito de desenvolver orientado a testes (TDD - Test Driven Development) serve para que você teste de forma automática os pontos cruciais do sistema afim de certificar-se de que nada vai funcionar fora do esperado. Como dito anteriormente você em um primeiro momento pode até perder um pouco de produtividade no desenvolvimento do sistema no entanto mais a frente este esforço valerá muito os minutos de atraso, pois em caso de alguma modificação no código pode ser visto logo ao rodar os testes e corrigido antes mesmo de o cliente testar ou pior ainda, ter algum prejuízo.
Dica: Pesquise mais sobre TDD e xUnit, vale a pena!
Utilize controle de versão: Nada pior que estar editando um trecho de código em um determinado arquivo e coincidentemente outro programador mexendo exatamente no mesmo arquivo, no momento de salvar você se depara com uma mensagem de que o arquivo sofreu alguma modificação e lhe questionando se deseja manter sua alteração ou carregar o arquivo novamente no editor. Programadores experientes ou que trabalham em projetos fechados de empresas geralmente utilizam sistemas de versionamento.
Qual a vantagem de utilizar um sistema de versionamento? Há muitas vantagens, dentre elas estão: possibilidade de trabalhar em grandes equipes sem sobrescrita de código, maior segurança e, uma das mais importantes na minha opinião, log de alterações. Com o log você sabe exatamente de quem puxar a orelha em caso de um erro, brincadeiras a parte, mas isso é muito importante, saber quem ,o que e quando fez.
Dica de um sistema de versionamento bastante difundido e de fácil utilização: Git
2 - Classes: Para ser concisa uma classe deve ser, segundo o autor do livro pequena e ter responsabilidade única! Responsabilidade única nem preciso explicar, mas como assim, todas as classes devem ser pequenas? Sim, sempre que possível! O ideal é que as classes tenham o mínimo de linhas possível para que sua leitura se torne fácil e objetiva.
Pense em uma classe como se fosse uma caixa de ferramentas, como você a prefere, uma gaveta grande onde você coloca tudo ali de forma desorganizada ou pequenas gavetas onde você possa separar todas suas ferramentas por tipo?
3 - Sistemas: Pense em um sistema como a administração de uma cidade, por mais que ela seja pequena não há a mínima possibilidade de uma pessoa gerenciar todos os recursos sozinha. Assim mesmo acontece com um sistema, separe as responsabilidades, não deixe uma classe cuidar de muitos recursos, mais vale um código bem segmentado com diversos "membros" realizando sua tarefa específica do que uma classe gigante que tenta estar por dentro de tudo que se passa em seu sistema. Os sistemas devem ser inteligentes e trabalhar ao seu favor e não lhe dar dor de cabeça.
Leia também:
Código limpo parte 2
Código limpo parte 1