Viagens, opiniões e afins

Na maioria dos livros que li nos últimos tempos do mais diversos assuntos ligados a engenharia de software, testes automatizados, e mais especificamente, TDD (test driven development) e BDD (behavior driven development) são dominantes. É certo que, atualmente, se desejamos ter qualidade e velocidade de entrega nos nosso produtos precisamos de testes automatizados. E vou além: digo que abordagens como TDD e BDD auxiliam o desenvolvedor a escrever código melhor e mais focado no valor para o cliente.

A questão é que se estabeleceu axiomas – verdades absolutas – onde para ser bom o projeto precisa ter 100% de cobertura de código e  ter testes unitários e testes de integração e testes de aceitação (tela e feature), etc. Isso nem sempre é verdade e pode ser um verdadeiro “tiro no pé”. Antes de mais nada é preciso entender a real função do teste. E qual será a melhor forma de utilizá-lo. Não estou discutindo aqui abordagens e sim se estamos usando de forma inteligente e consciente os testes.

Em uma conversa recente com Bernardo Heynemann, vimos, que, por exemplo, em alguns casos testes de aceitação que usavam Cucumber ou Pyccuracy, estavamos testando mais o navegador que a funcionalidade em si. Quando falamos de cobertura temos outro ponto interessante: 100% não é garantia de nada. Já ouvi falar  de sistemas com 100% de cobertura que quando foram fazer refactoring – confiando na cobertura de testes,  ”quebrou” tudo ao colocar em produção pois vários detalhes escaparam.  Isso porque, provavelmente existiam diversos testes que faziam “nada” e que ali estavam apenas para garantir a cobertura mínima.

Novamente citando Bernardo Heynemann, ele me disse que para os que estão começando, é importante seguir uma fórmula:  testes unitários, testes de integração, testes de aceitação, etc. Isso porque ainda estão formando sua base de experiência e tem pouco discernimento para saber quais seriam os pontos críticos a serem testados para termos a garantia de qualidade.  Mas a medida que for ganhando bagagem e aguçando seu senso crítico, é importante se questionar o que testar, como testar, etc.

Uma coisa que sempre falo é que testar da trabalho. Por mais que possa trazer benefícios, ainda é mais trabalho. Se falamos de testes automatizados – programáticos – é mais linha de código. Por exemplo, tiveram coisas que levei mais tempo escrevendo os testes do que implementando.  Teste onera sim.

Antes de mais nada quero esclarecer que não sou contra testes. Muito pelo contrário, acredito que não existe a possibilidade de fazer algo bem sem usar TDD ou BDD. A questão que levanto é o quanto estamos realmente testando nossos sistemas e o quanto estamos apenas “inventando” para cumprir com regras pré-definidas que ninguém de fato entendeu para que servem.

Um exemplo disso que estou falando é quando temos diversos níveis de teste em nossa aplicação … E testamos a mesma coisa em todos eles. Sabe aquele teste que você fica criando o Model, colocando os dados  no banco, acessando o banco, etc? Isso mesmo. É um bom smell disso que estou falando.

Uma coisa que faço é primeiro me concentrar no objetivo que quero atingir com aquele teste. Tudo mais é superfluo e logo pode ser ignorado(entenda mock e outras tecnicas).  Logo, se quero testar as chamadas do controller de minha aplicação, eu não preciso, nem quero me preocupar com que está acontecendo dentro do Model associado.   Outro ponto é se já testei algo em algum ponto, evito ficar testando novamente… Se por acaso isso for necessário é sinal que preciso fazer um refactoring no meu código.

Em futuro artigos pretendo trazer o assunto e ir mais fundo inclusive trazendo exemplos, trechos de código, etc.  Até a próxima.

Esse final de semana rolou o Flisol. O Flisol  é um evento de software livre. Fugindo da agenda comum de instalações e evangelizações, o pessoal da UniRio inovou mais uma vez e montou uma grade de palestras ampla e muito legal. Eu tive o prazer, junto com o Guilhermes Souza, de ser um dos palestrantes, onde falei de Código Legado abordando bem a questão de engenharia de software.

Durante o evento também tivemos a oportunidade de fazer uma reunião de trabalho sobre o DevinRio 2011 e posso dizer de agora que queremos continuar mantendo o nível e superá-lo.  Para dar um gostinho gravamos alguns depoimentos do pessoal que foi ao evento no sábado dizendo porque deve ir no DevinRio desse ano. Vale a pena conferir. Peço desculpas por faltar nome de alguns mas esse amigo aqui esqueceu de anotá-los. Obrigado  a todos.

Por que voce deve ir ao DevinRio 2011 from andre fonseca on Vimeo.

Depoimentos do pessoal no Flisol falando porque você deve ir no DevinRio desse ano

Numa conversa recente com alguns colegas do trabalho falamos sobre a questão onde o programador, amante de tecnologia, tende a esquecer alguns aspectos comerciais daquilo que ele está fazendo.

Qual de nós não quiz aquela oportunidade para usar a mais nova versão daquela biblioteca no seu projeto e ouviu um sonoro não do coordenador ou gerente ou qualquer outro que seja? Quem nunca ficou mega empolgado fazendo um mega refactoring no código e depois de mostrou para algum amigo a sua proeza onde um emanharado de coisas ficou mais compreensível ou melhor arquitetado?

Nós desenvolvedores por natureza, espero que a maioria, somos apaixonado por tecnologia. Tanto que acreditamos que isso seja a única razão de nossa existencia e esquecemos com frequencia qualquer coisas. Pois todo o resto é um mero coadjuvante da tecnologia.

A questão que isso dentro do nossos produtos, os quais estamos sendo pagos para fazer ou pretendemos ganhar dinheiro com ele acaba, em muitos casos, atrapalhando. Eu mesmo sou um exemplo disse: por várias vezes gastei um tempo considerável dentro de uma tarefa fazendo um reestudo e redesing sendo que poderia ter focado mais na entrega do valor ao cliente naquele momento.

Poucos de nós tem em mente que o foco princípal de nosso atividade é cliente satisfeito. Criamos parametros de medidas e raríssimos são aqueles que levam em conta se estamos ou não entregando mais ou menos valor. Isso até mesmo dentro de toda essa hype de ágil.

Temos métrica para dizer cobertura de testes; temos métricas para dizer o quanto nosso código é claro; verificar duplicidades; mas não nos preocupamos se no final o cliente está feliz (imaginaram um gráfico no quadro com o humor do cliente por entrega?)

Antes que pensem que penso que devemos é fazer as coisas de qualquer jeito e entregar pois isso é o importa para o cliente e ponto final … Bom senso é a palavra chave da mensagem que quero passar para vocês.

BOM SENSO

O grande segredo que devemos perseguir é encontrar o equilíbrio ideal entre entregar valor o quanto antes possível para o cliente sem abrir mão de qualidade.

Já vi milhares de pessoas adotaram tática de 100% de cobertura, políticas severas de escritura de código(exemplo: proíbido usar if) e isso depois virar um mega gargalo nas entregas. Ter código claro e bonito é legal, desde que isso ajuda a gente a atender o cliente pois é ele que nos paga.

Minha mãe sempre me dizia na minha infância:

O ótimo é o inimigo do bom

Temos que ter cuidado com esse nosso lado Geek de ser e dar uma suavizada nessa tendencia de só pensar na parte técnica da coisa e passarmso a ter uma visão total do produto. Depois disso, usar essa visão para definir o quão fundo vale a pena refatorar aquele código.

Como alguns que acompanham o blog já devem ter percebido, eu estou usando o SOLR em um projeto. O SOLR é um servidor Web de busca, feito em cima do Lucene (grupo Apache). Ele é realmente poderoso e simples de usar. Recomendo muito para quem precisa fazer buscar textuais pesados e que tem uma quantidade razoável de documentos/dados para indexar.  Como minha aplicação é Rails, estou usando uma GEM, chamada Sunspot, que serve de DSL (facilitador) nessa “conexão” entre minha app e o SOLR.

Nesse dias surgiu a necessidade de fazer uma nova feature em nosso sistema que parece ser bem simples mas como busco pelo SOLR a coisa ganhou bastante complexidade.Só para que entendam o problema, deixe me contextualizá-los.  Minha aplicação é uma ferramenta de seleção de pessoas – CASTING. Nela um administrador cria uma campanha e define um formulários com N perguntas que serão respondido pelo candidato. Ao finalizar o preenchimento, esse formulário vira um inscrições e salvamos suas respostas.  Surgiu então a necessidade de buscarmos por inscrições através de valores de respostas a perguntas específicas:  Quero buscar por todas as inscrições que responderam Vasco para a pergunta “Qual é o seu time do coração?”.

Muitos, se não considerarmos que estamos usando o SOLR e que vamos fazer essa pesquisa direto no banco de dados, vão dizer é a solução bem simples: Se resume a um query onde informo o campo e o valor de resposta desejado. Tendo isso busca pelas inscrições que tenha aquela resposta. Simples, não é? Nem tanto. O meu cliente deseja que isso esteja integrado aos demais filtros já existentes – idade, sexo, estado, status, etc.

Bem antes desse nova funcionalidade, a busca direto no banco, dado a quantidade de dados, já se mostrou inviável. Logo, sem chances de eu largar o SOLR e voltar para o banco ou tentar fazer algo híbrido.

Parte para tentar descobrir se existia algo dentro do universo do SOLR e/ou do Sunspot onde eu pudesse definir um campo do indice de forma dinâmica, ou seja, para cada instancia que for criando. Depois de um certo tempo gasto com o Oráculo (Google) , fiquei feliz que mais uma vez nem a gem nem o servidor me decepcionou.

O Sunspot tem um recurso que é o “dynamic field” que é o seguinte: todo o indice de sua classe é feito no build da classe, ou seja, no seu load.  Como precisava definir coisas que só existiriam no contexto da instância, eu precisa de algum recurso que me permitisse delegar a criação de alguns campos nesse momento de indexação (instancia). Esse recurso de “dynamic” é exatamente isso: ele  configura um bloco que será criado quando ele for indexar. Com isso eu pude buscar no SOLR por campos que só existem para algumas inscrições.

Em termos de código é mais ou menos o seguinte. Imagine que sua Inscricao tenha uma relação has_many com Resposta.

class Inscricao << ActiveRecord

has_many :repostas

end

A classe Resposta faz referencia a um campo de seu formulário. Logo a busca terá como nome do campo do indice o campo + id e seu valor será a resposta. Assim o mapeamento fica:

…

searchable do

dynamic :respostas do

respostas.inject({}) do |mapa, resposta|

mapa.merge({ resposta.campo.id.to_sym => resposta.valor})

end

end

end

Com isso acima, fica pronto a configuração. Para busca fica assim:

search do

dynamic :respostas do

with(:1, “teste”)

end

…

Assim estou buscando por Inscrições cujo a resposta a pergunta 1 foi teste. E pronto. A mágica foi feita.

Espero sinceramente que isso ajuda alguém como outros blogs que consultei me ajudaram. Fiquem em paz e até a próximo.