Refatorando Padrões

Como de costume estava lendo vários posts via Google Reader (infelizmente também abandonei o Bloglines devido a vários incômodos bugs), quando me deparei com este post

O livro para download gratuito é simplesmente simples e simpático e o modo como TDD é mostrado encanta.

Não entendo a insistência de muitos programadores em não criar testes, o tempo que se gasta agora criando testes vai impedir que vários erros e transtornos com o cliente surjam no futuro, o custo é muito menor agora.

É interessante notar como alguns programadores seguem padrões com afinco, até as últimas consequências, onde houver código lá está ele impondo todos os padrões possíveis. Existe a boa prática em separar comportamento e apresentação, no caso de páginas HTML, os arquivos javascript são o comportamento e os arquivos CSS a apresentação, e o HTML faz uso de ambos, como pode ser observado aqui.

Observem o exemplo:

Algo que tem-se pregado por aí é retirar o totalmente o Javascript do HTML, ou seja, o exemplo acima ficaria assim:

E teríamos um arquivo .js com o seguinte código para ligar o evento onclick do button:

Puxa vida, toda essa volta só para não usar a propriedade onclick no HTML e se livrar totalmente do Javascript, isso vale a pena ?

Há vários motivos para que eu não concorde com isso:

• Mais código para dar manutenção, foram criadas várias linhas de javascript para algo que funcionaria no primeiro exemplo usando a propriedade onclick da tag input.
• E quando eu quiser saber qual evento o button aciona, será fácil de achar ? Podem haver vários objetos na página, todos com seus eventos ligados apenas no momento do onload da página. Vários objetos é igual a várias linhas de código javascript com as ligações, se você estiver usando um editor de textos comum, bem... boa sorte, e mesmo com uma IDE não é tão simples assim.
• A propriedade onclick, onkeypress, etc faz parte da especificação HTML, justamente para facilitar isso, porque iria deixar de usá-los ?

Então muito cuidado ao seguir padrões ao extremo, questione-os, cada um tem o seu lugar e hora certa.

Não sei se um dia vou entender qual o medo das pessoas em aceitar mudanças, ainda mais em pessoas da área de informática. Elas são inevitáveis, é a evolução. Quando chega o momento em que deve-se alterar código que já está funcionando, é praticamente um "parto" convencer outros de que isso é bom.

Martin Fowler, em seu famoso livro Refactoring: Improving the design of Existing Code (em português "Refatoração: Aperfeiçoando o Projeto de Código Existente"), já dizia que refatorar é: "modificar um sistema de modo que seu comportamento não se altere, mas que sua arquitetura melhore, fique mais limpa". Um dos meus livros prediletos, praticamente livro de cabeceira. Inúmeras técnicas de como melhorar seu código.

É muito comum encontrarmos código duplicado, e mais comum ainda observar que o programador não reaproveitou o código porque precisava refatorá-lo, por puro medo de "quebrar" outra parte do sistema. Oras, pra isso existe TDD (Test Driven Development), se criássemos testes não haveria nenhum medo em quebrar outras partes do sistema, as quebras seriam imediatamente visíveis. E refatorar ficou ainda muito mais simples com as IDEs atuais, qualquer uma possui mecanismos poderosos para auxiliar esta tarefa.

Refatorar nosso código, mesmo código antigo, constitui menos manutenção no futuro, pois refatorar é também diminuir a complexidade e quantidade de código. As partes duplicadas no sistema, se contiverem quaisquer erro ou necessidade de mudança na regra de negócios, vai realmente tirar seu sono, pois obviamente nunca sabemos onde estão as cópias. Uma regra de negócio ou erro poderia ter sido resolvido com uma única "martelada" no lugar certo em um código "enxuto".

Então sem medo de refatorar, você não está perdendo tempo agora, está na verdade economizando tempo de manutenção.