Sábado passado ocorreu aqui em Fortaleza o Ceará on Rails 2009,  segunda edição do evento desta comunidade aqui do Ceará. Eu, que ainda estou iniciando no mundo Rails, achei o evento bem positivo. É sempre muito bom ver a comunidade de desenvolvimento de software reunida e motivada em volta de alguma tecnologia, ainda mais quando esta tecnologia é o Ruby on Rails, que promove uma série de boas práticas e já nasceu com uma forte embasamento em metodologias ágeis.

O evento teve somente dois pontos negativos, mas que acabaram comprometendo o aproveitamento: a programação muito extensa e o atraso. Achei meio exagerado começar 14:00h e terminar somente 20:10h. Seria melhor se fosse divido pela manhã e tarde ou, melhor ainda, se fosse um evento menor, mais focado, talvez retirando-se a palestra de MAC (que não cabia muito ali) e alguma outra. E os atrasos fizeram com que as palestras fossem encurtadas, prejudicando a qualidade.

Como eu sabia que não iria conseguir passar seis horas direto no evento e estava cheio de coisas pra resolver no sábado (prefiro eventos durante a semana, em horário comercial mesmo) cheguei bem atrasado e peguei somente as três ultimas palestras.

A palestra do Anderson Leite, Pensando ao contrário. Por que você deveria considerar Rails no seu próximo projeto?, foi a mais interessante. Ele falou porque é bom procurarmos errar, roubar e precipitar. Devemos errar como forma de quebrar paradigmas e ir contra muitas coisas que estão por aí definidas como “certas”. Devemos roubar soluções como forma de nos apoiarmos em boas idéias e assim progredir de forma mais rápido. Ele citou como exemplo o Vraptor , que roubou várias idéias do Rails. E por fim devemos nos precipitar como forma de estar sempre buscando o novo. Na palestra ele também mostrou código com exemplos de metaprogramação do Ruby e como o Rails se aproveitou de tais recursos. Foi uma excelente palestra e com um bom equilíbrio entre conteúdo conceitual e prático.

Na palestra Testando Rails apps com Rspec, acho que o palestrante, Nando Vieira, foi prejudicado pelo tempo que foi reduzido (o evento estava bem atrasado). Ele mostrou bastante código com Rspec, mas não deu para absorver muito porque ele teve que passar os slides bem rápido e não dava nem para terminar de ler o código. De positivo ficaram as dicas de sempre utilizar TDD.

A palestra do Akita era uma das que eu estava mais motivado para assistir. Vi a palestra dele no Ceará on Rails do ano passado e gostei muito. O tema foi Filosofia RubyOnRails. Mesmo com todo o atraso ele ainda colocou um vídeo de uns 10 minutos de propaganda da Apple (feita pela 37 Signals) que poderia muito bem ter sido cortado. O começo propriamente dito foi bem legal, ele explicou um pouco da origem do Ruby e porque metaprogramação não era pra ser encarada como uma coisa tão exótica. Porém logo depois o assunto ficou mais para Filosofia Ágil do que Filosofia RubyOnRails. Falar de metodologias ágeis é bastante pertinente em qualquer encontro de desenvolvimento de software, principalmente de Rails, mas pra quem já tinha um certo background no “mundo ágil” foi algo como chover no molhado. Esperava ouvir mais de Rails. De qualquer maneira foi legal ele reforçar, de forma tão enfática, várias idéias e boas práticas. O ponto alto foi quando ele falou que se você não faz Extreme Programming você não faz Rails. Infelizmente já estava bem tarde e não pude ficar até o fim da palestra.

A palestra do Cauê, sobre CouchDB, era outra que eu esperava muito assistir, mas foi cancelada. Outra coisa chata foi a falta de energia, que demorou a voltar. Mas compensou pelos sorteios em que eu ganhei uma senha de acesso ao PeepCode .

No mais, o pessoal do Ceará On Rails está de parabéns. A comunidade é relativamente nova e já está conseguindo fazer eventos, gratuitos, com palestrantes de renome nacional e atraindo um público bem considerável. Espero que o evento se repita todo ano.

No ultimo dia 24 palestrei no terceiro encontro do grupo XPCE sobre automação de testes funcionais com Selenium. Estes foram os slides da palestra:

Em breve colocarei o projeto usado como exemplo.

No post anterior escrevi sobre alguns padrões para adoção de agilidade em um ambiente de desenvolvimento de software. Falei também que desta vez estamos utilizando uma abordagem utilizando os padrões Public Display of Agility e Iterative First, além do Start Small.

A utilização dos dois primeiros padrões impôs desafios diferentes dos encontrados na utilização dos padrões Stealth Mode e Technical Practices First (minha experiência anterior).

Uma das principais diferenças é que, por o Stealth Mode não chamar muita atenção, você tem mais liberdade para aplicar as práticas da maneira que achar melhor. Não precisa responder a muitas perguntas e nem assume de ante mão compromissos externos. Ou seja, pode trabalhar de forma bastante eficiente e não encontra muitas resistências.

Indo para o Public Display of Agility, entretanto, você estará chamando bastante atenção (como o próprio nome do padrão sugere) e, por metodologias ágeis ainda estarem longe de ser unanimidade, um certo jogo político tem que ser levado adiante. Um lado positivo é que você acaba ganhando o patrocínio das várias partes envolvidas, mas esse patrocínio as vezes vem com um preço um pouco alto. Por exemplo, algumas práticas ainda são encaradas como “muito radicais”.

Com Technical Practices First, a pesar de certas práticas “técnicas” serem bem difíceis de se dominar e possuírem certas dependências entre si, não é tão difícil sair da inercia. Por exemplo, se o time decide começar a fazer testes de unidade ou adotar integração contínua, existem disponíveis uma grande quantidade de material bem ao estilo “receita de bolo” e ferramentas bem simples de se trabalhar. Claro que leva-se algum tempo para se começar a trabalhar corretamente e entender o espírito da coisa, mas a sensação de estar perdido não é tão grande.

Porém, se o time decide ir pelo Iterative First, a adoção deve ser levada com mais cuidado e deve-se ter uma grande sensibilidade de como as práticas se encaixarão e principalmente mudarão a cultura da empresa. As primeiras práticas que serão abordadas são as gerenciais; e de gerência de projeto todo mundo entende um pouco, ou acha que entende Ou seja, é bem mais fácil encontrar resistências: infelizmente ainda há muita gente que acha que desenvolvimento de software deve ser feito de forma prescritiva e que devemos adotar as mesmas práticas gerenciais de outras engenharias. Também existem pessoas bem abertas a mudanças e enxergam as vantagens na aplicação de práticas ágeis, mas, por não terem um background sólido, não conseguem digerir os reais valores do Manifesto Ágil.

Ficamos então com o desafio de adotarmos como base uma metodologia de desenvolvimento ao mesmo tempo eficiente e que levasse em consideração todo esse cenário. Foi aí que o OpenUP se encaixou como uma luva às nossas necessidades:

• É um processo bastante enxuto e se encaixa bem em um contexto ágil (a gestão do projeto é quase que uma cópia do SCRUM). Práticas de outras metodologias também podem ser facilmente encaixadas no processo

• Por ser um Unified Process, traz possui conceitos que muitos já estão acostumados, diminuindo a resistência inicial:

• É iterativo e incremental

• É Baseado na utilização de casos de uso

• Desenvolvimento centrado na arquitetura do projeto.

• Possui foco em gestão de risco

• Mesmo sendo bem enxuto, engloba (quase) todas as disciplinas de software: Arquitetura, Gestão de Projeto, Gestão de Configuração, Desenvolvimento, Gestão de Requisitos e Testes

• Mesmo tendo que ser adaptado para a nossa realidade, é um processo que já está pronto para ser utilizado, contém um bom conjunto de práticas e artefatos, já com templates e “boas práticas” documentados

• Está todo documentado no EPF

• É disponibilizado através da Eclipse Public License: pode ser utilizado sem restrições.

OpenUP contém todas as melhores soluções para desenvolvimento de software? Acredito que não. Mas com essas características foi a solução salomônica para este momento inicial. Ainda estamos no começo (Start Small) e é difícil já fazermos algum jugamento da escolha, mas acredito que estamos no caminho certo, principalmente porque acabamos ganhando o apoio de muita gente boa.

É importante também ficar claro que a mudança de cultura de um ambiente não se trata somente de um mudança no processo ou metodologia de desenvolvimento e é um fator que também deve ser levado em conta, tendo desafios ainda maiores.

Mesmo com sua adoção crescendo ano a ano e comprovadamente trazendo ganhos de produtividade para projetos de desenvolvimento, metodologias ágeis ainda encontram bastante resistência e ainda tem uma adoção relativamente pequena aqui no Brasil. Existiria então uma forma mais indicada de transição para uma abordagem ágil de acordo com as características de cada ambiente?

O Mike Cohn documentou alguns padrões interessantes para adoção de agilidade e os dividiu em três pares antagônicos que são:

• Start Small ou Go All In?

Começar a adoção com um projeto piloto ou já começar com a grande maioria dos projetos da empresa?

• Technical Practices First ou Iterative First?

Focar primeiramente nas práticas de engenharia ou nas práticas de gestão?

• Stealth Mode ou Public Display of Agility?

Serão esperados os primeiros resultados para que a adoção seja tornada pública ou ela será divulgada de ante mão?

Dentre estes padrões, o caminho mais seguro e menos traumático é a combinação de Start Small, Technical Practices First e Stealth Mode. Foi essa combinação que funcionou muito bem em meu emprego anterior e, encontrando as mesmas condições, tentaria adotá-la em qualquer outro ambiente.

Adotando Start Small e Technical Practices First não se precisa de tanto apoio das hierarquias superiores e conseqüentemente pode-se atuar sob Stealth Mode. Como, até meio que paradoxalmente, as hierarquias superiores são as que menos conhecem e mais resistem às abordagens ágeis, o time pode evoluir sem encontrar muitas resistências nos estágios iniciais e, principalmente, sem ser talhado pela equipe de “qualidade”. Claro que vai chegar um momento em que o apoio será necessário, porém os resultados já alcançados servirão de prova de que desenvolvimento ágil não é coisa de adolescente frustrado ou programador revoltado.

Essa combinação, no entanto, possui um lado negativo considerável: é a mais lenta. Adotando-a, demoramos em torno de três anos para que começássemos a ter um impacto organizacional mais abrangente (demora também ocasionada pelo tamanho da empresa), mesmo resultados positivos tendo estado presentes desde os primeiros meses. E a razão da sua vantagem é também o motivo da sua desvantagem. Sem o apoio corporativo, o time pioneiro sente dificuldades de levar a adoção adiante e depende muito de esforços homéricos dos envolvidos para que as dificuldades naturais da adoção não comprometam o andamento do(s) projeto(s), gerando ruídos e quebrando o Stealth Mode.

Seria então está combinação a mais indicada para todos os ambientes? Acredito que não. Algumas forças devem estar presentes para que esta combinação seja a mais indicada:

• Já existe na empresa um processo de desenvolvimento “tradicional” bem estabelecido e controlado. Geralmente em empresas que tem ou buscam o selo CMMI e que acabam considerando abordagens ágeis uma ameaça para o processo de avaliação e controle de “qualidade”.

• O time tem um perfil técnico muito bom, os membros são proativos e comprometidos na busca de melhores formas de desenvolver software.

• Os integrantes do time devem, em grande parte, se manter constantes.

Aqui na SEFAZ, por termos outro cenário (com vantagens e desvantagens) estamos adotando outra estratégia, mais próxima da combinação Start Small, Iterative First e Public Display of Agility. O padrão Go All In traria resultados ainda mais rápidos, mas acho demasiadamente arriscado. O ponta pé inicial ainda não foi dado, mas estou animado com o comprometimento que estamos obtendo em todos os níveis e espero que em breve eu tenha boas notícias para dar.

Template Method sempre foi um dos meus padrões favoritos, porém quando aplicado de forma exagerada acho que ele trouxe mais prejuízos do que benefícios.

A principal razão é que ele acaba dificultando o tratamento de erros da aplicação: ao padronizar o comportamento de alguma operação para uma hierarquia de classes, ele acaba também padronizando as exceções lançadas pelo método, e é aí que está o problema.

Um dos principais problemas que vejo em aplicações legadas é o tratamento de erros feito de forma inapropriada. Já vi algumas pessoas criticando, mas considero um excelente recurso da linguagem Java a existência de Checked Exceptions, utilizadas para erros que podem precisar de um tratamento particular.

Na implementação de uma biblioteca ou de um framework, checked exceptions talvez não sejam tão interessantes. Mas, na implementação de aplicações, considero um recurso bem valioso principalmente para aquelas divididas em camadas.

Template methods não casam bem com checked exceptions pelo seguinte motivo:

abstract protected void validar(Entidade entidade);

abstract protected void logarOperacao(Object algumaCoisa);

public void salvar (Entidade entidade) {
    this.validar(entidade);
    this.dao.persistir(entidade);
    this.logarOperacao(algumaCoisa);
}

Um código como esse é comum em frameworks caseiros ou arquiteturas de referência. Geralmente fica em uma classe chamada MeuManagerGenerico, ou algo do tipo, e as diversas classes de negócio, específicas de cada entidade, devem implementar o método de validação e o método de log. O único problema com está abordagem é que você não está “amarrando” somente a assinatura e o algorítimo para salvar uma entidade, está também dizendo que nenhuma operação “salvar” do sistema lança uma checked exception.

A não ser que sua aplicação seja 100% CRUD, sem nenhuma restrição de unicidade em nenhum atributo, acho que essa é uma restrição muito forte e que não se aplica.

Dessa forma, se alguma regra de validação ou regra de negócio específica não for atendida, como você comunica para a camada superior (provavelmente a camada de visão) sobre o problema ocorrido? A única maneira é lançar unchecked exceptions.

Usando unchecked exception, como as camadas superiores saberão quais exceções lançadas pelas camadas inferiores? A única saída seria a camada inferior antecipar o tratamento dado ao erro, de maneira que a camada superior não precise trata-lo. Já vi muito essa abordagem com a exception tendo como atributo a chave da mensagem que será exibida ao usuário. Dessa forma a camada superior iria somente exibir a mensagem, não importando qual seja a exceção. Isso é um exemplo claro de quebra da divisão de responsabilidade entre as camadas. Se as camadas inferiores tem que antecipar de alguma forma a maneira como as camadas superiores fazem o tratamento de erro, porque você divide sua aplicação em camadas em primeiro lugar?

Esse um bom exemplo de que “amarração de código” e antecipação de necessidades podem trazer prejuízos não antecipados. Imagino que desenvolvedores que fazem template methods para operações com algoritmos simples como “salvar”, “atualizar”, “deletar”, etc só podem ter duas coisas em mente:

1. Economizar código.

Esse pensamento vem do falso sentimento de que uma aplicação enxuta é uma aplicação com pouco código. Temos que tomar cuidado pra não exagerar nas simplificações e não enxergar abstrações onde elas não existem ou são prejudiciais.

2. O desenvolvedor pode esquecer de fazer a validação ou gravar o log ou qualquer coisa do tipo, então “amarra-se” esse algoritmo em um template method.

Se seu desenvolvedor não sabe como fazer uma validação correta ou alguma dessas operações, ele não deveria colocar as mãos no código sem que estivesse fazendo programação em par com outro mais experiente.

Mesmo com essa armadilha, ainda acho válida a utilização do template method, mas somente nos raros casos onde se pode antecipar os erros de toda a hierarquia de classes e quando a complexidade do algoritmo justifique essa abordagem.

Iniciamos um processo de decisão sobre qual servidor de aplicação passaremos a utilizar em nosso ambiente. A motivação é que o velho Jboss de guerra não está mais dando conta do recado. Não que o Jboss não seja um ótimo servidor, muito pelo contrário. A questão é que o seu ponto mais criticado, a administração, começou a cobrar seu preço. Iremos aumentar consideravelmente o número de servidores em produção (assunto outro post) e uma interface de administração central, mais produtiva e confiável, passou a ser uma necessidade.

Depois de uma análise prévia, vimos que duas soluções poderiam atender nossas necessidades: Glassfish ou Jboss + JON.

O Glassfish é uma promessa que virou realidade, mas confesso que ainda não me convenci, culpa mais pela pouca experiência que tenho com esse servidor do que por sua qualidade, que ele é a melhor solução para o nosso caso. De qualquer maneira, nesses estudos prévios e na apresentação do Kohsuke, acabou subindo muito no meu conceito.

O Jboss já é um velho conhecido e ainda está no páreo, levando em consideração a utilização do JON. O JBoss Operations Network me pareceu ser uma ferramenta realmente fantástica que permite a administração e monitoramento de muitos e muitos e muitos pontos, desde o sistema operacional, passando pelo servidor de aplicação e chegando nas aplicações. Seu lado negativo é que é uma ferramenta paga.

Tomcat está fora da jogada. A maioria das nossas aplicações utilizam Spring, mas algumas mais novas já estão em EJB e futuramente iremos para o Jboss Seam ou Web Beans, como preferirem (também assunto para outro post). Ainda existem algumas outras alternativas, mas a princípio os principais candidatos são esses dois mesmo.

Bem, a análise ainda está em andamento e os principais pontos ques estamos analisando são:

- Administração: facilidade de administrar e monitorar remotamente múltiplas instâncias de servidores.

- Performance: para essa avaliação buscaremos análises de instituições independentes.

- Ambiente de desenvolvimento: facilidades de utilização do servidor de aplicação no ambiente de desenvolvimento:  integração com o Eclipse, tempo de start up e deploy, facilidade de debug, hot deploy, etc.

- Documentação técnica: disponibilidade e qualidade da documentação técnica disponível: manuais, tutoriais, wiki e fóruns

- Suporte técnico: disponibilidade de suporte 24×7. Considerando custo, meio (apenas via web e e-mail ou por telefone também), idioma (em português ou inglês) e tempo de resposta.

- Aderência à especificação: aderência à especificação Java EE 5, incluindo a velocidade em que são lançadas novas versões da ferramenta quando saem novas versões da especificação.

- Custo da migração: custo associado à migração do ambiente atual para o servidor de aplicação escolhido. Atualmente temos aplicações em produção tanto no Jboss quanto no Glassfish

- Custo do software: custo de aquisição de ferramentas necessárias para administração ou desenvolvimento no servidor de aplicação.

- Cases de sucesso: existência de casos de sucesso de sistemas em produção usando o servidor de aplicação.

Estes dois servidores possuem um grande comunidade de usuários, então, caros colegas e recém chegados leitores, sintam-se a vontade e estimulados a deixar algum comentário caso tenham alguma opinião ou experiência relativos a qualquer um desses pontos do Glassfish ou Jboss + JON.

Oi pessoal, nesse primeiro post vou falar de testes automatizados. Quem me conhece sabe que esse é um assunto que me interessa muito, mas desta vez o assunto não é teste de unidade, e sim testes funcionais, muitas vezes chamados de teste de aceitação.

A realização de testes funcionais é uma prática bem mais difundida do que testes de unidade. É uma disciplina presente em qualquer metodologia de desenvolvimento, até mesmo porque o cliente em algum momento do ciclo de vida do projeto vai querer verificar se o que foi desenvolvido satisfaz suas espectativas.

O que não é uma prática difundida é a automatização dos testes funcionais e sua utilização desde as fases iniciais do desenvolvimento. Enquanto testes de unidade vem ganhando atenção, principalmente com a popularização de metodologias ágeis como XP, a automatização de testes funcionais, também defendida por esta metodologia, não tem ganho a mesma atenção.

Em vários projetos já vi diversos motivos para o não investimento na automatização. O mais comum, infelizmente, é nem sentir sua falta. Se se trabalha com um processo cascata, a fase de teste só é realizada uma vez (no final do projeto) e não existe muito overhead para ser eliminado. Nesses projetos a equipe geralmente tem tantos pepinos que qualidade de software chega a ser um luxo.

Em outros, a preocupação com qualidade do software parte de quem realmente bota a mão na massa: os desenvolvedores. Estes, por estarem muito envolvidos com aspectos de baixo nível, se preocupam em testar o código e delegam, de certa forma, o teste a nível de usuário para a “equipe de teste” ou para o cliente mesmo. Pelo menos era assim que eu agia.

Mesmo sem a preocupação com a automatização de testes funcionais, estava tudo funcionando perfeitamente. O investimento em testes de unidade estava dando um ótimo retorno e, aliado a algumas outras práticas,  fazia com que as iterações terminassem em sua maioria sem nenhum bug e com o cliente bastante satisfeito. Porém, os sistemas em que trabalhei com essa abordagem tinham algo em comum: os testes de unidade eram feitos a partir do dia zero.

A frustração veio quando, ao entrar em um projeto em andamento e com alto índice de instabilidade, testes de unidade não mostraram ser uma boa ferramenta para começar a resolver o problema. Neste projeto as entregas não eram confiáveis. O sistema tinha muitos bugs e, a medida que eles eram corrigidos, outros apareciam ou retornavam. Intuitivamente, para identificar os bugs e evitar que eles voltem, pensamos em adotar testes de unidade. Porém não obtivemos a resposta esperada.

A causa era simples: Uma grande vantagem dos testes de unidade é a exposição de locais em que o design do código poderia ser melhorado. Dessa forma, ao implementar os testes de forma tardia, você vai achar diversos pontos em que o sistema precisa de uma refatoração. Mas como realizar as refatorações necessárias se a cobertura dos testes ainda está bem pequena e não te dá garantia que não vai quebrar o sistema?

É aí que entra a automatização dos testes funcionais. Por ser um teste completamente caixa preta, você pode de maneira bem mais rápida alcançar uma boa cobertura dos testes. Daí em diante você vai se sentir mais seguro para fazer as refatorações necessárias, de preferência já encaixando os testes de unidade também. Além, claro, do ganho óbvio na identificação de erros no sistema.

Pretendo em outros posts falar mais da automatização de testes funcionais. Nesse primeiro momento queria somente destacar sua importância, principalmente para sistemas legados. Posteriormente espero escrever sobre quais ferramentas e práticas estamos utilizando, além da dificuldade e benefícios encontrados.

Functional tests are the first type of tests any application should have. If you had to choose between writing unit tests or functional tests, you should choose the latter.

Junit in Action