edit

O desenvolvimento do Just-remind.us

Publicado por Vinicius Manhães Teles há aproximadamente 1 ano.

Enquanto estou de castigo aqui em São Paulo, aguardando o vôo de conexão que me levará ao FISL, achei que seria uma boa comentar um pouco sobre o desenvolvimento do Just-remind.us.

A idéia original era fazer um "projetinho" de uma semana. Mas, um "projetinho" nunca é um projetinho, estão, acabamos gastando três semanas. A equipe de desenvolvimento era composta por três pessoas: Tapajós e eu na programação, e o Leandro no design. Eu e o Leandro trabalhamos full-time, quatro dias por semana, enquanto o Tapa foi part-time.

O protótipo básico da aplicação, com a tela dos cartões e o formulário de edição, ficou funcional ao final do primeiro dia. Afinal, o sistema não poderia ser mais simples. Então, com um pouquinho mais de trabalho, poderíamos ter colocado o sistema no ar em dois ou três dias certo? Depende. Queríamos passar um tempão corrigindo bugs após o deploy, ou a idéia seria terminar este projeto e começar outro sem se preocupar com bugs no Just-remind.us? Definitivamente a gente prefere a segunda opção.

Odeio corrigir bugs e morro de vergonha quando encontram um bug em algo que eu fiz. Então, só há uma opção, óbvia por sinal: testar freneticamente. Mas, parece que tudo que é óbvio tem uma tendência incorrigível de ser negligenciado. Mas, não aqui.

Nós fizemos muitos testes no Just-remind.us. Para começar a explicá-los, vejam a imagem abaixo:

A primeira parte da imagem mostra o resultado de um rake stats no projeto. Como se pode ver, são 548 linhas de código Ruby, contra 1419 linhas de código de Specs, ou seja, 2.6 vezes mais linhas de Specs que linhas de código da aplicação. Nos Specs, nós temos 223 exemplos que cobrem 100% das linhas de código do projeto (segundo o RCov).

A segunda parte da imagem mostra a execução de um rake stats_with_selenium. Mais, hein? Pois é, nós usamos o Selenium exaustivamente para fazer testes funcionais. Na boa, não dá para fazer uma aplicação web sem usar algo assim. Sério, não dá! Se você acha que dá, me desculpe, mas você é um fanfarrão! :p

Uma coisa que sempre me incomodou no rake stats é que ele não diz nada sobre os HTMLs e o Selenium. Mas, eles também representam uma parte significativa do projeto. Então, pedi ao Tapa que fizesse uma nova versão rake stats que contabilizasse também o Selenium e isso é justamente o que está na segunda parte da figura.

Note que só de Selenium nós temos 1311 linhas de código. A contagem total agora considera 865 linhas de código da aplicação e 2730 linhas de código de teste. Agora, são 3.2 vezes mais código de teste que da aplicação. Nada mal! O Selenium executa 1243 validações através de 58 cenários de teste.

Agora vem a pergunta: faz sentido todo este esforço para uma aplicação tão pequena? Essa pergunta está incorreta, para ser honesto. a pergunta certa é: faz sentido não fazer este esforço? Minha resposta para esta última é, definitivamente, não.

A quantidade de problemas que nós detectamos com estes testes e, sobretudo, a gravidade destes problemas, é surpreendente. Mesmo em uma aplicação ridiculamente pequena como esta, a quantidade de detalhes é inacreditável. Um aspecto que nos preocupou muito era a segurança dos dados dos usuários. Descobrimos vários problemas de segurança fazendo os testes. Obviamente corrigimos todos bem antes de colocar o sistema em produção. Agora eu pergunto: e se nós não tivéssemos feito os testes? Você ficaria feliz de saber que seus dados estão registrados em um sistema que mais parece um queijo suíço, de tanto furo de segurança que tem?

Bem, o sistema está no ar há dois dias. Até aqui, tivenos, no total, 839 visitantes únicos, 1044 visitas e 5069 page views. Não é muito. Mas, é interessante notar que ainda não houve nenhum bug reportado. Provavelmente deve existir algum problema ainda, porque a quantidade de detalhes realmente é grande. Mas, até agora está tudo bem. Exatamente o que nós queríamos que acontecesse. A única bobeira que nós demos (e já sabemos) foi de design. Ontem à tarde nós colocamos uma nova versão no ar, que tinha um errinho de CCS, bem visível na primeira página. Mas, isso foi corrigido pouco tempo depois. A propósito, se vocês detectarem algum problema, por favor, nos avisem.

Desenvolver software sem testes não é apenas coisa de fanfarrão. É coisa de irresponsável. É impossível uma atividade tão complexa quanto desenvolver software ser conduzida sem testes automatizados, em uma quantidade absurda. Quer dizer, possível é, mas não é aceitável. Nem mesmo para um sistema simples como esse.

Todo mundo diz que não tem tempo para testar. Mas, isso é a maior mentira do mundo. Todo mundo acha isso porque conta o tempo errado. O que importa em desenvolvimento de software não é o tempo de desenvolvimento, mas sim o tempo de vida da aplicação. Ou seja, ao longo do tempo de vida da aplicação, quanto tempo você vai ter que dedicar a ela? O desenvolvimento original da mesma é apenas uma parcela do problema. Normalmente a parcela maior vem depois, durante todo o restante do tempo de vida do aplicativo. Você vai ficar corrigindo bugs nele todo dia, ou vai estar liberado para desenvolver outra coisa?

A visão tradicional de que não dá tempo é míope. Não enxerga a grande verdade: o tempo de desenvolvimento é o menor dos problemas!

Semana que vem, vida nova. Vamos tocar nosso primeiro aplicativo comercial, aquele outro segredo que ainda vai levar um tempo para ser revelado. ;-)

Tags produto | 7 comentários