A última palavra em rastreabilidade

A versão 0.5 do Motiro vai incluir um meio de acompanhar funcionalidades: saber o que entra no próximo release, o que fica de fora e votar no que você acha mais importante. Isso é bom para as equipes, que vão conhecer a vontade dos usuários e priorizar seu trabalho de acordo. Também é bom para os usuários, que vão saber o que esperar da evolução da aplicação e, melhor ainda, influenciar nesta evolução.

O Motiro já tem um pouco de integração com sistemas de controle de versão e, por isso, tive a grande idéia: prover algum meio de ligar um trecho de código à funcionalidade correspondente ("Este código aqui é para realizar a tradução da página"). Com isso poderíamos rastrear trechos de código para requisitos de usuário e vice-versa.

Acontece que minha idéia não é tão boa assim.

Na verdade, eu até diria que é uma má idéia. Fazer rastreamento desse jeito é jogar trabalho fora. Rastreabilidade é uma coisa ótima, mas acontece que no Motiro já usamos o que há de mais novo em termos de rastreabilidade.

Não, não temos nenhuma arma secreta escondida que não esteja publicada no site do projeto ou no próprio código fonte. Não usamos nenhuma ferramenta complicada, não desenhamos nenhum diagrama e muito menos mantemos uma matriz potencialmente gigantesca.

Não temos nada disso. Mas o Motiro é testado.

Nenhuma funcionalidade é desenvolvida e nenhum defeito é corrigido sem o teste correspondente. Portanto, para todo requisito há pelo menos um teste e descobri-lo é fácil, tão fácil quanto olhar seu título. Se quero saber que trecho de código implementa uma funcionalidade qualquer, é só olhar que trecho de código é executado pelo teste correspondente. Se quero saber por que alguma linha foi escrita, basta apagá-la e ver que teste falha.

Essa abordagem para rastreamento, ao contrário das outras que citei, não exige nenhum esforço extra por parte da equipe de desenvolvimento. Afinal, qualquer equipe que esteja realmente interessada em produzir software de qualidade vai ter algum mecanismo automático para verificação. Na maioria dos casos esse mecanismo é um conjunto de testes automáticos.

Os objetos estão te matando?

Ou é você quem acha que a culpa é deles?

Hoje eu achei um exemplo de código ruim atribuído ao uso de objetos. O interessante é que se você olhar bem, o código na verdade é procedural. Só porque você está usando uma linguagem ou biblioteca com suporte a orientação a objetos, não quer dizer que você esteja programando orientado a objetos. Este é um engano bastante comum. Você já deve ter conhecido algum sistema por aí que parece ter sido construído sobre duas exigências básicas:

1. Usarás uma linguagem orientada a objetos
2. Escreverás somente código procedural

Dava até pra colocar numa tábua de mandamentos.

O objetivo do código do exemplo de Jeff Attwood que disparou este artigo é renderizar um trecho de XML. Vamos dar uma olhada:

1   System.Text.StringBuilder sb =
      new System.Text.StringBuilder();

    XmlWriterSettings xs = new XmlWriterSettings();
    xs.ConformanceLevel =
      ConformanceLevel.Fragment;
5   xs.Indent = true;

    XmlWriter xw = XmlWriter.Create(sb, xs);
    xw.WriteStartElement("status");
    xw.WriteAttributeString("code", "1");
10  xw.WriteEndElement();
    xw.WriteStartElement("data");
    xw.WriteStartElement("usergroup");
    xw.WriteAttributeString("id", "usr");
    xw.WriteEndElement();
15  xw.WriteEndElement();
    xw.Flush();
17  return sb.ToString();

Este trecho de código é totalmente procedural, e foi escrito usando uma linguagem e uma biblioteca de objetos (acho que isso é C# junto com alguma biblioteca .Net para XML). A grande estrela desse código é o objeto conhecido por 'xw'. Ele aqui está sendo usado como um elemento passivo, mero cumpridor de ordens. Tudo que ele precisa fazer é explicitamente requisitado:

— Xw, comece a escrever um elemento 'status'.
— Sim, senhor!
— Xw, escreva um atributo chamado 'code' com valor '1'.
— Sim, senhor!
— Xw, está bom, pode fechar este elemento.
— Sim, senhor!

... e assim por diante. Dar ordem expressas assim é característica de código procedural, que se confunde com o código imperativo. E código imperativo tem esse nome justamente porque é estruturado ao redor de um conjunto de comandos (ou ordens) básicos.

Esse tipo de argumento anti-objetos parece acontecer muito mais por causa da interface de uma biblioteca do que pelo uso de objetos. Bibliotecas diferentes vão ter interfaces diferentes. Este trecho de código Ruby enviado por um leitor do blog dele exemplifica bem:

  builder = Builder::XmlMarkup.new(:target=>STDOUT,
                                   :indent=>2)
  builder.person { |p|
     p.name("Jim")
     p.phone("555-1234")
  }

Aqui o estilo é muito mais declarativo. Quase idêntico a escrever o código XML você mesmo, mas sem os perigos de se tentar escrever manualmente em uma linguagem feita para máquinas.

A questão aqui não é a dicotomia orientado-a-objetos x procedural. Talvez isso nem exista. Como o exemplo em C# mostra, é possível escrever código procedural orientado a objetos. Além de possível, é bastante comum. A discussão na verdade é entre os estilos declarativo e procedural.

Quem será que ganha essa última?

Testando os testes

"Ter testes automáticos para validar o código é muito bom. Você pode refatorar o código livremente, os testes te ajudam a saber que você não quebrou nada e bla bla bla."

Você muito provavelmente já escutou essa conversa. Esse é o discurso padrão dos xispistas e de quase todo mundo na comunidade ágil. Todo mundo fala que os testes servem para manter a aplicação saudável, mas o código dos testes também é código e ele precisará ser refatorado mais cedo ou mais tarde. Já aprendemos que não dá pra acertar da primeira vez no código de produção, achar que no de teste dá seria ingenuidade.

Já que não dá, fazemos com os testes o mesmo que fazemos com a aplicação. Escrevemos um pouco de cada vez e refatoramos conforme necessário para não repetir idéias, minimizar o acoplamento e alcançar todas aquelas outras coisas boas que aprendemos na escola (ou que a experiência nos ensinou).

Quando estamos refatorando o código da aplicação, confiamos no código de teste para não nos deixar cair. Mas quando é o código de teste que estamos refatorando não há uma segunda rede protetora, não há testes que testem os testes que testam o que deve ser testado (eu sei que ficou confuso, foi de propósito). Na verdade, podemos ir em frente e escrever os meta-testes.

Mas talvez não precisemos.

Os testes não estão tão desprotegidos assim. Há a aplicação para garantir que eles não estão fazendo nada errado. Ela foi escrita especialmente para passar naqueles testes e pode ser usada para garantir que o comportamento deles não está mudando, que eles estão checando o que checavam anteriormente. Se não alterarmos o código da aplicação quando estivermos reestruturando o dos testes, sair de uma barra verde para outra é razoavelmente seguro.

Há uma sinergia muito grande entre os dois tipos de código. O código de teste segura o de produção e o código de produção segura o de teste. Quem já viu dois amigos tentando voltar para casa depois de saírem de uma festa embriagados sabe como é isso. Nenhum dos dois vai chegar muito longe sozinho, mas quando estão juntos um pode contar com o outro se tropeçar.

Ajudando no burburinho

Web 2.0 tá na moda, mais na moda do que aquelas músicas eletrônicas intercaladas com assobios. Por todo lado que eu olho tem alguém falando dela. Toda semana aparece mais uma aplicação hospedada em um domínio terminado em 'o.us'. Parece que todo mundo está usando bordas redondas e dá pra achar tags em todo site que entro. Outro dia desses minha mãe veio comentar comigo que a era da informação tinha acabado, que estávamos entrando agora na era da participação.

Tá bom, esta última não é verdade (a frase na verdade é de Jonathan Schwarts, agora CEO da Sun). Mas do jeito que as coisas andam, bem que podia ser. O fato é que Web 2.0 há muito tempo virou uma palavra de moda e seu sentido está cada vez mais obscuro. Para falar a verdade, todos os aspectos que citei no parágrafo anterior me lembram a tal segunda versão da web. Todos eles marcam de algum modo essa nova revolução.

Mas o que eu acho mais interessante é a frase de Schwartz. As pessoas deixaram de ser apenas consumidoras de informação para serem produtoras. O que estamos vendo não é uma revolução tecnológica, mas uma reviravolta cultural provocada pela evolução tecnológica. Nesse novo mundo as comunidades são as grandes responsáveis pela informação e comunidades são feitas de pessoas. Cada pessoa faz um trabalho pequeno, algo que tome tão pouco tempo que ela não se importa em cedê-lo. A grande mágica é a informação brotar da interação entre as pessoas. É assim que foi construída a Wikipedia, que hoje já é a maior enciclopédia do mundo.

Uma aplicação totalmente Web 2.0 que descobri há pouco tempo é o site last.fm. Ele é uma gigantesca base de dados sobre música construída quase que exclusivamente por seus usuários. Você se cadastra, instala um pequeno plugin no seu tocador de música e tudo que você escutar vai sendo enviado para o site. Seus dados são cruzados com os dos outros usuários e o sistema é capaz de sugerir algumas músicas com base nisso. Há também o aspecto Orkut da coisa. Depois que o sistema recebe uma certa quantidade de músicas suas, ele diz quem são seus 'vizinhos musicais', gente que tem gosto parecido com o seu.

Outra bem útil é o site digg.com que apesar de terminar em ponto-com, é uma das coisas mais Web 2.0 que se pode ter. As pessoas usam o site para indicar coisas interessantes que elas acharam (escavaram) na Internet e há um sistema de votação. As histórias mais populares vão borbulhando até a pagina principal e as menos populares ficam escondidas em alguma página obscura.

Curioso é que se olharmos por outro ângulo, vemos que toda essa revolução na verdade talvez seja uma volta às origens. Há alguns artigos, textos e páginas nessa grande rede que são verdadeiros fósseis cibernéticos. Vestígios de um tempo em que a rede era habitada por programadores, cientistas e outras criaturas mitológicas atualmente em extinção. Estes fósseis nos contam uma história de um lugar intocado pela bolha ponto-com dos anos 1990 onde ainda não havia grandes portais. Nesse lugar o conteúdo também era gerado por indivíduos e era interessante descobrir como as coisas se interligavam. As pessoas se comunicavam através de redes formadas por listas de discussão e grupos Usenet (você já ouviu falar nisso? Eles ainda existem!) e faziam páginas pessoais, uma espécie de ancestral dos blogs.

O que estamos observando hoje é somente a vontade de se comunicar, de fazer diferença e de ser parte de algo maior potencializada pelos avanços da tecnologia. O poder de informar (e desinformar) está sendo transferido dos grandes feiticeiros para o usuário comum.