Frederico Benevides

Reinventar a Roda 09/03/2009

Desde que eu mudei para Brasília, trabalhei com vários tipos de aplicações. Algumas, ou quem sabe maioria destas aplicações, eu vi o que a maioria é acostumado de ver, funcional por fora, mas internamente, horrível de se trabalhar.

Algumas destas aplicações o que eu nunca consegui entender, é como o pessoal reinventa a roda! E como REINVENTAM! Se fossem boas, tudo bem, mas a maioria não é. Pra ser sincero, não lembro de um destes se teve UM que valeu a pena, mas não vou chegar a ser tão crítico.

Eu nunca gostei disso, pois atrapalham muito o desenvolvimento. Estas implementações geralmente não existem testes, e o pior, na solução existente poderia estar trabalhando no meu negócio e não nos problemas da estrutura de um framework.

Para se ter uma idéia, um dos frameworks mvc que trabalhei, nele encontrava mais outro mvc, o struts. O negócio era uma bomba, que futuramente eles implantaram o struts para algumas partes do sistema. Infelizmente, legado é legado e logo muito da bomba ainda continuava lá, tanto que ele chegou a ter um problema que após uma certa quantidade de usuários, permitia que alguns usuários acessavam com perfil de outros usuários. Imagina o problema disso…

Já vi também criarem sistemas para controle de bugs, sendo que, existem muitos sistemas bons e livres tais como trac e bugzilla. Agora se pudessem parar pra analisar o tempo e o dinheiro que gastou com analistas e desenvolvedores para implementar este software, sairia mais barato pagando licença do Jira. E uma pequena observação, sairia mais barato e teria um sistema bem melhor.

Outra, trabalho com uma aplicação que até inventaram a camada de persistência, e o pior, os que desenvolveram achavam que o design era ótimo. Até já teve uns bugs que por exemplo, se fosse buscar uma pessoa pelo id, o que retornava era apenas um o objeto pessoa com o seu atributo ID sem o restante das informações do usuário. Pois é, era mais fácil fazer new Pessoa(id)…

Nesse tempo, o que eu cheguei a perceber, ou pelo menos parece com o pensamento de certos tipos de desenvolvedores: “Eu sou um bom desenvolvedor e sei fazer a minha própria aplicação, não preciso de soluções existentes”. Claro que eu não sei o que passou na mente de cada um para reinventar a roda, mas será que já perguntaram para si mesmo: “O que a minha aplicação terá o que as outras não tem?”, ou quem sabe pensar: “Vale a pena o tempo que vou gastar para desenvolver do que estudar um outro framework?”.

Lembre-se, reinventar a roda nem sempre é o caminho para uma solução, e sim, apenas o começo de alguns problemas.

Testes… O salvador! 02/03/2009

Este primeiro post vou escrever sobre um assunto que até para muitos já estão cansados de saber, que é sobre o uso de testes no desenvolvimento de software. Neste post não vou explicar como fazer testes unitários na sua aplicação, vou falar um pouco das experiências que eu tive usando testes, mais especificamente com o JUnit.

Desde que eu comecei a “brincar” com testes fiquei meio viciado. O vício aconteceu quando eu comecei a ver que, a segurança que o teste me provê é inverso aos problemas que terei. Pois quanto de nós já deve ter tido problema de ter que arrumar algo que antes funcionava, perder tempo para concertar erros por causa de alguma outra manuntenção que quebrou o seu código. Perder horas, ou dias, por problemas que foram inseridos e não testado corretamente antes de subir para algum ambiente. Pois é, ninguém gosta disso, tanto desenvolvedor, ou até mesmos os responsáveis pela empresa em que trabalha, pois perda de tempo, é dinheiro jogado fora. Então, por mais que leve um tempo maior para implementar com mais segurança, é melhor ter um tempo maior de desenvolvimento, do que em um breve futuro seu código possa ser quebrado por causa de atualizações de outras pessoas, ou até mesmo as suas próprias atualizações.

Um exemplo do que passei aqui no serviço. Tinha um aplicativo, na verdade, uma classe que FAZIA TUDO, que sempre dava problema. Cheio de if, else, e o escambau. Então me passaram o serviço de eu corrigir um bug nessa classe. Eu olhei aquilo novamente, e pensei, desse jeito não dá e resolvi fazer um projeto separado, fiz testes. No final do projeto já tinha 22 classes, e uns 60 testes. O detalhe não é a quantidade de classes ou mesmo testes, mas sim que nesse meio tempo o teste me “salvou”, pois tinha momentos da minha implementação que quebrava algo que eu tinha que corrigir. O projeto demorou um pouco mais por causa dos testes, mas pelo menos , ou por enquanto, esse projeto está livre dos problemas enfrentados aqui no serviço e que já tomou tempo de vários desenvolvedores.

Então pessoal, vamos tentar ser mais profissionais, pois como sabemos, software sempre muda, e o testes ? Bem… este poderá um dia ser o seu Salvador!