Pode se argumentar que se trata de uma questão cultural, que a grande maioria dos desenvolvedores acham que o banco de dados deve ser o integrador de aplicações. Pensando rapidamente até faz sentido, já que todos os dados estão lá e as histórias de integração se resumiam a ler ou escrever dados fora do controle do sistema.

Eu defendo que se trata de visão míope, completa incapacidade de enxergar a longo prazo ou com um horizonte mais amplo. Qual sistema relevante de integração não possui comportamento a ser aproveitado? Ao utilizar um RDBMS simplesmente se anulam as chances de explorar todo código e regras de negócio já existentes. Uma pessoa letrada em desenvolvimento de software tem a obrigação de enxergar isso, de possui olho de peixe.

Agora se sua aplicação for desenvolvida apenas como uma casca para um repositório de dados, seja ele prevayler ou OODBMS ou relacional, ela vai entregar muito pouco valor para o cliente, nem o mínimo para ganhar o rótulo de moderna. Eu, e o Phillip também, gostaríamos mesmo de ver uma evolução no mercado, de existirem mais pessoas entendendo que hoje que escalabilidade e paralelismo também estão relacionados a desenvolvimento e deployment – conceitos estes que estão intimamente relacionados com a forma como uma aplicação se apresenta ao mundo.

O Refactoring browser do smalltalk desenvolveu uma mini linguagem nesse sentido, para facilitar localizar, por exemplo, as invocações de um dado métodos. Finalmente esse poder chegou ao Java. Desenvolvido como um plugin para o Eclipse, o Semmle Code permite executar queries muito semelhantes ao SQL sobre projetos Java. Só de olhar o tutorial você já fica com água na boca com as possibilidades.

Os exemplos do próprio site já são muito interessantes, e mostram como essa ferramenta permite extrair informações extremamente uteis sobre uma base de código com muita facilidade. Quer saber quais classes possuem atributos públicos, use a seguinte query:


from Field f, RefType t

where f.hasModifier("public")
and
not(f.hasModifier("final"))
select f.getDeclaringType().getPackage(),
f.getDeclaringType(),
f


Muito simples, e, para completar, o plugin tem várias formas diferentes de visualizar o resultado. No geral, achei uma ótima ferramenta, vou explorar um pouco mais como ela funciona, mas pelo pouco que já ví, sei que vou acabar usando muito.

Testes que podem ser executados várias vezes são uma vantagem a partir da segunda vez que são necessários, pela minha experiência após uma certa prática no assunto, o custo de codificar um teste é quase o mesmo de executá-lo manualmente duas vezes. Esse custo diminui ao longo do projeto, quando vários elementos reusáveis dos testes aparecem, chegando a ser próximo do mesmo da execução manual.

Existem várias categorias de testes: funcionais, unitários, de integração, caixa-branca, caixa-preta, bla, bla, bla. Acho que no final das contas podemos dividir os testes em duas categorias: os que ajudam os desenvolvedores e os que medem o progresso do projeto. Os primeiros servem para verificar partes do sistema que não se traduzem em requisitos funcionais, os testes unitários de uma classe, por exemplo. Os outros são os testes funcionais, são os mais importantes também, pois, além de tudo, podem medir o nível de confiança de um projeto em entregar no prazo com qualidade.

Testes funcionais são os mais dificeis de escrever e planejar. Existem alguns cuidados que devemos tomar, o pricipal é substituir os sistemas externos por versões sob nosso controle, coisas como banco de dados e web-services são faceis o resto vai exigir mais trabalho. É crucial fazer isso em vez de usar recursos compartilhados, pois senão eles podem deixar de ser determinísticos, falhando sem motivo. Banco de dados em memoria são a melhor ferramenta que você pode querer, eu utilizo o HSQLDB eu não tenho do que reclamar.

Finalmente, temos várias ferramentas para ajudar a escrever os testes, tais como Fitnesse ou Selenium, cada um tem sua utilidade e recomendo explorá-las para saber quais ferramentas você tem a mão. Elas ajudam muito a criar os testes e permitir que eles, caso necessário, sejam reusados e integrados no processo de build da sua aplicação.

Testes funcionais, quando automatizados, são o artefato mais importante de um sistema, pois certifica que o conjunto de funcionalidades verificados funciona. O valor dessa garantia é muito grande depois que você sente a diferença.

O principal critério que eu tenho para graduar um experimento para pet-project é conseguir produzir um demo razoavel. Sempre fui assim e considero um critério razoavel. Estou a 18 meses indo e vindo com essa JVM para conseguir produzir um Hello World, e existem uma enorme gama de problemas envolvidos com isso, dos quais a maioria foram causados por minha falta de conhecimento do assunto.

Primeiro tive que aprender tudo sobre o assunto e ter alguns falsos inícios – protótipos que foram descartados por completo. Depois tive que construir um compilador nativo Java capaz de se compilar, isso envolveu uma série de evoluções na arquitetura que sempre atrasavam muito o tão desejado hello world. Por final, agora estou enfrentando o problema de adaptar o compilador estático e a intraestrutura de execução para funcionarem como uma máquina virtual.

O fato mais marcante que eu vi ao longo desse projeto foi que sempre que eu conseguia um avanço significativo ele pode ser atribuido a uma evolução nos testes automatizados do projeto. O compilador passo a funcionar direito quando eu criei um conjunto pequeno da ordem de 70 testes para verificar o comportamento dele, isso me permitiu evoluir com uma taxa de defeitos muito baixa. Estou agora escrevendo outro conjunto de testes para verificar o comportamento da máquina virtual, eles já me ajudaram a encontrar vários bugs.

No atual rítmo devo em breve implementar JNI e finalmente ter como escrever java.lang.System. Depois disso, é dar continuidade aos elementos que deixei para traz, como melhor conformidade a especificação e suporte a multi-threading. O legal deste meu pet-project é que dificilmente vou ficar sem coisa para fazer e a dificuldade nunca diminui.

Eu sempre tentei usar ao máximo automação de testes, quase sempre foi com os unitários, só que mais por conta da forma que eu desenvolvo. Agora que recentemente eu começei a usar pesadamente os funcionais, posso dizer que é o melhor investimento que uma equipe pode fazer em um projeto.

Primeiro que dificilmente um sistema não vá sofrer manutenções grandes ao longo de sua vida útil, então simplesmente o fato de poder executar de forma barata um enorme conjunto de testes é muito bom. Segundo, pela minha pouca experiência, automatizar testes funcionais custa em termos de tempo, pouco mais de 1,5x o custo de executá-los manualmente. Logo, na segunda execução você já entra no lucro.

Finalmente, uma boa suite automatizada de testes te da muito mais liberdade e segurança para fazer manutenções mais ousadas, de forma mais agil e gastando menos tempo.

Eu desenvolvi uma suite de testes funcionais para a JVM que estou escrevendo, ela é bem pequena, mas serve por enquanto para garantir todo funcionamento básico do sistema, e todo bug que encontro ganha mais um teste para aumentar sua robustes. Só isso me permitiu refatorar e reestruturar o sistema todo com poucos bugs sobrando.
Então, se você quiser dar uma sugestão para o seu gerente que vai melhorar em muito a qualidade dos sistemas produzidos pela sua equipe e reduzir custos, diga para ele que testes funcionais automatizados devem ser escritos para todo o sistema.

Compartilhar dados é estupido, exponha o comportamento do seu sistema.
Isso mesmo, avisar os desenvolvedores da outra equipe para eles usarem alguns selects que sua equipe definiu para fazer a integração é uma idéia horrivel. Os dados são a parte menos expressiva e ao mesmo tempo a mais sensivel do sistema.

Todo sistema depois que cresce além do trivial embute muito valor semântico aos dados que existem no banco, se você integrar nesse nível todos vão precisar saber isso ao risco de fazer ou ver a coisa errada. Ainda para piorar, essa técnica vira uma barreira à evolução, você não pode alterar o schema e continuar com suas alterações até que todos sistemas relacionados sejam também atualizados. Moral da história, integração feita no banco de dados é como se em um casamento os noivos trocassem pedaços de víceras em vez de alianças.

Tudo bem, já disse que é ruim, mas como fazer isso então? Crie uma série de serviços que expoam a funcionalidade pública do seu sistema e deixe o resto por conta da criatividade das outras equipes, elas vão agradecer. Isso normalmente significa lançar mão de usar EJB, CORBA, RMI e, principalmente, Web Services. Esse uso de Web Services é o que eu classifico por SOA pragmático, aquele que existe por algum propósito justo, existe para avisar e mostrar ao mundo as coisas que seu sistema pode fazer, como ele se comporta.
As vezes é meio chocante ver que com todo esse marketing feito por todos vendedores empurrando SOA não teve o menor impacto positivo. A parte que sofre mais parece ser a que menos adota esse tipo de tecnologia. Mas enfim, espero que esse post tenha servido pelo menos para avisar do desastre anunciado que é compartilhar as entranhas do seu sistema com os demais.

Senso comum é um ótimo exemplo de aversão a mudanças. Ele surge porque alguém disse que viu outros fazendo e pareceu legal. Só ver que assim que se fala em usar EJB a maioria já pensa nos DTOs que vão precisar escrever, ou melhor, VOs, para sermos fieis às origens.

Alguém já usou, já fez, já falou do assunto. Muito já ouviram e repetiram. Pronto, já virou senso comum. A partir desse ponto não fazer assim é querer mudar as regras do jogo e para isso precisamos pensar, propor, discutir e confrontar os demais. Para isso acontecer é preciso estar armado de argumentos, razões e motivos, ter uma boa dose de coragem para tirar todos da zona de conforto de uma coisa já formulada e pensada por outros.
O senso comum é nada mais que uma manifestação de um problema ainda maior, o medo que mudanças e suas incertezas carregam. Podem ver, existe muita gente que adora de escorar nisso para justificar ações e medidas descabidas. Inércia de questionamento causa isso, você não se pergunta o por que de algo acontecer por tempo suficiente até assumir que se trata de uma verdade, o famoso concenso por omissão.

Garantir que esse feedback ocorra, e em tempo habil para ser útil, é obrigação do lider do projeto, que deve criar o espaço e habito entre os demais. Tem formas razoaveis de fazer isso, como, por exemplo, instituir semanlmente um code-review das classes que aparecerem mais feias em um relatório de métricas ou pedir que uma pessoa mande o trecho de código mais cabeludo do atual projeto dela para ser sabatinado.

O mais importante nisso tudo é evitar que se crie uma bola de neve de desenvolvedor inexperiente criar aquela obra de arte impossivel de se manter e que é rotulada de legado antes mesmo de ir para o ar.

Espero então que esse post sirva pelo menos para todas as vítimas de programadores júnior – aquelas que tiveram que se aventurar em códigos por eles escritos – entenderem que tem de dividir a culpa.

Um software existe muito além da entrega; ele precisa funcionar corretamente, precisa atender a demanda inicial e precisa estar pronto para os próximos desafios. Não muito diferente de fazer o primeiro filho, duas pessoas que precisam aprender a ser pais e garantir que nada de ruim vai acontecer durante a gestação – vão fazer os tais exames pré-natal.

Ainda que fazer um software não seja apenas chegar ao ponto de gritar “Está pronto!”, muito gerente prefere fazer assim. Ordena que a execução seja feita dessa forma, sem permitir que prestem atenção aos, então correntes, detalhes do projeto. Coisas bobas como qualidade, escalabilidade e manutenibilidade. Chega ser realmente estranho, já que a grande maioria deles adora ter um grande portifólio de “***dade” na manga.

Por essas e outras que processos tradicionais de software falham. Testes não devem ser feitos somente no final de um ciclo de desenvolvimento, devem ser feitos com o menor intervalo possivel e para todos os critérios que são importantes. Testes automatizados são fundamentais para isso, caso contrario a equipe de testers precisa ser do tamanho da torcida do Flamengo.

Escrever código de teste só é perda de tempo pro desenvolvedor se ele não for capaz de enxergar todo o ciclo de vida daquilo que programa. O desafio é conseguir mostrar a matemática disso para um gerente. Olha que isso é uma coisa que os ginecologistas já aprenderam a muito tempo – cuide bem daquilo que você cria.