Desenvolvimento Ágil - Blog da Improve It: Tag TDD

Improvecast 22: Entrevista com Edson de Lima

Vinicius Manhães Teles — Fri, 02 Nov 2007 17:02:00 -0200

Acaba de ser publicado o Improvecast 22 no qual entrevistei Edson de Lima, que falou sobre a implantação do Extreme Programming na LeoSoft, uma empresa do Paraná que contou com o treinamento Imersão Ágil há alguns meses e está trabalhando com o XP desde então. Eu havia escrito há algum tempo sobre como foi o Imersão Ágil na LeoSoft e o pessoal de lá nos concedeu este depoimento. Se quiser, você também pode ver as fotos do treinamento.

Falamos sobre diversos assuntos relacionados à adoção do XP e também sobre a implantação do MPS.BR na LeoSoft. Antes do treinamento Imersão Ágil, a LeoSoft havia iniciado um processo de implantação do MPS.BR junto a outras empresas da região. Algum tempo após o Imersão Ágil, começou de fato a implantação do MPS.BR em um dos projetos da empresa. Isso está sendo um desafio, visto que a filosofia do MPS.BR é, em vários aspectos, bem diferente da filosofia do Extreme Programming. Esta é uma das questões que discutimos no Improvecast 22. Se você quiser saber mais sobre o MPS.BR, escute o Improvecast 8.

Ouça a entrevista com Edson de Lima!

Barrigas abertas

Vinicius Manhães Teles — Thu, 11 Oct 2007 10:08:00 -0300

O Marcelo Baltar fez alguns comentários, nesse artigo, sobre a utilização do CruiseControl no processo de integração contínua e eu gostaria de levantar algumas considerações. Preferi fazer isso através de um novo artigo. O Marcelo cita o seguinte:

"Parabéns, mais um excelente post. Mas devo dizer que eu também tenho uma preferência pelos testes assíncronos (CruiseControl-like ;) ). Além das questões técnicas, já bem exploradas no seu post e em alguns comentários, esse tipo de abordagem aproxima-se mais dos conceitos pregados pelas metodologias 'ágeis'.

No meu entender é mais proveitoso o desenvolvedor 'commitar' seu trabalho o quanto antes (lógico, com os devidos testes implementados) e já avançar para as próximas tarefas ao invés de ser obrigado a passar por todo esse processo de integração 'pré-commit'. Afinal de contas, quão realmente grave/problemático seria o commit de código que quebra o que está no repositório? Pela minha experiência, isso acontece pouquíssimo, e quando acontece, graças a granularidade dos commits, pode ser facilmente corrigido."

Marcelo, muito obrigado pelo comentário. Compreendo sua percepção de que o uso do CruiseControl possa estar mais associado a metodologias ágeis, porém não compartilho essa mesma visão. Acredito que isso tem a ver com a interpretação do que seja uma "metodologia ágil". Não sei se você chegou a ler o artigo sobre agilidade x Agilidade. O termo "ágil" não está associado apenas ao conceito de velocidade, mas sim ao Manifesto Ágil e seus princípios.

Um dos valores fundamentais no mundo ágil é feedback. Receber feedback cedo e agir sobre ele rapidamente. A forma de receber feedback e atuar sobre ele é diferente dependendo se você utiliza um modelo de integração síncrona ou assíncrona. No assíncrono, o feedback tende a ser mais demorado e pode passar despercebido. Por exemplo, se ele vier por email, pode ser que o desenvolvedor não esteja consultando os emails com freqüência. Isso é comum de acontecer em XP, por exemplo, devido à programação em par e outros fatores.

Desenvolvimento ágil também está relacionado a entregar software funcionando. Então, cada novo código introduzido no projeto tem que estar funcionando para gerar valor de verdade. Por essa razão, o código que vem do repositório tem que estar em ordem permanentemente. O uso de uma ferramenta como o CruiseControl, pelas razões descritas acima, permite a existência de código quebrado no repositório. Ele não leva a isso, mas permite.

Nos projetos que eu conheci, que utilizavam CruiseControl, era comum o repositório estar quebrado. A razão era sempre alguma coisa "boba" que ia ficando lá porque ninguém queria parar para consertar. Nós aqui chamamos isso de "barriga aberta". Pense em um cirurgião. Quando ele vai operar uma pessoa, ele abre a barriga, faz o que precisa ser feito e fecha, antes de partir para outra cirurgia. Ele não abre a barriga de um, começa a operar e, em seguida, abre a barriga de outro antes de terminar a primeira cirurgia (como ilustrado abaixo). Ele sabe que isso seria perigoso e improdutivo. Nós não. Nós somos de computação, então a gente adora fazer aquilo que parece rápido, mas costuma gerar dores de cabeça mais adiante. :-)

Ilustração de Leandro Mello.

Na minha opinião, fazer um commit e partir para outra atividade, antes de receber feedback sobre o que foi colocado no repositório é o mesmo que "deixar uma barriga aberta". Para nós, desenvolvedores, que estamos sempre ansiosos para passar para a próxima atividade, é tentador demais seguir com o próximo cartão, mesmo enquanto ainda há pendências no atual. E o modelo de integração assíncrona permite isso. Já a integração síncrona, não. Ela obriga o desenvolvedor a parar momentaneamente, ter certeza de que tudo correu bem e só então prosseguir para a próxima atividade. Isso está alinhado a um princípio do XP chamado passos de bebê. Acredito que o importante não seja a velocidade com que partimos para a próxima atividade, mas sim quão rápido conseguimos entregar código que temos certeza de estar funcionando.

Outra questão, também ligada ao feedback é o próprio tempo de execução dos testes. A integração síncrona, para funcionar, exige testes que executem rapidamente. Mais de cinco minutos para integrar já é um problema. Kent Beck costuma dizer: se essa atividade é difícil, execute-a freqüentemente. Fazer builds que executem rapidamente é desafiador. É algo que exige atenção permanente. A integração síncrona nos obriga a ter essa atenção e nos leva a melhorar os testes quando o tempo cresce. Na assíncrona, é fácil demais deixar os testes demorarem cada vez mais e não fazer nada a respeito.

No meu entender, essa é uma questão sistêmica, ou seja, no curto prazo, trabalhar com o CruiseControl pode parecer uma boa idéia, pela aparente velocidade que ele traz ao processo de integração. No médio e longo prazo, entretanto, o comportamento da equipe, influenciado pelas facilidades oferecidas pelo CruiseControl, atrapalham o projeto. Digo isso com base no que pude observar em projetos que usavam o CruiseControl. Entretanto, cada projeto é uma realidade. Se no seu caso o CruiseControl funciona e não causa os problemas sistêmicos que mencionei, use-o. No meu caso, ainda prefiro a integração síncrona.

Nosso processo de integração contínua

Vinicius Manhães Teles — Fri, 05 Oct 2007 09:45:00 -0300

O Lucas Húngaro deixou-nos um comentário pedindo que escrevêssemos sobre nossa infra-estrutura de controle de versão, integração contínua, testes unitários e cobertura de código para projetos Rails. Ótima pergunta! Muito obrigado, Lucas.

Nós utilizamos o Subversion como repositório e optamos por um modelo de integração contínua síncrono. Isso significa que toda vez que um desenvolvedor precisa integrar, ele roda uma script do Rake que faz o update do código, executa todos os testes, verifica a cobertura de código e, se tudo estiver em ordem, faz o commit do código.

Nós trabalhamos com 100% de cobertura em todos os projetos. Para isso usamos o Rcov. O script de integração executa a análise de cobertura antes de cada commit e cancela a integração caso o desenvolvedor tenha esquecido de fazer os testes para um código recém-introduzido.

A integração síncrona obriga o desenvolvedor a aguardar a execução do script de integração, antes de partir para outra tarefa de programação. Isso é bom porque evita que a gente comece outra coisa antes de saber que fizemos corretamente a atividade corrente. Além disso, ter que esperar pela execução do script nos leva a ter atenção permanente com o tempo de execução dele. Se crescer muito, a gente o aprimora para reduzir o tempo. No geral, tentamos manter o tempo de execução sempre abaixo dos cinco minutos.

O contrário da integração síncrona é a assíncrona, que utiliza algum servidor, como um CruiseControl. Nesse caso, o desenvolver faz o commit, o qual dispara um script no servidor do CruiseControl. Ele executa todos os testes e demais verificações enquanto o desenvolvedor já passou para outra atividade. Algum tempo depois ele recebe um email ou outro tipo de notificação avisando se tiver acontecido um erro. É um modelo interessante em várias circunstâncias, mas nos projetos que fazemos tentamos evitá-lo. James Shore escreveu um excelente artigo que resume as razões para não usar o CruiseControl. Nossas razões são basicamente as mesmas.

Para os testes unitários, utilizamos o Test::Unit, naturalmente, além do Mocha para os mock objects e o Selenium on Rails para os testes de aceitação.

Podcast "Tudo que quero saber"

Marcos Tapajós — Mon, 27 Aug 2007 18:03:00 -0300

Eduardo Fiorezi publicou mais um podcast da série "Tudo que quero saber!". Dessa vez foi sobre disciplina em projetos com eXtreme Programming e eu fui entrevistado junto com o Danilo Sato.

Fiquei muito feliz com o convite do Eduardo e em conhecer o Danilo, com quem já troquei algumas figurinhas sobre o Dojo-SP. Obrigado Eduardo !

Mais informações sobre o podcast aqui.

Plugin Brazilian Rails

Marcos Tapajós — Fri, 06 Jul 2007 21:30:00 -0300

Acabei de publicar no RubyForge a primeira versão do plugin Brazilian Rails.

Desde que eu comecei a programar em Ruby, usando o Ruby on Rails, sempre adorei o sistema de plugins, onde facilmente podemos incorporar novas funcionalidades que atendem a vários projetos.

Sempre tive vontade de colocar nossos códigos disponíveis como plugins mas nunca tive tempo para fazer isso. Inevitavelmente continuo sem tempo mas agora estou contando com um time de amigos que resolveram me ajudar. São eles:

André Luiz Kupkovski (Ancar)
Celestino Ferreira Gomes (Ancar)
Rafael Fraga Walter (Ancar)
Fernando João Manfroi (Ancar)
Luciene Souza Luna (Ancar)

Esse plugin surgiu da necessidade de usar o método error_messages_for para sinalizar na camada de vista os erros encontrados nas validações do nosso modelo. Essas mensagens eram em inglês, o que fazia com que os desenvolvedores tivessem que implementar algo semelhante no RHTML.

Acabamos notando que várias outras coisas poderiam ficar mais simples aos brasileiros usando-as como estamos acostumados. Por exemplo, nosso formato padrão de data é DD/MM/AAAA mas Ruby não trabalha da mesma forma. Para solucionar esse problema fizemos uma implementação que modifica o método to_date do modulo String para lidar com esse nosso formato.

Esse nosso primeiro release não abrange todas as nossas implementações mas resolvemos publicar o quanto antes para poder contar com o feedback dos nossos usuários e melhorar continuamente.

Trata-se de um projeto Open Source, onde gostaríamos de contar com a colaboração da comunidade Brasileira com sugestões e quem sabe com novos desenvolvedores. Minha única exigência com relação aos patches é que eles venham acompanhados de testes.

Quem quiser experimentar nosso plugin basta executar uma única linha e reiniciar sua aplicação Rails.

script/plugin install -x \
svn://rubyforge.org/var/svn/brazilian-rails

Como temos vários tipos de códigos diferentes devemos fazer outros plugins em breve !