Em qual DAO colocar minha SQL?

Descobrir métodos que podem não estar em seus melhores DAOs pode ser algo útil quando pensamos em medir a dívida técnica dos nossos projetos. Para isso, podemos fazer uso de heurísticas para detectar esse tipo de método. Heurísticas e métricas de código são maneiras rápidas e baratas para detectar problemas em nosso código.

Decidimos então bolar algumas regras, baseadas em nossa experiência, de quando um método está no DAO mais correto. Imagine que estamos olhando para os métodos da classe XDao. A boa prática é que XDao seja a classe responsável por acesso aos dados da entidade X. Então, basicamente olhamos para a assinatura de cada método desse DAO: se na assinatura, ele de alguma forma faz uso de X (retorna X, recebe X como parâmetro, faz uso de algum sub-tipo de X, etc), então esse método está no lugar certo.

Obviamente é difícil garantir que se um método apresentar alguma dessas características, ele está no DAO correto. Mas, dado que nossa experiência dizia que na maioria dos casos, isso era verdadeiro, decidimos avaliar se estávamos certos. E para isso olhamos para todos os DAOs de 3 projetos nossos. Criamos um protótipo de ferramenta que olha a assinatura de todos os métodos dos nossos DAOs e nos diz se o método está ou não dentro dessas regras.

Com o resultado em mãos, o apresentamos para um desenvolvedor do projeto dizer se concordava ou não com o resultado da heurística. E, para nossa surpresa, a heurística acerta na grande maioria das vezes!

Para um dos projetos, tínhamos 590 métodos dentro de DAOs, dentro dos quais a ferramenta disse que 79 deles possivelmente estavam em lugares errados. Isso quer dizer em torno de 14% dos métodos. Quando um desenvolvedor do projeto olhou todos eles, ele concordou com a ferramenta em 59 métodos, ou seja, em 75% dos casos! Tivemos resultados parecidos para os outros 2 projetos avaliados: Em um deles, de 13 métodos marcados como possivelmente errados, o desenvolvedor concordou em 8 deles (60%). No outro, dos 33 errados, o desenvolvedor concordou em 16 deles (50%).

Ou seja, a heurística parece fazer sentido. Veja que a ideia de uma métrica de código não é dizer precisamente se uma classe tem ou não determinado problema, mas sim dar um bom indicativo. E veja, dos quase 600 métodos, a ferramenta selecionou apenas 79. E inspecionar manualmente 79 métodos é algo que sua equipe consegue fazer com um custo razoável (ainda mais sabendo que o acerto da heurística é superior a 50%); já inspecionar manualmente 600 métodos custa caro.

Por fim, lembre-se que escrever código de qualidade é difícil. Qualquer ferramenta que nos avise de possíveis problemas é de grande ajuda. Se você gostou do assunto, pode ler mais sobre o paper que publicamos no MTD2014, o Workshop Internacional sobre Dívida Técnica, que aconteceu esse ano, em Victoria/Canadá. Você pode ver a simples implementação do nosso protótipo no Github, e até executá-la em seus projetos.

E nos seus projetos? Você sofre muito para encontrar uma determinada SQL? Já repetiu código nos DAOs, sem querer?